Three of the top five most common website attacks – SQL injection, cross-site scripting (XSS), and remote file inclusion (RFI) – share a root cause in common: input sanitization. Or to be more accurate, a lack thereof.
All three exploits are leveraged by data sent to the Web server by the end user. When the end user is a good guy, the data he sends the server is relevant to his interaction with the website. But when the end user is a hacker, she can exploit this mechanism to send the Web server input which is deliberately constructed to escape the legitimate context and execute unauthorized actions.
Input sanitization describes cleansing and scrubbing user input to prevent it from jumping the fence and exploiting security holes. But thorough input sanitization is hard. While some vulnerable sites simply don’t sanitize at all, others do so incompletely, lending their owners a false sense of security.

Incoming Data Dangers

There are three roads data can take to get from a user’s browser to the Web server:
GET requests. These are parameters included in the URL, often (but not always) generated by form input on a Web page. The parameters in a GET request appear after the question mark in a URL:

Anyone can easily manipulate the data in a GET request simply by editing the URL.
POST requests. These are parameters included in the header information sent from the browser to the Web server. POST data does not appear in the URL, but can be manipulated by hackers using browser plugins like Tamper Data For Firefox  or simply with custom code using a library like cURL.
Cookies. Often overlooked when sanitizing input, cookies created by a website can contain exploitable data. Cookies are stored as plain text files on the end user’s machine and can easily be modified by a hacker to manipulate input data sent to the server.

Example Attacks and Defenses

Exploiting input sanitization weaknesses can take many forms, but let’s look at some classic attacks. We are using PHP for these examples, but the same principles apply to other Web development languages like ASP and Ruby.
ATTACK: Returned form input. In this attack, the hacker exploits a Web page that returns an incomplete form by echoing back the user’s own input.