Quick attacks for Web security, penetration testing and SQL advisory

Are you in need of penetration testing but are on a strict budget? Expert Matt Heusser provides tips and tricks to get your software application live and without issues. Learn beyond the basics of penetration testing and learn how to overcome SQL injection flaws in this tip.

Software Tester Matt Heusser
A project team under pressure may fall into the trap of seeing the go-live, or "flip of the switch", as the ultimate goal of the project. However, experts will tell you security should be considered from the beginning; that it should be included early in the lifecycle with issues like System Hardening and Threat Modeling. In order to assess whether an application is vulnerable, one thing to do is to begin a series of quick security attacks against the software; to go through a sort of checklist. What follows are descriptions of some of the most common Web security defects - including techniques on how to test for and fix them. After reading this article, you'll be able to jump on a keyboard and uncover security defects before a hacker finds them and takes advantage of those vulnerabilities.

SQL Injection
Most of the time you see a login, password, and submit button, there is a database somewhere, building a query something like this:

select userid from user_table where username='first_param' and password='second_param';

If the query (question) returns a userid, you are logged in as that user.

The easiest way for programmers to do this is to take the parameters and combine everything in one variable. That means if you typed something like this in the password field:

pwd' OR 'hello'='hello

It will be interpreted as this:

select userid from user_table where username='first_param' and password='pwd' OR 'hello'='hello';

Because hello is hello, the software will pull back a match. In many cases, you can use a semi-colon and insert additional code, as this classic web comic illustrates:

If password of:

pwd' OR 'hello'='hello

logs you in, you've got a SQL injection problem. Your developers can fix it relatively easily by forcing the inputs to be only parameters rather than calculating a raw string.

URL Guessing

When you log into the site, look at the URL. Do you see something like:

http://www.mysite.com/page/account=124467

That 124467 is likely your account. You likely aren't supposed to be able to see other people's accounts; but change the numbers and hit return. If you can see someone else's accounts, that's a problem. Likewise, any time there is a transaction (say a book order), look at the fields. Do they contain a dollar amount or a discount percent? You guessed it. Or try deleting your account and looking at the URL; could you use those variables to delete someone else's account? The possibilities are limitless.

Another, related term to URL guessing is 'escalation of privilege', because it is possible for us to do things we aren't expected to do my manipulating the submit.

Cross-Site Scripting (xss) - embed javascript
One of the neat, interactive features of the web is the ability for other people to add to our applications to create conversations. We've been doing it since Guestbooks, but today with MySpace, Twitter, and FaceBook, we might even say the application is the user generated content. To a point, that's great.

But it's also another entry point for malicious code. Thanks to javascript, some 3rd party user can now popup a new window that could install a virus or trojan horse.

How do you test for xss? My favorite example is from my friend David Christiansen, who recommends using this code on every input that gets saved and rendered:

<script>alert('f')</script>

That's right; it's a trivially small piece of javascript designed to render a popup. If you click save on some fields, then view that page and 'f' pops up or you see the alert without the script tags, you've got a xss vulnerability. If you see the text rendered funny, like > or < , then the application has a regular bug dealing with special characters.

A Cross Site Scripting, or xSS vulnerability, means someone can put code (javascript in this case) on your pages to be viewed by someone else. That means they can pop-up their website - or pop-up code that downloads a virus - or anything else. Once a hacker can run his own javascript on your browser, he has control of it. In other words, if the pop-up of 'f' appears, it's a proof of concept that it's the least of your worries.

Https and SSL
When we order products from Amazon or Buy.com, we see the url in the upper-left changing from http to https - and perhaps the secure lock of the SSL icon. Those are good, and your application likely has them - or does it? If it doesn't that's a problem.

Even if the transaction is secure, the next question is when does it start to be secure? If that is after login, then someone sniffing the wire can find out the username and password relatively easily.

How do you do that? With a packet sniffer; Wireshark is a good free tool. If you work wireless office, or one with 'switches' which send all the data down the wire, you can use a tool like wireshark to find out exactly what information is being sent in the free and clear.

The Hack Fest
Between SQL Injection, URL Tampering, Cross Site Scripting, and packet sniffing, you can do a fair amount of testing in about an hour. At the end of your lunch hour, you could have found enough bugs to justify a serious conversation with management -- or, possibly, enough to have some confidence in your team. That is an end of sorts, but it doesn't take much to move beyond these into serious network security.

Where to go for more
We've barely scratched the surface; two more easy quick attacks to google are port scans and denial of service attacks. Beyond that, allow me to suggest some books: Whittaker and Thompson's How to Break Web Software provides a number of quick cheap and quick attacks for web applications, as does the HackNotes series of books.

Books do tend to go out of date quickly, so web-based resources are often the most effective. WebGoat is a free, open-source training environment designed to teach penetration testing, and the canonical XSS cribsheet provides much more details and subtleties in cross-site scripting.

The Open Web Application Security Project (oWasp) is a free public resource for testing and securing websites. The oWASP top ten is a list of the most common security defects in web applications.

No, you won't become a penetration tester overnight. I hope by now, though, it's clear that penetration testing is a skill that can be researched, practiced and learned, not some black art involving frogs and leeches. Now get out there and break the web!

This was first published in April 2010

Dig deeper on Mobile Application Testing Techniques and Tools

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close