home about topics archives sitemap advertise

Content Management Matters ™

Subscribe to Feed Subscribe by Email

• News
• CMS Products
• Reviews
• Features
• Resources
• Job Board

Home > Archives > Web CMS Stay Informed

Newsletter: Subscribe
Add Feed
Follow Twitte
Article Topics
· Enterprise CMS
· Web CMS
· Micro CMS
How They Hack Your Website: Overview of · Web Publishing
· Enterprise 2.0
Common Techniques · Web Content
By John Conroy · Social Media
Mar 5. 2008 · Mobile
Tagged: google hacking hack security web cms web publishing xss
We hear the same terms bandied about whenever a popular
site gets hacked. You know… SQL Injection, cross site scripting, that Coming Events
kind of thing. But what do these things mean? Is hacking really as Gilbane CMS
CM Europe (CME)
inaccessible as many of us imagine; a nefarious, impossibly technical ECM 365
twilight world forever beyond our ken? EMC Plaza
...more events
Not really.
When you consider that you can go to Google right now and enter a Archives
search string which will return you thousands of usernames and · November 2008
passwords to websites, you realize that this dark science is really no · October 2008
mystery at all. You’ll react similarly when you see just how simple a · September 2008
· all archives
concept SQL Injection is, and how it can be automated with simple
· all topics
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. CMSWire
Is published by
Simpler Media
SQL Injection Group. More »

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.

SPONSORSHIP

CMSWire speaks to a specific audience of professionals and opinion makers focused on content
management, publishing and collaboration.
Advertise here.
The Simple SQL Injection Hack
In its simplest form, this is how the SQL Injection 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
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.
‘ ’ 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 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 have a pop at Microsoft, but when it comes to such
vulnerabilities, HTTP GET requests 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 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.
As we saw above, access to the database raises a number of
interesting possibilities. The database structure can be mapped by a
skilled hacker through ill-conceived 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 additional data.
Revealing error messages are manna - they can carry invaluable table
name and structural details.
The following illustrative string is from Imperva.
http://www.mydomain.com/products/products.asp?productid=123
UNION SELECT username, password FROM USERS
There are vast swathes of information on SQL Injection available, here
are a couple 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 particularly difficult to stop. Microsoft,
MySpace, Google… all the big cahunas have had 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, which are used to hijack sessions, hijack ads in applications
and steal personal information.
Picture the scene: you’re there flicking through some nameless bulletin
board because, yes, you really are that lazy at work. Some friendly girl
with broken English implores you to get in touch. ‘Me nice gurl’, she
says. You’ve always wondered 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 right now is to see an ad for cheap Cialis. Maybe the linked
page satisfies this craving, 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.

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 video.

Authorization Bypass
Authorization Bypass is a frighteningly simple process which can be
employed against 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 Bags 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 this:
• 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 process on YouTube. This was done against a small university’s
website. It’s a two-minute 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 attacks. Google hacking will primarily be used for finding sites
with vulnerabilities. If a hacker knows that, say, SQL Server 2000 has
certain exploits, and he knows a unique string pushed out by that
version in results, you can hone in on vulnerable websites.
For specific targets Google can return some exceptionally useful
information: full 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 dumps as well (fooling around
with a Google hack while preparing this article, I stumbled across a
dump for a top-tier CMS developer’s website). And a vast amount
more besides.
johnny.ihackstuff.com is the man to go to for Google hacks. One
interesting one I toyed with invited me to the Joomla! install page for
dozens of sites… people who had uploaded Joomla!, decided against
installing it, and subsequently had either left the domain to rot, or else
set a redirect on the page to, say, their Flickr account (in one case).
Allowing anybody to walk in and run through the installer. Other query
strings target unprotected email/IM archives, and all sorts of very
sensitive information. What fun we can have!

Password Cracking
Hashed strings can often be deciphered through ‘brute forcing’. Bad
news, eh? Yes, 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 XWE42GH64223JHTF6533H 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 and similarly encoded passwords.

A Few Defensive Measures

• If you utilize a web content management system, subscribe to
the development blog. Update to new versions soon as
possible.
• Update all 3rd party modules as a matter of course — any
modules incorporating web forms or enabling member file
uploads are a potential threat. Module vulnerabilities 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 ‘Flowers.php’ or something, instead of
“AdminLogin.php” etc.?
• Enter some confusing data into your login fields like the sample
Injection strings 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 betray
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, it rhymes.
UPDATE
I had posted a link here to a hacking bulletin board containing
specific sql injections strings etc. The link pointed to a page
which listed numerous hacks targetting various CMS platforms,
but containing a disproportionate number of hacks for one
platform in particular. In retrospect, and following a specific
complaint, I have pulled down this link. Apologies to the
complainant and to anyone else who found this link to be
inappropriate.
Was this article useful?
Email a Friend Digg It ShareThis

Read more breaking news:

• Day Software's New CQ5 Web CMS Has Arrived
• eZ Publish Open Source CMS Heads to SaaS
• Sprout's New Flex-based Widget Tracked by Google Analytics
• Finalists Announced at Adobe Max Awards 2008
• Bringing Interactive Mobile Video Advertising on Stream
• Tomoye Advances Communties for MOSS
• Collaboration for Linux Users Just Got Easier
• KazForensics: Forensics for Improved eDiscovery
• Clickability Evolving Web Content, One Solution At a Time
• Enterprise Ain't Going Into the Cloud?

Comments
I appreciate that you've presented this information in a form that less
tech-savvy users can understand. However, there are a few issues I
have as a professional programmer with some of the solutions
presented.

Primarily, you make SQL injection sound like a magical breakthrough

that requires some military-grade security architect to circumvent it.
SQL Injection can be properly stopped simply by properly escaping
your data. In an SQL string, if you wish to represent quotation marks,
it must be escaped with a backslash (\' instead of ' or \" instead of ")
to differentiate it from a quotation mark that would end the string.
This is an oversimplification and there are other rules, but the point is
that most web scripting languages have functions that you can pass a
string through to avoid the leak. In PHP, this is
mysql_real_escape_string. Essentially, for each SQL query that allows
any input by the user, escape that information. Also, another thing that
I've found useful is to convert input data to integers when I am putting
numbers into a query. For example, in the query SELECT * FROM
`users` WHERE `id`=1, the 1 does not have quotes around it, so it is
possible still to perform an SQL injection attack even with properly
escaped data. Converting the id to an integer before it is injected will
mitigate that. What Citi and other online banking sites do is not magic,
it's just good programming practice.

Also, your first two defense measures suggested updating versions 'as
soon as possible.' In general, unless a patch is specifically fixing a
large security error, this is not a good idea, because new code
introduces new vulnerabilities. If you updated your codebase simply
because a new version came out, what are you going to do if a major
exploit is found in the new version two days later? It's better to wait a
little to be sure that the new version is stable, especially if valuable
information is at stake.

On the topic of password cracking, one common programming practice

is to use a 'salt' on whatever password is being encrypted.
Hypothetically, when you come to XYs site and log in with the
password 'password', and they're using MD5 encryption without using
a salt, your password will be checked against the MD5ed version of
'password'... however, lets say they have a pseudorandom salt of
'Mt5y4r'. When you log in with 'password', this salt is added to your
string, so it is now 'passwordMt5y4r' that is being encrypted and
checked against the database. This simply means that if a hacker gains
access to the password table it will take much longer for a crack to
work, because they are not finding the reverse of 'password' (which
would be an easy dictionary crack.) There are other benefits, and even
more secure ways of implementing a salt, and
http://en.wikipedia.org/wiki/Salt_(cryptography) can explain it better
than I can.

Thanks for your time.. this is not meant to be overly critical, this
article is good overall, just trying to help out! :)

Posted by: Jason on March 9, 2008 2:53 AM

Trackback from "Best resources for Web developers and designers"

( http://impressionsoft.blogspot.com/2008/03/best-resources-for-web-
developers-and.html )

Posted by: ccchai on March 9, 2008 4:26 AM

Very useful info! Posting a link to this.

Posted by: BedriftsGuiden blog on March 9, 2008 7:30 AM

That is exactly why i use a protection modules on my web site. I

reviewed a few and went on with dotDefender for IIS.

My two cents.

Posted by: Steph G on March 9, 2008 9:57 AM

If you're doing "SELECT * FROM users WHERE username = ‘USRTEXT ’

AND password = ‘PASSTEXT’" to authenticate, you've got all kinds of
problems. Most importantly, it means you're storing unencrypted
passwords in your database. That's even worse than SQL injection!
Our operating systems have had salted, encrypted passwords for
decades, and they're really easy to implement -- there's no excuse for
not knowing about them.

Posted by: tim on March 9, 2008 3:09 PM

very useful... thanks.

Posted by: a on March 9, 2008 3:50 PM

Thanks everyone. And great feedback Jason -- thanks for taking the
time. On the subject of updating modules, yes: perhaps it's better to
say that you should "update your modules", rather than say that it
should be done ASAP.

Posted by: John Conroy on March 10, 2008 8:10 AM

Thanks for a good read. You're the first one I've come across that was
able to explain XSS for the simple concept that it is.

Posted by: Carl B on March 10, 2008 4:18 PM

Great article. But wonder how many of guys see this and close the
holes. Well...it worked most of the time.

Posted by: Jay on March 19, 2008 1:59 AM

We want partnership & advertisement with u

Our concept is
New Internet tricks & techniques

First time in world whole keyboard is booked by AtoAll.com ( angle)for

easy search. Type two times any three letters which are together on
the keyboard (right to left) e.g. mmnnbb ctrl+enter for quick Web
Search. This option is working from whole keyboard.

Posted by: Sanjeev on March 21, 2008 12:18 AM

Could you call it 'cracking' and not 'hacking'? For instance, I hack the
GNU core utilities to improve them, this involves no wrong doing and
helps my neighbor.

Please stop saying 'hacking' when wrong doing is implied, else GNU
and Kernel hackers will have to come up with a new term. This would
be sad, as our motivation to do what we did was to help our hacker
community.

I don't care what using 'hacking' does for you SEO, consider the
damage that your doing to the community that built the OS that
powers this blog.

You might enjoy reading this:

http://www.gnu.org/philosophy/rms-hack.html

Its an interview with RMS (the guy who wrote gcc and the core utilities
that you now call 'Linux').

Cheers,
--Tim

Posted by: tinkertim on April 2, 2008 6:54 AM

Great article , really enjoyed it. The information is rather basic but I
hope all the webmasters reading this have closed any holes. It amazes
me how many sites lack any real security !

Posted by: ACE-KING on April 7, 2008 2:16 PM

tinkertim: duly noted.

Posted by: john conroy on April 14, 2008 10:50 AM

usefull info..need to share

Posted by: hafiz@dungun on April 15, 2008 4:33 AM

Wow, thanks for explaining the process to a non tech. I have heard of
sql injection before but didn't quite understand what it really was
before reading your article.

Posted by: Anon on May 11, 2008 11:01 PM

Great article. Lots of good information. I have inherited two Classic

ASP/SQL 2000 web sites that have been subject to constant brutal
hacking. They were poorly coded to begin with and it has been a chore
getting them updated. What seems to work for me for the SQL
injection, or at least the type these sites were subject to (domain/URL)
has been creation and use of a 'read only' user with stored procedures.
That way the only code that can be written is what is allowed by the
stored procedure. Insert, update, delete and many other commands
are not allowed. I also created custom error pages and forced all query
strings to be int, so there cannot be any way to get SQL data (that I
know of). I also remove scripting and html from text boxes on all
forms.

This seems to have worked just fine so far, after months of constant
backing up and restoring at least once a week on both sites, they
haven't been hacked in a month, although I am logging attempts and
there have been many.

Anyway well written 101 article and thanks for the info!

Posted by: Bard on May 24, 2008 3:19 PM

Good description mate...! Very well explained ..

Posted by: Hami on June 30, 2008 7:16 PM

Nice Info!

Posted by: Teng on July 16, 2008 4:30 AM

it is really good useful,

Thanx a lot...

Posted by: bhushan on August 20, 2008 11:20 AM

For the "Authorization Bypass" section, you do not even need to save
the HTML source anymore. You can make modifications on the page if
you run plugins such as Firebug on Firefox. Even the HTTP-Referer
header will be correct!

Posted by: Retag on September 1, 2008 10:18 PM

there is no information to login avoiding get_magic_quotes_gpc()

Posted by: Fahim on September 29, 2008 12:52 PM

i am not eable to open orkut bec in our collage there is url or page has
been bloked.
Posted by: dhavni on October 13, 2008 4:59 AM

Good article, hehehe...i can start hacking websites now :p

Posted by: A Mohamad on October 13, 2008 9:10 AM

Very useful info.

Please tell me how to brute 3 web forms (username, passwd, and

form3). Most tools have 2 input form which are only username and
password. Please help, just a newbie.

Posted by: Jayson on October 15, 2008 7:45 AM

easily explained... hard to be d0ne... :p

Posted by: jun on October 23, 2008 1:41 AM

Just one quick question:

If you wanted to bring up two articles, I don't think
http://somesite.com/index.asp?id=10 AND id=11
would work, because no article has an id 10 and an id of 11 (unless
there's some dodgy database schema going on).

Shouldn't it be id=10 OR id=11?

Posted by: James Lawrie on November 3, 2008 4:16 PM

Great article on how people hack sites. Really informative.

Posted by: http://freemoneypayments.blogspot.com/ on November 3, 2008 7:05 PM

True for ya James -- good point-- should be OR

Posted by: john conroy on November 7, 2008 9:02 AM

i want to hack it completly.....

Posted by: deepak on November 11, 2008 2:59 PM

Excellent article and wonderful feedback from all. Very refreshing and
simplified.

Posted by: Soumik on November 11, 2008 4:27 PM

Speaking as a pseudo-knowledgeable user, I appreciated the
article...its middle-of-the-road tech language should be considered the
standard that all may partake.

Posted by: Daryl James on November 16, 2008 6:17 PM

Add a Comment

Name: Email:
Web Site:
Comments:
Security Code:
Remember me? Yes No

Get a New Job! (View All | Feed | Post a Job)

• Senior Web Developer at Trapeze

• ActionScript Engineer (ActionScript Assassin) at Meebo
• Software Chameleon at BorderStylo
• Web UI Developer at GETCO
• Copywriter at Navajo Company Inc.
• Principal Technical Architect at TandemSEVEN
• EMC/Documentum content management Architect at Urpan
Technologies, Inc.
• Technical Artchitect at Frog Design
T h i s s i t e i s p o s s i b l e v i a g e n e r o u s s u p p o r t f r o m C y l o g y,
Inc. - Content Management (CMS) Consultant

Copyright © 2003-2008 Simpler Media Group, LLC. Some

rights reserved.
I postponed my immigration plan because of some my personal reasons it is request to
you kindly send decided money by western union