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