The other day I asked if anyone had any topics they’d like to read on here. Someone suggested basic web security testing.
That’s a great topic, and an important one too.
Software is continuing to get more complex. More complexity equals more attack surface, and it seems like we hear about data breaches every couple months.
Peoples’ personal data becomes at risk, functionality gets exposed, problems happen.
Why Test Security? Isn’t That Someone Else’s Job?
It can be. Some companies are big enough that they can have a standalone team to perform security testing.
But even if you’re not working at a place like that, it’s good to know a bit about how to find these kinds of bugs yourself.
Testers who know a broader variety of bug types to find are a ton more valuable than ones who know how to do only functional testing.
Where Do Security Bugs Even Come From?
Again, software complexity plays a huge part.
Because software is so big, it often requires multiple people to produce software in-house. It’s easy to miss details when one person is handing off software to someone else, or because deadlines cause a time crunch.
Lack of understanding written code is also a contributing factor. When people don’t understand code, they may either mess up adding/modifying the code, or they just say, “(╯°□°)╯︵ ┻━┻” and rewrite/refactor the code.
Either action can introduce security bugs–removing code not understood to be protective, or rewriting a “simpler” version which excerpts secure code in favor of simplicity.
Sometimes it’s the fault of 3rd party software. Code has to get written fast enough that maybe it’s better and/or cheaper to let another tool or application do the heavy lifting. Except for when it’s not. If the 3rd party doesn’t have great security, that’s a liability.
There are many, many ways security bugs can be introduced. Now, how to find some of them.
What Kinds of Testing Can Be Done?
Three kinds I want to talk about are Cross-Site Scripting (XSS), SQL Injection and DOM Manipulation.
These are great ones to start with, because many times, you’ll be able to see right away if they’re working or not.
Cross-Site Scripting (or XSS) is an attack method which allows you to use a website to execute whatever kind of code you want. Anytime you have a website that has any public-facing interface, those are good places to try this.
Let’s say for example, you have a login page–username and password text field, and a Login button. An XSS attack string would look like this:
\<script\>alert("xss attack yay!!")\<\/script\>
(Well shoot. So I can’t get the tags to look right, so I had to mangle them. It’s supposed to be a script tag around that alert statement. Sorry.)
If this is submitted in a text field, and you get a popup saying “xss attack yay!!” then you’ve successfully pulled off an XSS attack.
What’s happening is: the webpage is not distinguishing between text and code. It’s blindly executing code when it finds it, in the script tags. In this case, the code being executed is something simple that throws a popup up, but this is enough of a test to show that the input data isn’t being sanitized properly.
And potentially millions of people can exploit this.
Sometimes, code tries to sanitize against this, but even then, there may be ways around it.
The code may know to get rid of all instances of script tags, but what about <ScRiPt>? Or if you send in <scr<script>ipt>, and the inside script tag is removed, you get left with a script tag anyway. Pretty sneaky.
Databases are a fact of life in software development. We need a way to store all the information that’s used across applications.
The security problem with databases is, the code accessing them sometimes takes data input at face value. So you might see code that looks like this:
SQL_QUERY = "SELECT " + getUsername() + " FROM USERS";
For the login example above, a common approach would be to put in a string of data that looks like part of a SQL query, and comment out the rest of the query that would normally be executed.
If you put this for the username:
* FROM ADMINUSERS;--
This would result in a query that looks like this:
SELECT * FROM ADMINUSERS
Because you put in a string that contains a comment token (“–“), then this will comment out the rest of the query that normally would have pulled rows from the USERS table.
Pretty cool huh?
An extremely simple way to check for whether any sanitation is going on, is to enter a single apostrophe into whatever field is vulnerable. If this were the username field from earlier, then the SQL statement would look like this:
SELECT ' FROM USERS
…which is bad grammar. You’d see some error get thrown up, which lets you know you might be able to make complex queries to poke around the tables for neat info, or drop the tables completely. Depending on what error you get, you will be able to tell what kind of database is being used, too.
DOM Manipulation is actually less straightforward than the other two. But, you don’t need any special tools other than a browser (Firefox or Chrome–I don’t think this works for IE).
DOM stands for Document Object Model. It’s basically an XML representation of a webpage.
As far as how to manipulate the DOM, I’ll refer you to a post I wrote awhile back, so you can see how it’s done.
But, as I said, this isn’t as straightforward as other attack types. It really depends on what data is provided to you in the DOM, what the underlying code does with the data itself, and whether you can get anything useful from it.
Here’s an example though: One time at a client, I noticed that some orders placed for information under my test account had a piece of data that looked like a consecutive 8-digit number.
I also had access to another account, to see what those orders looked like, and I saw similar 8-digit numbers. There was a feature to have the information from one of my orders re-sent to my email address, but that feature also used one of those 8-digit numbers.
Using DOM manipulation, I changed my number to a number in the other account, and sent the request. That other person’s information showed up in my mailbox.
(Oh, and the other account was the manager’s. They fixed that bug real quick. 🙂 I wasn’t picking on the manager, just did it for the lulz.)
The reason why this worked is because the server that sent those 8-digit numbers out, assumed that the data received was correct. It wasn’t, but then it acted on the data it was given. Result was, I had access to information I shouldn’t have had.
This is just a sampling of what kinds of testing you can do on the security side. There aren’t many hybrid testers that know how to test and who have security in mind. It’s definitely an interesting career path.
There’s actually a great book I’ll recommend called The Web Application Hacker’s Handbook, which I think is a great misnomer for this book because it weighs like 2 pounds. But it is packed FULL of different attack methods and serves as a wonderful reference.
Have fun and happy hacking!