Many Typos

Author: dpaquette

Blog 5 - Security.md

@@ -6,7 +6,7 @@ Even those developers who should be highly concerned with security are often lac
 
 In BugTracker.NET we have identified a couple of poor practices that may be exploitable. Some of them are easy fixes and others are, well, catastrophically difficult. Let's examine BugTracker.NET's security issues by going through the top 10 security exploits on OWSP's list.  Before we start remember that these aren't the only security exploits in the world.
 
-I once did some work for a large engineering multinational who had a software security group. This group's mandate was to review applications deployed internally and access their security. Unfortunatly the security team had been pulled from the general population of programmers and were not given any additional training. Thus their entire approach to security was predicated on complying with the top 10 list. We mortal developers had to address each point before being permitted to deploy our application. Despite the application I developed having no backing database I still had to come up with an approach for eliminating SQL injection attacks. Much hilarity ensued.
+I once did some work for a large engineering multinational who had a software security group. This group's mandate was to review applications deployed internally and access their security. Unfortunately the security team had been pulled from the general population of programmers and were not given any additional training. Thus their entire approach to security was predicated on complying with the top 10 list. We mortal developers had to address each point before being permitted to deploy our application. Despite the application I developed having no backing database I still had to come up with an approach for eliminating SQL injection attacks. Much hilarity ensued.
 
 We'll just take a cursory look at all the potential issues in this post. Those that require more investigation and correction will be addressed in follow up posts.
 
@@ -34,13 +34,13 @@ However it possible to override this setting on a page by page basis in the unli
 ```
 validateRequest="false"
 ```
-Searching the project for these yeilds [quite a few examples](https://github.com/dpaquette/BugTracker.NET/search?p=2&q=validateRequest%3D%22false%22&type=Code&utf8=%E2%9C%93). The thing is that turning off request validation is not necessarily bad, unless we're printing the content back to the web browser unencoded. This is however difficult to find every case where unescaped values can be written back out to the browser. The difficulty of tracking down possible cross site scripting vulnerabilities when request validation is disabled is half the problem.
+Searching the project for these yields [quite a few examples](https://github.com/dpaquette/BugTracker.NET/search?p=2&q=validateRequest%3D%22false%22&type=Code&utf8=%E2%9C%93). The thing is that turning off request validation is not necessarily bad, unless we're printing the content back to the web browser unencoded. This is however difficult to find every case where unescaped values can be written back out to the browser. The difficulty of tracking down possible cross site scripting vulnerabilities when request validation is disabled is half the problem.
 
 This topic is complicated enough to warrant an entire blog post as we investigate whether proper care has been taken to avoid cross site scripting attacks. We'll introduce some tricks to make it easier for future developers to know that cross site scripting attacks have been mitigated.
 
 ##Insecure Direct Object References
 
-Often there are parts of the system to which a user might have only partial access. In BugTracker.NET a great example woudl be a bug. A user from project A should not have access to a bug from project B. However the same screen is used for accessing each bug with the only difference being the bug ID. Checks have to be made in the code to avoid displaying bugs that users should not be able to see.  This is actually a pretty common exploit.
+Often there are parts of the system to which a user might have only partial access. In BugTracker.NET a great example would be a bug. A user from project A should not have access to a bug from project B. However the same screen is used for accessing each bug with the only difference being the bug ID. Checks have to be made in the code to avoid displaying bugs that users should not be able to see.  This is actually a pretty common exploit.
 
 Fortunately, it looks like there are extensive checks throughout the application for user permissions. The checks look something like
 
@@ -79,7 +79,7 @@ We're going to drop these features. It is possible that we'll lose some customer
 
 ##Missing Function Level Access Control
 
-Ensuring that lower level users cannot visit pages that are restircted to higher level users is important. Attacks on your site may come from users who are valid. It is also possible that an external attacker may have an easier time exploiting user level accounts and then elevating their privileges.
+Ensuring that lower level users cannot visit pages that are restricted to higher level users is important. Attacks on your site may come from users who are valid. It is also possible that an external attacker may have an easier time exploiting user level accounts and then elevating their privileges.
 
 There are extensive checks in place inside BugTracker.NET to prevent these sorts of attacks. The difficulty again is that the checks for this are scattered all over the application. It is hard to know if every possible escalation is protected against. For the moment I'm comfortable leaving this alone. At some later point it may be worthwhile extracting the user level functionality to some common module. This may actually be an ideal place to leverage aspect oriented programming.
 

Blog 5.1 - SQL Injection.md

@@ -1,4 +1,4 @@
-In the previous instalment of this series we took a look at the various security issues present in BugTracker.NET. We identified five vulnerabilities that were worth addressing at once. The most difficult, or at least the most time consuming problem to address is the potential for SQL injection attacks.
+In the previous installment of this series we took a look at the various security issues present in BugTracker.NET. We identified five vulnerabilities that were worth addressing at once. The most difficult, or at least the most time consuming problem to address is the potential for SQL injection attacks.
 
 BugTracker.NET does not make use of any entity relational mapping tool such as Entity Framework or NHibernate. Instead it uses direct access to the database though ADO.net. To ensure that your ADO.net queries are safe the it is considered best practice to use parameterized queries. Parameterizing queries avoid SQL injection attacks by passing the duty of escaping string onto the database itself.  This ensures that there is no risk of anybody sneaking a value in that will break out of the query and allow an attacker the ability to compromise the data.
 
@@ -46,7 +46,7 @@ and (us_id <> $us or isnull(us_send_notifications_to_self,0) = 1)";
 ```
 The construction of this query relies on the various parameters having been escaped prior to being inserted into the string. The final few lines of the above code do the replacement of tokens in the query and then pass the query onto a utility function that fetches a dataset.
 
-Now looking through the application I can't actually find any parameters that aren't properly escaped. I think it is likely that they exist, somewhere, and that the large amount of code is obscuring them. However it does require that every parameter be manually escaped. It is very easy to forget such things andy it only takes one mistake to allow an attacker to delete the entire database. The [general advice](https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf) is to avoid blacklisting characters.
+Now looking through the application I can't actually find any parameters that aren't properly escaped. I think it is likely that they exist, somewhere, and that the large amount of code is obscuring them. However it does require that every parameter be manually escaped. It is very easy to forget such things and it only takes one mistake to allow an attacker to delete the entire database. The [general advice](https://www.owasp.org/images/d/d4/OWASP_IL_2007_SQL_Smuggling.pdf) is to avoid blacklisting characters.
 
 We want to make sure that not only is the application itself secure but that future developers are prevented, as best as possible, from shooting themselves in the foot. If every query is parameterized then it should act as something of a hint to future developers that they too should parameterize queries.
 
@@ -133,7 +133,7 @@ Now comes the long and arduous task of going through and replacing all the SQL s
 1. Remove any quoting of the variables in the string
 1. Remove any escaping that has been plugged in to the parameters
 
-An typical example is that we change
+A typical example is that we change
 
 ```
 string sql = @"
@@ -185,7 +185,7 @@ This poses a difficult problem: I'd like to keep the custom column functionality
 
 ![Properties Table](Images/PropertiesTablePattern.png)
 
-When querying for a bug we can look for all the entires in this table to find the properties. It makes some filtering queries a bit harder but we will have a search engine in place for that.
+When querying for a bug we can look for all the entries in this table to find the properties. It makes some filtering queries a bit harder but we will have a search engine in place for that.
 
 I chugged along for some time fixing the various queries in the application. I spent a lot of time without a compiling application, which always makes me nervous. Eventually I got to the point where the application would compile. With baited breath I launched the application to see if it would work.
 
@@ -219,7 +219,7 @@ We use this parameter name as it one that is used by ASP.net MVC projects so it
 
 [View the Commit](https://github.com/dpaquette/BugTracker.NET/commit/c6201f790a80bcfb678ce2cd54810277e0caaaab)
 
-With this in place I discovered another hundred and fifty places in need of updating. When these were fixed another hundred and fifty errors poped up. It looks like there might be some batching of files sent to the aspx compiler and that if any one batch fails the processing stops before hitting the next batch. In the end there were about 500 places in need of changes. This took, obviously, more than one commit.
+With this in place I discovered another hundred and fifty places in need of updating. When these were fixed another hundred and fifty errors popped up. It looks like there might be some batching of files sent to the aspx compiler and that if any one batch fails the processing stops before hitting the next batch. In the end there were about 500 places in need of changes. This took, obviously, more than one commit.
 
 [View the Commits](https://github.com/dpaquette/BugTracker.NET/commits/SQL_Parameters)
 

Blog 5.2 - Password Hashing.md

@@ -4,11 +4,11 @@ Storing passwords is always a tricky proposition. For a great number of sites th
 
 Authorization is the act of matching a user with a set of permissions. So I could be authenticated as Simon and authorized to edit bugs.
 
-When storing a password there are a couple of ways to do it - most all of them are wrong. Encryping passwords seems like a good idea at first but if the encrypted passwords are leaked, as seems to happen with alarming regularity, then an attacker could decrypt the passwords. This is a bad situation because many people reuse passwords from site to site. Not only do you put your own site at risk but also other sites. With a password and an e-mail address it is possible the attacker could log into a banking website or some other high impact site. This is the reason that it is recommended that people use distinct passwords for each website.
+When storing a password there are a couple of ways to do it - most all of them are wrong. Encrypting passwords seems like a good idea at first but if the encrypted passwords are leaked, as seems to happen with alarming regularity, then an attacker could decrypt the passwords. This is a bad situation because many people reuse passwords from site to site. Not only do you put your own site at risk but also other sites. With a password and an e-mail address it is possible the attacker could log into a banking website or some other high impact site. This is the reason that it is recommended that people use distinct passwords for each website.
 
-Hashing passwords is a far better idea. A hash is a one-way function that cannot be reversed to reveal the password. When hashing it is important to hash not just the user's password but to combine it with a salt. A salt is a string of random characters that is appended to the unhashed password before hashing. This random string acts as protection from an attack using rainbow tables. A rainbow table is a large database that maps passwords with the hashes they generate. Many popular hashing algorithms have rainbow tables which permit near instantaneous exploration of a large percentage of the key-space. Salts invalidate this approach as the key in the rainbow table maps to the password + salt. Without knowing the salt an attacker is not able to enter any password that will work. The key in the rainbow table is unlikely to be the actual user password and more likely to be a string that simply hashes to the same value so it will not be obvious what the users's password is.
+Hashing passwords is a far better idea. A hash is a one-way function that cannot be reversed to reveal the password. When hashing it is important to hash not just the user's password but to combine it with a salt. A salt is a string of random characters that is appended to the unhashed password before hashing. This random string acts as protection from an attack using rainbow tables. A rainbow table is a large database that maps passwords with the hashes they generate. Many popular hashing algorithms have rainbow tables which permit near instantaneous exploration of a large percentage of the key-space. Salts invalidate this approach as the key in the rainbow table maps to the password + salt. Without knowing the salt an attacker is not able to enter any password that will work. The key in the rainbow table is unlikely to be the actual user password and more likely to be a string that simply hashes to the same value so it will not be obvious what the user's password is.
 
-Even when hashing passwords we need to remain vigilent about the implementation. Many common hashing functions such as MD5 and SHA are designed to be as fast as possible. Their purpose is to give a checksum of a file so you know if the file is correct. For this application we want hashing large quantities of data to be as simple and fast as possible. The opposite is true of password hashing. We would like to take as substantial amount of time to avoid brute force attacks. A possible algorithm is the bcrypt algorithm. It is interesting as it is a tuneable algorithym that can easily be made to take longer as computer resources get cheaper.
+Even when hashing passwords we need to remain vigilant about the implementation. Many common hashing functions such as MD5 and SHA are designed to be as fast as possible. Their purpose is to give a checksum of a file so you know if the file is correct. For this application we want hashing large quantities of data to be as simple and fast as possible. The opposite is true of password hashing. We would like to take as substantial amount of time to avoid brute force attacks. A possible algorithm is the bcrypt algorithm. It is interesting as it is a tuneable algorithm that can easily be made to take longer as computer resources get cheaper.
 
 How easy is it to break a password hashed with a low grade hashing function? Well famed hacker Kevin Mitnick give a hint:
 
@@ -22,7 +22,7 @@ This is not to say that a bug database would be a high value target but the amou
 There are a couple of options for fixing the password problem in BugTracker.NET. The ideal solution is to rip out all the entire authentication system and replace it with something like [ASP.net Identity](http://www.asp.net/identity). Identity is well designed (at least in this version, don't ask about version 1) and well tested. It also brings in functions to throttle logins, change passwords and all that good stuff. This is, however, a pretty large undertaking.  
 We're in the business of getting the best solution for the least amount of work. We can solve most of the issue here simply by replacing the hashing algorithm.
 
-There is no well checked implementation of bcrypt on the .net platform. There is, however, an alterntative in the PKDBF2 algorithm as defined in RFC 2898 in the base class library. This algorithm is similar to bcrypt in that it has an interations setting that permits making the algorithm take longer thus increasing the cost to the attacker.
+There is no well checked implementation of bcrypt on the .net platform. There is, however, an alternative in the PKDBF2 algorithm as defined in RFC 2898 in the base class library. This algorithm is similar to bcrypt in that it has an iterations setting that permits making the algorithm take longer thus increasing the cost to the attacker.
 
 So now that we know the algorithm we need to decide how we're going to migrate to it. Looking at the source code it seems like, perhaps, this is not the first time that somebody has attempted to improve password security.
 
@@ -75,7 +75,7 @@ We don't want to send a new password in plain text. If somebody is reading their
 
 #Adding the New Password Check
 
-The very first step is to rip out the existing MD5 based password algorithm and put in place the PKDBF2 algorithm. In the code it is called RFC2898. At the same time we'll simplyfiy the hashing function to be a bit clearer.
+The very first step is to rip out the existing MD5 based password algorithm and put in place the PKDBF2 algorithm. In the code it is called RFC2898. At the same time we'll simplify the hashing function to be a bit clearer.
 
 The old method looked like
 ```