The OWASP Top Ten Project can be found at their website: http://www.owasp.org/index.php/OWASP_Top_Ten_Project
The number one security vulnerability as of writing this article, is Cross-site Scripting (XSS). Cross-site scripting occurs when an attacker inserts malicious coding into a page element appears to be from a trustworthy source. When a user interacts with the element, (i.e. clicks a link or even views an image) the embedded programming is submitted as part of the browser’s request and can execute on the user's computer. For example, many forum and guestbook sites allow users to submit posts with embedded HTML and JavaScript. If someone views a post that contains malicious JavaScript, then the user can be subjected to information theft or session hijacking.
Additional common vulnerabilities are Injection Flaws. A site that accepts user input and executes commands based on some or all of that user-supplied data, is vulnerable to injection attacks. The most common form of injection is SQL injection. One form of SQL injection is when text provided by a user is inserted directly into a SQL command, which can result in elevated privileges, information theft, and information tampering. Lets imagine that an insecure website that contains a username and password login form.
The website then takes the username and password supplied by the user, and builds the SQL query string below.
SELECT * FROM Users WHERE username = ‘“ + txtUserName.Text + “’ AND password = ‘” + txtPassword.Text + ”’;
This approach does work, but what it also does is allow a malicious user to inject his own SQL into the command, and possibly gain unauthorized access. What would happen if a user entered the following into the login form?
When the form is submitted, the SQL query that gets executed would look something like this:
SELECT * FROM Users WHERE username = ‘’ OR 1=1 --’ AND password = ‘randomtext’;
This is a valid SQL query that will execute and always return true, allowing the user to gain access to the system. The “--“ command acts as a comment, which tells the SQL engine to ignore anything after it. So “’ AND password = ‘randomtext’;” is ignored.
Surprisingly, both XSS and injection flaws are easily avoidable. The easiest and most important way to protect against these types of attacks is one of my golden rules.
ALWAYS VALIDATE USER INPUT!
As a web developer, it is a mistake to trust any data coming from the browser. Data should be validated and revalidated to ensure that it cannot be used in an unsafe manner. There are two types of validation - positive validation and negative validation. Most developers would approach fixing a vulnerability by restricting the use of certain characters. In the SQL injection example, one could just eliminate the use of the apostrophe, equals sign, and hyphens. The same applies for the XSS example. One can restrict the special characters used in JavaScript. These are examples of negative validation, also known as black listing. But one problem with negative validation, is that there is still room for other special characters to make their way into the application if the developer chooses to use negative validation alone. On the other hand, one could also only allow A through Z characters into a textbox, and disallow all others, which is an example of positive validation, also known as white listing. By using positive validation, the developer specifies which characters are allowed while disallowing all others. Overall, you should always use positive validation when validating user input, or even better, use both positive and negative validation.
Another method in protecting against security vulnerabilities, particularly SQL injection attacks, is to use parameterized queries or stored procedures. In ASP .NET, Visual Studio allows developers to quickly and easily create parameterized queries for database operations. For more information on using parameterized queries, check out http://aspnet101.com/aspnet101/tutorials.aspx?id=1.
Encoding data that is displayed in the browser is also important. If special characters do make it into a field, and your application reflects that data back to the screen, it could render as code. So make sure to HTML encode your output before sending it to the screen by calling Server.HTMLEncode(String). This way, malicious code is rendered as harmless text.
It doesn’t take much to prevent many security flaws from creeping into your application. Just remember to always validate user input, HTML encode your output, and use parameterized queries or stored procedures.
Related Post: Define Your Development Team's .NET Coding Standards
