Tuneup Talk Home


Web Sites and SQL Injection

A new SQL (Structured Query Language, used for databases) injection attack emerged recently, and so far it’s apparently infected over 40,000 websites with malicious software. The attack has been termed “Beladen,” which is German for “loaded,” and refers to the website to which the attack attempts to redirect users (e.g. beladen.net).

SQL injection isn’t an uncommon attack method, and it’s easy to use against badly written websites containing forms with unfiltered or unvalidated input fields. Clever attackers can insert SQL commands into these form fields, where they’re executed against the database. This results in anything from bogus data to compromised private information within the database.

In this case, the attack inserts code that attempts to redirect users to the bogus beladen.net website. It tries to “push unsuspecting victims to typo-squatting site ‘googleanalytlcs.net’ that attempts to push malware such as keyloggers onto the victim’s machine. If that’s not successful, it will try to scare them into buying fake antivirus software.”

If you’re a web developer working with data-driven sites, you want to be very aware of the possibility of SQL Injection attacks. The frequency of such incidents apparently rose to an all-time high in 2008, and for good reason. While more sites are doing better at protecting files and access via traditional (OS) methods, not everyone protects their DB appropriately.

For example, I know of many sites that use one (and only one) account to manage database access. The login ID used is often a super-user that has unlimited access to all tables and other functionality. This means anyone can use SQL Injection to perform any task whatsoever on the database. It’s far safer to use multiple accounts that have appropriately restricted access to the system, since this makes a hacker’s job all that much more difficult.

That, really, is the name of the game in terms of defending your website against attack. If a site is harder to break into, a hacker is far more likely to move on to find one that’s less defended. Clean up your code, make sure all form fields are appropriately validated/filtered, and lock down database access to minimum usable levels. The data you save might be your own.

Leave a Reply