When performing a security code review, finding issues like Cross Site Scripting, SQL injection, Poor Input Validation, and others quickly can be a huge time saver. This also helps to make sure that the majority of the code has been reviewed for low hanging fruit, and then later a more in-depth review can be performed of the major areas of concern.
Cross Site Scripting (XSS)
Look for any Label, Literal, Checkbox, LinkButton, RadioButton or any other control that has a “.Text” property. If the value that is assigned to the .Text is not properly encoded there is a possibility for XSS.
GridViews, DataLists, and Repeaters can be set to either encode by default or not. If you see one of these being used verify that it’s being used properly. You set the data on these by assigning the DataSource property to some kind of structured data (usually a DataTable). Make sure the values in the DataSource are properly encoded or that the control is doing this automatically.
.NET can do automatic malicious character detection using the ValidateRequest=true setting. True is the default for this, so if you don’t see it it’s set properly. You must set this to false if you’re going to accept any character that .NET thinks could be dangerous (like < or ‘), so it’s common to see it turned off. This can live either at the top of an aspx file (between the <%@ %> tags) or in the web.config file in the <configuration><system.web><pages validateRequest =”false”> section.
.NET has a bunch of validators (CompareValidator, CustomValidator, RegularExpressionValidator); they all work on the entire string (even if your regular expression lacks the ^$ stuff), however these only check client side by default. (Note: I wrote a blog entry on creating good regular expressions for input validation earlier.) You can check those same validators on the server by checking the Page.IsValid property, but this isn’t done by default, so they’re probably vulnerable if if you don’t see validation and you don’t see something like the following:
Look for Any TextBoxes, DropDownLists, or ListBoxes; the input from all of these should be validated.
Searching for “using System.Data.SqlClient” will tell you which classes use SQL.
The common ways to execute SQL use the SqlConnection and SqlCommand classes. SqlCommand has ExecuteNonQuery and ExecuteQuery methods. NonQuery returns the number of rows that were affected while ExecuteQuery returns a DataReader used to read the SQL data stream. You’ll be able to recognize all kinds of SQL injection possibilities (format strings, concatenations, etc.) when you look at the ExecuteNonQuery and ExecuteQuery methods. If they’re using parameterized queries, they’re probably fine.
- Security In ASP.NET MVC (codeproject.com)
- 14 Years of SQL Injection and Still Widely Exploited. Why? (mavitunasecurity.com)
- SQL Injection Vulnerability in glFusion (seclists.org)