Having been stressing online forms of my fellow developers at work, and reading Eric Farraro’s posts on Cross Site Scripting and his recent Google exploit, I figured just how important user input validation is, and the need to emphasise that.

Both XSS and SQL Injections are simple exploits that work on a basic assumption that a web application ‘trusts’ the input it is given, ether through carelessness or ignorance of the developer. The common pattern is the following style of code

[php] echo “hello:”.$user_input; //XSS vulnerable
$sql = “INSERT INTO table VALUES (”.$user_input.”)”;
//SQL Injection [/php]

While both are valid approaches when working with variables, contents of which are your own, it is a whole different game when the values are supplied by an external user. With no limitations, the above code is essentially an equivalent of

[code] "hello", place-your-webpage-here
$sql = access-to-my-whole-database[/code]not good…

Numerous explanations with examples are already available for both XSS and SQL Injections, so why do they still occur? In an otherwise secure application, the exploits are usually found in places where the developer relies on client-side data validation. Form elements come with constraint attributes (such as max-length for text fields), and JavaScript could handle elaborate validation schemes, but that, in fact, relies on the user to validate their own data. In the professional world we call this ‘conflict of interests’, as a mischievous user will obviously think otherwise of their ‘incorrect’ input.

“yes, my name really is \’; DROP table users; –”

One cannot be certain as to what is really happening on the other side. Opera browser allows users to edit the HTML code of the page, and reload it from cache. Firefox’s amazing Web Developer extension allows the same, and more. I make one bad QA specialist when I use the above extension to remove form element constrains, disable JavaScript, and write text into otherwise select-from-drop-down menues. One would assume that user’s choices are limited to the list, but ultimately one would have to check for that on the server side.

Personally I would suggest using an established framework, that handles most of security issues, to build your project upon. Being a Ruby fan that I am, Ruby on Rails is an exceptional choice. Security assistance is build into the framework itself, preventing common SQL Injection

“If you only use the predefined ActiveRecord functions (attributes, save, find) without writing any conditions, limits or SQL queries yourself, ActiveRecord takes care of quoting any dangerous characters in the data for you.”

and Cross Site Scripting

“Strictly convert HTML meta characters (“< ” and “>“) to the equivalent HTML entities (”<” and ”>”) in every string that is rendered in the website. … Rails provides the helper method h() for HTML meta character conversion in Views.”

Additionally Rails includes an amazing framework for data validation, ensuring the integrity of data submited (and results in pretty looking feedback as well). I might get into more detail about that later.

The bottom line is – keep in control of your application, and validate all the content yourself, don’t trust the user to always enter the correct input.

Take care,

– Tony

Read more

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.