The Five Most Common Web Development Flaws One of Microsoft's IT ACE team members (the team responsible for ensuring the security of their internal Line Of Business applications), Rob Labbe, shared the top five most commonly seen security issues that he and his co-workers have helped to work out of various client applications. The number five problem is what is known as Integer Overflow. This issue is typically seen when the user has the ability to enter some number and he/she decides to enter something really, really big. So big, in fact, it doesn't fit within the standard integer value. Since a 32 bit integer can only go as high as 2147483647, there are checks built into .NET to make sure values entered by the user don't exceed this number. But what this check doesn't look at is arithmetic operations that occur after the input is gathered. For instance, if the user entered 2147483645, and 3 was added to that value behind the scenes, then the result would be over that maximum number shown above. If you then try to put that into an integer without doing some sort of check, the actual value you would get would be a really big negative number (specifically -2147483646). This is because of how integers and similar values work within computers, because by going over the top end 32 bit value, you flip the "negative" bit and make the number extremely small. How this is a security issue all depends on what that new value is intended for. In Labbe's example, the user was selecting the number of license keys to generate (with a maximum of 10). The addition was done to see how many total keys the user has generated (there were previously 3 and now he wants 2147483645 more). Well, when the integer rolls over to a negative value, it becomes obvious that -2147483646 is less than the number of keys he can generate, and he can keep generating more. Labbe explained that the easiest way to solve this problem is to wrap your calculations in "checked" blocks. This keyword ensures that your results are safe, but comes at a performance hit. It's also worth noting that there is a setting in C# projects to do this operation all the time (well, there is a similar option in VB.NET projects as well, but it is on by default). Number four on the hit list was misplaced authorization checks via Web Services. This issue seems to be on the rise with the use of AJAX. The basic premise is that what the user can do or see is getting put more on the client side instead of the server where it is more secure. In this example, Labbe showed a sample web application that sent a message to the server asking if the current user was an administrator or not. The response was simply "Not an Admin." Labbe intercepted the message and edited it to say "Admin" and voila, he had admin rights. Labbe stressed that this was very bad and anything that dictates what the user can or can't see should be in the backend code in order to make it secure. The next two items in Labbe's top 5 list involve a hack called Cross-Site Scripting (XSS). XSS uses JavaScript or other languages to activate or manipulate the actions on another site. The first example of XSS hacking vulnerability involved a poorly written search box on a website. There were several issues that worked together to allow Labbe to take over a user's session and use his/her purchase information to buy hundreds of products. The first issue was that there was no HTML encoding being done to whatever the user typed into the search box. This meant that symbols which have special meaning to HTML (like the less than and greater than symbols) are interpreted as if it was written by the developer. What this means is that a hacker could inject JavaScript calls into the search box and/or send someone a link that has the malicious JS as part of the search string and it could grab a hold of the user's login and/or session data to be used at a later time. The other aspect of this sample involved poor error handling. If you tried to search for something that wasn't in the database, the error would give you the SQL statement that was trying to be run. This gives the hacker extra knowledge about what the website does behind the scenes. It seems like the easiest way to get rid of most XSS issues is to encode any input the user gives, thus making sure that any special characters that can be interpreted by the browser are converted into safe characters. The last, and possibly most dangerous, security risk Labbe showed was SQL Injection. Similar to XSS, the hacker will attempt to run SQL statements in input fields. Unless SQL statements are formed correctly and/or the developer uses SQL parameters instead of just appending strings together, the hacker could not only gain access to the data within the database, but drop tables and change user administration rights. Labbe showed several examples, though not going into a whole lot of detail about how to perform these tasks, in his talk. Each security risk was scarier and more disastrous than the last. Being aware of these issues and their simple fixes will go a long way to making your site and its data safer. -J.R. Nip, GameVortex Communications AKA Chris Meyer Related Links: Cross-Site Scripting on Wikipedia SQL Injection on Wikipedia