Security research, news and guidance

Output Validation

In addition to validating all of the data your application receives you should also follow similar processes for the data your application will output. Some attacks such as Cross Site Scripting can take advantage of poorly validated output to attack unsuspecting end users through your application. There are three main issues associated with output validation that you should always aim to address in your application; they are data encoding, data format and data length.

The data encoding process is slightly different depending on where your output is going to end up. For example if your data is going into a URL you need to ensure it is URL encoded. We have included an example below of a malicious value appended to a URL and how URL encoding of this data would remove the threat.

The example site has a parameter in the URL called day, this parameter will contain the current day and it will then write this into the homepage. This allows the homepage to always display the current day for the user:

www.examplesite.com/home.html?day=Monday

If we assume that the example site hasn’t implemented output validation for the day parameter a malicious user could replace Monday with anything they wanted to. The parameter’s lack of validation could be exploited with something like this:

www.examplesite.com/home.html?day=<script>alert(document.cookie)</script>

If a user were to access this URL a pop up would appear which contained their cookie for the example site. This is a simple example but a malicious user could silently steal the cookie rather than show it to the user in a pop up box. If the site had implemented URL encoding the threat posed by cookie stealing JavaScript would have been nullified as we have shown below:

www.examplesite.com/home.html?day=%3Cscript%3Ealert%28document.cookie%29%3C/script%3E

A second type of encoding that should be considered is HTML Encoding. The first encoding we looked at covered encoding of data in a URL, if your data is going to be entered into a HTML page you should employ HTML Encoding.

We have included two sets of code below. The first piece of code has no output validation that could leave it vulnerable to attacks such as Cross Site Scripting:

#!/usr/bin/perl
use CGI;
my $cgi = CGI->new();
my $name = $cgi->param(‘username’);
print $cgi->header();
print ‘You entered $name’;

The code will accept any text into the username parameter and then use this data in the print statement:

print ‘You entered $name’;

You can clearly see that no validation has occurred on this data. The username data should have been subjected to both input and output validation prior to it being used in the print statement. This example uses Perl which means we can make use of the HTML::Entities Perl module to encode this data for us; the code shown below has implemented this module:

#!/usr/bin/perl
use CGI;
use HTML::Entities;
my $cgi = CGI->new();
my $name = $cgi->param(‘username’);
print $cgi->header();
print “You entered “, HTML::Entities::encode($name);

Any data entered into the username field will now be HTML encoded prior to it being printed. If a malicious user were to input the same JavaScript we used in the previous example (<script>alert(document.cookie)</script>) it would be changed to the following:

&lt;script&gt;alert(document.cookie)&lt;/script&gt;

This would again nullify the threat posed by the malicious input. The values that have been changed (i.e. < & >) would still be written to the page but as a literal value instead of being used as a special character. This will allow you to implement strong validation techniques but also continue to display characters such as < & > on your web page.

In addition to the encoding we have explored already we should always control the content encoding method used by the web browser. We can configure this in two places, firstly the HTTP response header:

Content-Type: text/html; charset=utf-8

And secondly in the Meta tags:

<META HTTP-EQUIV=”CONTENT-TYPE” CONTENT=”text/html; charset=UTF-8″>

This will ensure that the browser correctly encodes your data. The final point to remember when you are implementing output validation is length validation, as we saw for input validation we should define the minimum and maximum lengths for all of our data.

VIDEOS & SLIDESHARES

Look at our latest security Videos & SlideShares

EVENTS & SEMINARS

Upcoming Security Events & Seminars

PODCASTS & DOWNLOADS

Check out our Podcasts & White Papers