Here’s a bit of Monday morning fun: Slashdot reports that SQL.com was cracked via an SQL injection attack.  

SQL is a very prominent database schema used in thousands of installations around the globe.  An SQL injection is when an attacker bypasses the normal front-end for the database and finds a means of executing their own commands, usually with the aim of either stealing information or of corrupting or changing the database in some fashion.

Cross-site scripting, also mentioned in the article, is a means by which such attacks can take place.  This is a slightly more complex vulnerability–essentially, it occurs when the client, rather than the server, is used to validate requests against the server.  If that is the case, then a sufficiently competent attacker can craft a malicious version of the script produced by the webpage in question and serve that to users (via the usual social engineering methods) in an attempt to gain login credentials, session credentials, or other information about how the resources are generally accessed.

Combining the two can lead to a theft of credentials usable for gaining access to the whole of the database for whatever purpose the attacker wishes–the “pwnage” that many attackers seek to gain.

The vulnerability in the SQL databae was apparently, according to the articles linked above, discovered in January by some enterprising folks out of Romania.  Whether it was reported ahead of time is not known to this author at this time–the original resources are protected behind a policy setting at a Romanian exploit site, and the XSS (cross-site scripting) vulnerability has a publication date of April 1–though this could be January 4, and a dd/mm/yy rather than mm/dd/yy confusion.  

The vulnerability in question appears to be something rather obvious; the actual attack is caused via inserting a “script” html tag in the URL of the resource requested.  

The countermeasures to prevent this sort of thing happening are twofold:  first, of course, is never to click on a URL without knowing what it is you’re clicking on.  Think before you click.  There’s no reason to click on a link with an html tag embedded in it, normally; such uses are endemic for exploiting security flaws, but are not often used by legitimate sites.

Secondly, if you are designing a site, assume that any input coming from the client side is unsafe and must be validated–there’s no point putting the validation mechanism out where it could be changed.  Javascript is inherently open-source because the source must be served to the client machine in order to run; as such, any vulnerabilities present in it will be found eventually.  There’s no way to ensure that input coming to your servers is being sent by the same javascript that was served from them originally; take this into account when designing your sites, and you will not be vulnerable to this kind of attack.

One Response to “SQL injections and cross-site scripting”


  1. Cross-site scripting continued: McAfee boogaloo - Aetheric Research, Ltd. says:

    [...] As reported yesterday by Network World, McAfee’s website has a cross-site scripting (XSS) vulnerabilities that could lead to compromise in the same manner as the SQL.com compromise. [...]