We hear the same terms bandied about whenever a popular site gets hacked. You know… SQL Injection, cross site scripting, that kind of thing. But what do these things mean? Is hacking really as inaccessible as many of us imagine — a nefarious, impossibly technical twilight world forever beyond our ken?
Not really.
When you consider that you can go to Google right now and enter a search string which will return you thousands of usernames and passwords to websites, you realize that this dark science is really no mystery at all. You'll react similarly when you see just how simple a concept SQL Injection is, and how it can be automated with simple tools. Read on, to learn the basics of how sites and web content management systems are most often hacked, and what you can do to reduce the risk of it happening to you.
SQL Injection
SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.
When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.
The Simple SQL Injection Hack
In its simplest form, this is how the SQLInjection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.
Suppose we enter the following string in a Username field:
' OR 1=1 double-dash-txt.png
The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:
SELECT * FROM users WHERE username = ?USRTEXT '
AND password = ?PASSTEXT?
…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.
So entering `OR 1=1 — as your username, could result in the following actually being run:
SELECT * FROM users WHERE username = ?' OR 1=1 — 'AND password = '?
Two things you need to know about this:
['] closes the [username] text field.
'double-dash-txt.png' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:
SELECT * FROM users WHERE username = '' OR 1=1
1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.
Let's hope you got the gist of that, and move briskly on.
Brilliant! I'm gonna go hack me a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank, evidently.
But the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines:
username field examples:
* admin'—
* ') or ('a'='a
* ”) or (“a”=”a
* hi” or “a”=”a
… and so on.
Backdoor Injection- Modules, Forums, Search etc.
Hacking web forms is by no means limited exclusively to login screens. A humble search form, for instance, is necessarily tied to a database, and can potentially be used to amend database details. Using SQL commands in search forms can potentially do some extremely powerful things, like calling up usernames and passwords, searching the database field set and field names, and amending same. Do people really get hacked through their search forms? You better believe it. And through forums, and anywhere else a user can input text into a field which interacts with the database. If security is low enough, the hacker can probe the database to get names of fields, then use commands like INSERT INTO, UNION, and so forth to get user information, change product prices, change account settings/balances, and just about anything else… depending on the security measures in place, database architecture and so on.
So you can have security locked down at the login, but poor security on other forms can still be exploited. Unfortunately this is a real worry regarding 3rd party modules for Web CMS products which incorporate forms, and for CMS products these 3rd party modules are often the weakest links which allows hackers access to your database.
Automated Injection
There are tools to automate the process of SQL Injection into login and other fields. One hacker process, using a specific tool, will be to seek out a number of weak targets using Google (searching for login.asp, for instance), then insert a range of possible injection strings (like those listed above, culled from innumerable Injection cheat-sheets on the Web), add a list of proxies to cover his movements, and go play XBox while the program automates the whole injection process.
Remote Injection
This involves uploading malicious files to inject SQL and exploit other vulnerabilities. It's a topic which was deemed beyond the scope of this report, but you can view thisPDF if you'd like to learn more.
SQL Injection in the Browser Address Bar
Injections can also be performed via the browser address bar. I don't mean to have a pop at Microsoft, but when it comes to such vulnerabilities, HTTP GET requests withURLs of the following form are most often held to be vulnerable:
http://somesite.com/index.asp?id=10
Try adding an SQL command to the end of a URL string like this, just for kicks:
http://somesite.com/index.asp?id=10 AND id=11
See if both articles come up. Don't shoot your webmaster just yet if it's your own site and you get two articles popping up: this is real low-level access to the database. But some such sites will be vulnerable. Try adding some other simple SQL commands to the end of URLs from your own site, to see what happens.
No comments:
Post a Comment