Dragons in the Algorithm
Adventures in Programming
by Michael Chermside

Many ways to attack websites

Developers of web applications have quite a few different kinds of "attacks" to worry about. I will try to describe the major categories I know of, including one which is "new" as of the past month or so.

SQL Injection

The most venerable is the SQL-injection attack (and related attacks for things other than databases). This is the danger that data entered by users will be treated as meta-characters not just as text, and will allow a visitor to your site to execute arbitrary code in your database (or some other system). Nothing illustrates this kind of attack better than this XKCD cartoon:



There are XSS attacks - which stands for "Cross Site Scripting" (the acronym "CSS" was already taken). XSS is the danger that your site might serve up some content which was entered by a user (or perhaps loaded from a 3rd party site). Normally, this makes sense: whole empires have been built on the concept of allowing users to customize their own pages on your site. But browsers assume that any code served up by your site is trusted, and will allow it to do things like accessing you site's cookies. Particularly if users can get others to view their content, this can be quite dangerous. The first line of defense is to carefully sanitize and properly escape all content from users that it intended as plain text. As for content from users that is intended to contain markup, some sites just prohibit this, while others can use a solution like Google caja, which provides a secure sandbox for untrusted code to run in.


Wikipedia lolcat

XSS attacks exploited the fact that the user (or the user's browser) trusted content coming from your website (even if that content wasn't written by the site owner). The converse is a CSRF attack which exploits the fact that the site trusts content coming from it's user's browser. One of your users visits a malicious site which contains some sort of link to your site -- preferably a link which causes some action to be taken. The request comes from the user's browser, it has the user's cookies and everything, so your site thinks the user intended to send the request. The idea is for a site containing pictures of cute cats to trick your banking site into transferring money to someone's account. There are several defenses such as always using POST (helps, but doesn't fix the problem), a per-session unique ID, and double-submit cookies.


The latest hot issue in the web security community is "clickjacking". This is a variant of CSRF in that it occurs when your site's user navigates through a malicious website. But instead of the foreign site trying to generate a "click" on your website by embedding an image or executing some JavaScript, the foreign site embeds your site, perhaps within an IFrame. They then cover it up so you can't SEE it, but when you click you perform an action on the attacked site. You can see an innocuous example at http://noscript.net/getit, where the "install now" button installs from Firefox's site, not from noscript's site. The most evil versions will continually move the attacked site so it stays under the cursor... no matter where you click, the button you don't see will be under your cursor. Some of the details of this exploit have not been released yet, so it is too early to make clear statements about how a website (or a user) can protect themselves.

Plenty of others

I am sure that there are other fundamental forms of attack against web applications. Go ahead and add your own items in the comments below!

Posted Thu 09 October 2008 by mcherm in Uncategorized