SQL Injection

SQL Injection involves entering SQL code into web forms, eg. login fields, or in
to the browser address field, to access and manipulate the database behind the s
ite, system or application.
When you enter text in the Username and Password fields of a login screen, the d
ata 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 m
atches table/row data, you're granted access (in the case of a login screen). If
not, you're knocked back out.
Your Ad Here
The Simple SQL Injection Hack
In its simplest form, this is how the SQL Injection works. It's impossible to ex
plain 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 --
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 we
b form.
So entering `OR 1=1 as your username, could result in the following actually bei
ng run:
SELECT * FROM users WHERE username = ' OR 1=1 'AND password = '
Two things you need to know about this:
['] closes the [username] text field.
'--' 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.
But the process does serve to illustrate just what SQL Injection is all about in
jecting 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 comm
on 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 potentiall
y be used to amend database details. Using SQL commands in search forms can pote
ntially do some extremely powerful things, like calling up usernames and passwor
ds, searching the database field set and field names, and amending same. Do peop
le really get hacked through their search forms? You better believe it. And thro
ugh 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/balance
s, and just about anything else depending on the security measures in place, data
base architecture and so on.
So you can have security locked down at the login, but poor security on other fo
rms can still be exploited. Unfortunately this is a real worry regarding 3rd par
ty modules for Web CMS products which incorporate forms, and for CMS products th
ese 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 fi
elds. 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 innu
merable Injection cheat-sheets on the Web), add a list of proxies to cover his m
ovements, and go play XBox while the program automates the whole injection proce
ss.
Remote Injection
This involves uploading malicious files to inject SQL and exploit other vulnerab
ilities. It's a topic which was deemed beyond the scope of this report, but you
can view this PDF 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 ha
ve a pop at Microsoft, but when it comes to such vulnerabilities, HTTP GET reque
sts with URLs 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 o
wn site and you get two articles popping up: this is real low-level access to th
e 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.
As we saw above, access to the database raises a number of interesting possibili
ties. The database structure can be mapped by a skilled hacker through ill-conce
ived visibility of error messages this is called database footprinting and then
this knowledge of table names and so forth can be used to gain access to additio
nal data. Revealing error messages are manna - they can carry invaluable table n
ame and structural details.
The following illustrative string is from Imperva.
http://www.mydomain.com/products/pro...?productid=123 UNION SELECT username, pas
sword FROM USERS
There are vast swathes of information on SQL Injection available, here are a cou
ple of good sources:
* GovernmentSecurity.org
* SecurityDocs.com
Cross Site Scripting (XSS)
XSS or Cross Site Scripting is the other major vulnerability which dominates the
web hacking landscape, and is an exceptionally tricky customer which seems part
icularly difficult to stop. Microsoft, MySpace, Google all the big cahunas have h
ad problems with XSS vulnerabilities. This is somewhat more complicated than SQL
Injection, and we'll just have a quick look to get a feel for it.
XSS is about malicious (usually) JavaScript routines embedded in hyperlinks, whi
ch are used to hijack sessions, hijack ads in applications and steal personal in
formation.
Picture the scene: you're there flicking through some nameless bulletin board be
cause, yes, you really are that lazy at work. Some friendly girl with broken Eng
lish implores you to get in touch. 'Me nice gurl', she says. You've always wonde
red where those links actually go, so you say what the hell. You hover over the
link, it looks like this in the information bar:
[%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7 ]
Hmmm what the hell, let's give it a bash, you say. The one thing I really need rig
ht now is to see an ad for cheap Cialis. Maybe the linked page satisfies this cr
aving, maybe not. Nothing dramatic happens when you click the link, at any rate,
and the long day wears on.
When a link in an IM, email, forum or message board is hexed like the one above,
it could contain just about anything. Like this example, from SandSprite, which
helps steal a session cookie, which can potentially be used to hijack a session
in a web application, or even to access user account details.
cookiegrab.png
Stealing cookies is just the tip of the iceberg though XSS attacks through links
and through embedded code on a page or even a bb post can do a whole lot more,
with a little imagination.
XSS is mostly of concern to consumers and to developers of web applications. It'
s the family of security nightmares which keeps people like MySpace Tom and Mark
Zuckerberg awake at night. So they're not all bad then, I suppose
For additional resources on this topic, here's a great overview of XSS (PDF) and
just what can be accomplished with sneaky links. And here's an in-depth XSS vid
eo.
Authorization Bypass
Authorization Bypass is a frighteningly simple process which can be employed aga
inst poorly designed applications or content management frameworks. You know how
it is you run a small university and you want to give the undergraduate students
something to do. So they build a content management framework for the Mickey Ba
gs research department. Trouble is that this local portal is connected to other
more important campus databases. Next thing you know, there goes the farm
Authorization bypass, to gain access to the Admin backend, can be as simple as t
his:
* Find weak target login page.
* View source. Copy to notepad.
* Delete the authorization javascript, amend a link or two.
* Save to desktop.
* Open on desktop. Enter anything into login fields, press enter.
* Hey Presto.
Here's a great video of a White Hat going through the authorization-bypass proce
ss on YouTube. This was done against a small university's website. It's a two-mi
nute process. Note that he gets into the User 1 account, which is not the Admin
account in this case. Is Admin User 1 on your User table?
Google Hacking
This is by far the easiest hack of all. It really is extraordinary what you can
find in Google's index. And here's Newsflash #1: you can find a wealth of actual
usernames and passwords using search strings.
Copy and paste these into Google:
inurl : passlist.txt
inurl : passwd.txt
and this one is just priceless
login: * password= * filetype:xls
Such strings return very random results, and are of little use for targeted atta
cks. Google hacking will primarily be used for finding sites with vulnerabilitie
s. If a hacker knows that, say, SQL Server 2000 has certain exploits, and he kno
ws a unique string pushed out by that version in results, you can hone in on vul
nerable websites.
For specific targets Google can return some exceptionally useful information: fu
ll server configurations, database details (so a good hacker knows what kind of
injections might work), and so forth. You can find any amount of SQL database du
mps as well (fooling around with a Google hack while preparing this article, I s
tumbled across a dump for a top-tier CMS developer's website). And a vast amount
more besides.
Password Cracking
Hashed strings can often be deciphered through 'brute forcing'. Bad news, eh? Ye
s, and particularly if your encrypted passwords/usernames are floating around in
an unprotected file somewhere, and some Google hacker comes across it.
You might think that just because your password now looks something like XWE42GH
64223JHTF6533H in one of those files, it means that it can't be cracked? Wrong.
Tools are freely available which will decipher a certain proportion of hashed an
d similarly encoded passwords.
A Few Defensive Measures
* If you utilize a web content management system, subscribe to the development b
log. Update to new versions soon as possible.
* Update all 3rd party modules as a matter of course any modules incorporating w
eb forms or enabling member file uploads are a potential threat. Module vulnerab
ilities can offer access to your full database.
* Harden your Web CMS or publishing platform. For example, if you use WordPress,
use this guide as a reference.
* If you have an admin login page for your custom built CMS, why not call it 'Fl
owers.php' or something, instead of AdminLogin.php etc.?
* Enter some confusing data into your login fields like the sample Injection str
ings shown above, and any else which you think might confuse the server. If you
get an unusual error message disclosing server-generated code then this may betr
ay vulnerability.
* Do a few Google hacks on your name and your website. Just in case
* When in doubt, pull the yellow cable out! It won't do you any good, but hey, i
t rhymes.