Recently, I've been doing a lot of application security assessments for clients of Applied Trust, the majority of them being black box or grey box testing, all dealing with some form of web application.  The most common problems I find deal with developers not or inadequately sanitizing user supplied input.

Any time you write a user supplied value back to the page, you need to be leery of cross site scripting (XSS) attacks. Any time you are inserting user supplied input into a database, you need to guard against SQL injection attacks.

The steps below will teach you how to guard against these attacks...

Step1: Validating input

Regardless of whether we're talking about cross-site scripting (XSS) or SQL injection attacks, all input needs to be validated.  This most commonly affects web applications pulling input in from GET and POST variables but depending upon the architecture of your application this could also include other sources such as cookies.  You should always white list input, that is, make sure the user supplied input is what your application is expecting.  I repeat again, WHITE LIST INPUT.

Here are a couple examples in PHP:

If you're expecting an integer, match it to a regular expression:

if(ereg("^[0-9]{1,8}$",$_GET['number'])){
 // valid, "number" only contains digits and is between
 // 1 and 9 digits, continue to process
 ...
 }

or use PHP's intval() function to explicitly set input to the integer type:

$clean_number = intval($_GET['dirty_number']);

If you're expecting a last name, require it to match a regular expression containing only letters of the alphabet and ensure it is of proper length:

if(ereg("^[A-Za-z]{1,15}$",$_GET['lastname'])){
// valid, "lastname" only contains letters and is between
// 1 and 15 characters, continue to process
...
}

Step 2: Validating output

In a perfect world, the following techniques would not be required, one would simply write perfect white list filters for every possible input value.  Unfortunately, we need a second layer of protection as we must account for human logistical errors.  Below I will show you two common techniques for preventing against XSS and SQL injections.

Cross-site scripting protection

To prevent cross-site scripting attacks we need to HTML encode all user input that we will be writing back to the page.  We do this so an attacker cannot insert arbitrary HTML and JavaScript into our pages.

For example, we want to encode the left bracket "<", which is used in JavaScript <script> statements, to its HTML encoded equivalent of "<"  Also, if we are outputting the user's input into a JavaScript block within our page, we want to escape all single and double quotes so that they do not disrupt our string literals (ie. ' is encoded to #039;).

In PHP, this can be accomplished using the htmlentities() function:

// explicitly return our page as ISO-8859-1.
// instead this can be specified in the
// "default_charset" directive of php.ini.

header('Content-Type: text/html; charset=ISO-8859-1);

// encode our output into its HTML character equivelents
// for charset ISO-8859-1, also escape quotes

echo htmlentities($_GET['user_input'], ENT_QUOTES, 'ISO-8859-1');

The reason we set a charset is because this protects us against cross-charset attacks (like the UTF-7 XSS attack to which The Google was vulnerable).  We must also ensure htmlentities() is encoding our output for the charset we are returning our pages in.

SQL injection protection

If we're using PHP, then most likely we're using MySQL  as our database back end.  We can use the mysql_real_escape_string() function to sanitize user input that contains harmful quotes intended to escape out of the intended context of the query.

$clean_query=sprintf("UPDATE `table_foo` SET `foo_name`='%s' WHERE 1=1",
             mysql_real_escape_string($_GET['foo_value']));

This post will be the first of a series of posts that will show remedies for guarding against common attacks identified in the Open Web Application Security Project (OWASP).