By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
When you log into the site, look at the URL. Do you see something like:
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.
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.
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:
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.
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!