A guided tour to someone else's network
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" . For a great SQL injection tool, check out SQLMap (now available as an official Debian package!) .
Cross-Site Scripting (XSS)
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 . 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.
Buy this article as PDF
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.
Four-inch-long computer on a stick lets you boot a full Linux system from any HDMI display device.
New statute would require companies to report break-ins to consumers.
Weird data transfer technique avoids all standard security measures.
FIDO alliance declares the beginning of the end for old-style login authentication.
Legendary Uber-distro splits over the systemd controversy.
One of CeBIT’s most successful forums returns in 2015.