SQL Injection Attacks

The joy of using an ORM like SQLAlchemy or SQLObject—in addition to the benefit of not having to write a single SQL statement yourself—is its ability to protect you from SQL Injection attacks. Although this built-in security measure affords you protection, it is important to understand how SQL injection attacks work.

If an application contains code that looks like this…

…then you are vulnerable to the stinging strikes of a malicious user. That’s because he or she can craft a cookie with the value of "someonebad';
TRUNCATE TABLE users; SELECT '". The SQL statement that will be executed will then be:

…which is not good, not good indeed!

To see just how bad the situation really is for our fellows in PHP land, have a look at these Google code search results, or for our little brothers in ASP land, have a look here. Please act responsibly and don’t hack into the sites listed there.

Luckily, ORMs escape all the strings we send to the database engine, and as a result, we are protected from this kind of harmful attack.

XSRF: Cross-Site Request Forgery

This exploit is very common in Web applications, especially in those that provide AJAX API. It is best to describe this type of attack with an example. Suppose that an imaginary project, TGBank (which is a Web interface for a bank), has a send_money() method:

The bank site using this application might contain a page with a “send money” form, where the user fills in information such as to whom he is transferring the money and how much money he is transferring. Everything’s find and dandy there. But what if the user is connected to the bank site, and in another browser tab, he is simultaneously browsing a malicious site, one that contains the following img tag?

Then the user’s browser will trigger that operation on behalf of the unsuspecting and innocent Web visitor. And because it’s such and inconsequential amount, he probably won’t even bother to check about those four cents.

Allowing only POST requests to go into send_money() will not help the matter. That’s because it is easy to send POST requests using Javascript. On the other hand, checking that the HTTP referrer header of the request is within one’s domain is too restrictive. That’s because many browsers often do not send this header.

A possible solution is to add a hidden field that only your application can generate and validate. For example, you might consider that the application will process the request only if received a query argument with the value of a sha1 digest of a string that is composed of the user id and a secret word. This string can be easily validated by your application, but it will be hard for a malicious site to generate.

Utterly Ridiculous!—More XSRF: Stealing Information with Scriptaculous

In addition to doing serious damage, this type of attack can be used to steal information. Suppose the bank application previously mentioned has a URL that returns Javascript code that defines a list with your monthly statement (list of expenses). It may be used on the bank site for doing client side sorting. A malicious site might contain something like this:

Here, that dastardly attacker placed code on his site, that executes the monthly statement script from the bank’s site. Once that script is executed, we have an object named statement containing a list of monthly expenses. Then, after the document finished loading, it is transmitted right into the waiting attacker’s hands.

Recently, an XSRF flaw was discovered (and fixed) in GMail. This vulnerability allowed an attacker to steal the user’s contact list precisely as just mentioned.

Assault–Take Two! XSS: Cross-Site Scripting

Cross-site scripting vulnerability occurs when a Web application generates output that contains user-supplied data without HTML encoding. For example, if we allow a post in a forum to contain HTML tags, then we can use KID to display it:

Raising the ax yet again, a vile attacker can embed javascript code into his post. Then, when an innocent user visits the page, his or her browser runs the script, unbeknownst to him or her. This script can, for example, send the contents of the page back to the attacker. It might also post a comment to a blog, in the unsuspecting user’s name, or make new friends for him or her in MySpace.

If we do not use the XML() function in KID, then HTML entities are escaped and we are safe. The users will see just the script text and the browser will not interpret it as code. That said, if XML() is to be used, then it is suggested one check whether the string contains '<script' (case insensitive) before actually sending it. You should also beware of spaces between the script and its surrounding < and >, although I haven’t tested which browsers allow it. Note that most HTML elements allow attributes that can contain javascript code like onmouseover or onclick. The safest thing would be to escape all < to < (Python has a cgi.escape function for this). If HTML tags are to be allowed, then the application should carefully check that they contain only permitted attributes. Also the href attribute of <a> tag should be checked that it does not contain something like “javascript:do_something()”. That way, those malicious attackers can be forced to drop their weapons before they have time to draw them.

Now that you’ve learned how to preempt attacks before they strike, you’re well on your way to a more enjoyable Web application development experience. Comments and questions about the strategies outlined here are welcomed. We also encourage suggestions on how you’ve successful waged war against security attackers.

Moving around quickly

The most basic part is to move to the place you want to edit quickly. Here are the most useful shortcuts:

• Ctrl-a – Move to the start of the line.
• Ctrl-e – Move to the end of the line.
• Alt-f – Move forward a word.
• Ctrl-f – Move forward a char.
• Alt-b – Move backward a word.
• Ctrl-b – Move backward a char.

Another very common shortcut is Ctrl-L which clears the screen and reprints the current line at the top. This is useful if you are organizing your movies library and somebody enters the room.

Cut, Paste and Undo

Here is the list of most useful shortcuts for deleting text:

• Ctrl-w – Deletes from cursor position to the previous whitespace.
• Ctrl-k – Deletes from cursor position to the end of the line.
• Ctrl-d – Deletes from current character.
• Ctrl-u – Deletes from whole line.
• Alt-d – Deletes from cursor position to the end of the current word.
• Alt-DEL – Deletes from cursor position to the start of the current word.

The deleted text can be pasted (yanked) using Ctrl-y. You can use Ctrl-_ or Ctrl-X-U to undo the last editing command.

Summary

This covers the essentials. On the next parts of this series we’ll explore the more powerful abilities of readline. Feel free to leave here questions, suggestions, or perhaps your own tips and tricks.