SQL Injection

Most web applications need to store data locally on the server, and rather than dealing with local files or SQLite, applications commonly use a back-end database such as MySQL or PostgreSQL. Unfortunately, many applications do not safely sanitize data before passing it to an SQL query, and many do not construct queries safely. Some common attacks include:

name' or '1'='1
productid' and '1'='2

The first attack is commonly used against authentication fields (e.g., username or password); if not properly sanitized the query will look for name or '1' = '1'; because 1=1 evaluates to TRUE in SQL, this would potentially let the attacker authenticate even without a valid password or user name. The second attack will help the intruder find out if a query is vulnerable to SQL injection; it will look for productid, but because 1 does not equal 2 (and thus the statement evaluates as FALSE), the and statement will force the SQL query to be false, which will most likely result in an error. In the case of a product page that should display the results for productid, it won't because the SQL query is invalid or causes an error.

Attackers love SQL injection because they can bypass authentication altogether, and depending on the database and configuration in question, it can also let them attack the local database server directly. Additionally, if the web application gets content from the database (such as product descriptions), an attacker can modify the product description to include PHP code (or whatever language the web application is built in), which is then executed the next time that page is requested, allowing an attacker to execute code on the server. For a really complete list of tips and tricks, check out the "SQL Injection Cheat Sheet" [14]. For a great SQL injection tool, check out SQLMap (now available as an official Debian package!) [15].

Cross-Site Scripting (XSS)

Cross-site scripting is a perfect example of why one should never mix data and code in a single object. HTML was once just a simple mark-up language that didn't involve any content executed on the client side. Of course, this made for a really boring web, and it wasn't too long before we got JavaScript from Sun and a variety of options from Microsoft (ActiveScript, ActiveX, etc.). Now the problem is that the web browser has no way to know what JavaScript should and shouldn't be present in a web page (and whether or not the JavaScript is "bad"), so an attacker who can insert content can just as easily insert JavaScript, which (usually) is executed on the client side, unless the client user is paranoid and has disabled JavaScript or installed the NoScript extension.

The real beauty of XSS attacks is that they are extremely common. You can put hostile content and code into the website the user is using, allowing you to steal cookies (which usually contain authentication credentials), keystrokes, form data, and so on – all of which can ultimately lead to administrative access on the application and more detailed attacks. Also, when XSS is combined with targeted email attacks and personal information gleaned from the web, the chances of successfully tricking a user into clicking on a bad link go up. But what happens when the website has a good web application firewall (or perhaps mod_security), which blocks XSS attacks? In that case, you go with encoding (UTF-8), embedding white space (which the browser will generally ignore), and adding strange characters into the script tag (such as "/"), to name a few methods.

Cross-Site Request Forgery (CSRF)

I covered cross-site request forgery in my monthly column in December 2008 [16]. To recap briefly: If a web application doesn't ensure that commands sent to it are valid, an attacker can potentially trick a victim's web browser into making a request that contains commands that the web application will execute (such as adding a new user or changing the permissions on an existing user). The bad news is that many applications still do not provide effective CSRF protection, the simplest reason being that there really aren't any widely accepted libraries to deal with this problem; the fact that people are forced to keep reinventing the wheel has led to many broken implementations.