How It Started

Not long ago, security testing (and its equally scary cousin, penetration testing) was a big scary thing best left to those who understood it and got paid lots and lots of money to actually do it. Then life happened and I found myself accidentally stumbling across some things that could have been very expensive for my employer if I hadn't caught them.

Suddenly I was learning more about the pointy end of security testing than I'd ever thought I'd need, and it was exhilarating, fascinating, and terrifying, more or less in equal measure.

I felt a bit like this:

As I learned more about security testing, I found it wasn't quite as scary or overwhelming as all that. I started to understand what it meant when people talked about privilege escalations, or compromised servers, or…

There's a lot to learn. But it's not hard to get started, and with a bit of reading and forethought you can possibly catch a vulnerability (a piece of code that someone with Evil Intent can abuse to do things they shouldn't) before the software is mature enough to go to the expensive security professionals (which means it will cost less to fix - bonus, right?) and well before it finds its way out into the lawless frontiers of the Wild Wild Wes… ahem the World Wide Web.

Do I Really Need To Know This?

There are many who would say that all testers should know about web security testing. While knowing more about web security is a good idea for anyone who spends time online, I think there are situations where you may not need to know anything about web security testing.

You Probably Don't Need To Know About Web Security Testing If…

• You're part of a big team that already has security experts. That's their bailiwick, and if they're doing their job properly, they'll be working with you and your developers to make sure everything has the right level and kind of security for its purpose as well as helping you test it for any security problems.
• You're testing software that gets pushed out to users then nobody cares what they do with it because it doesn't talk to your servers or touch confidential information. An offline sudoku app is a good example here - and if your company doesn't care whether high scores are fake or not and/or protects its servers well, an online casual game can be too.
• It's a display only website and you don't manage the web hosting.
• You don't work on web software

You Do Need To Know About Web Security Testing If…

Your company's software stores any kind of personally identifiable information (this is defined by law, but as a general rule if it can be used to locate you or your family, it counts)

• Examples include address, email address (usually in combination with other information), government-issued identification such as United States Social Security Number, driver's license number, passport number…

Your company's software uses or stores any kind of payment information. If you store credit card information there are strict rules about storage and access of the data in most parts of the world, along with very high costs of failing to protect that data. If you're storing bank account information, the standards aren't as strict, but you still need to be careful with it.

Your company must follow data security laws or procedures. Some examples I know of are:

• Medical companies in the U.S. have a lot of Federal laws they have to follow.
• Any publicly traded company in the U.S. must comply with Federal laws about disclosure of breaches and data storage and retention.
• Companies that store or transmit credit card information must comply with PCI DSS standards. Failure to comply can see the company lose its ability to accept credit card payments in addition to fines and other penalties.

Your company has any kind of confidentiality requirement for the data it stores.

If you think you might need to know more about web security testing, then you probably do need to know more.

Getting Started

It's actually very easy to get started with web security testing, and there are some excellent references and tools out there that won't cost you anything but time. You can do a lot just with your browser.

Warning! Danger Ahead!

Before you do anything that could be destructive, make absolutely sure that you have permission to do this. Yes, even on a test server - there may be others using that server for other things; your company may have network monitoring for suspicious behavior; or there could be any number of other factors you as a tester know nothing about. Always, always make sure you have permission to hack before you start.

Free Tools

The tools I work with are all Windows-based because I work in a Windows environment. Some are cross-platform. Others are not. All of them are reasonably easy for a beginner to dip a cautious toe into the waters and see what they can find.

Browser developer tools - If your company hasn't blocked them, most modern browsers give you the ability to inspect web page code, step through JavaScript, and view network traffic between your browser and the server. You can also edit and run random JavaScript in them, try out code changes, and replay network requests.

If you don't already have them for cross-browser compatibility checking, install all the browsers that will work on your operating system. Each browser's tools are subtly different, and sometimes I'll see more in one than in another.

Postman - Despite being a Chrome extension, Postman runs as a standalone application. You can use Postman to send arbitrary requests and examine the responses (there's a theme here: pretty much anything you do in the way of security testing can be done multiple different ways. Experiment to find the ones you like best).

Fiddler - Telerik Fiddler is by far my favorite tool for examining web requests and responses and manipulating them. It's cross-browser and runs on multiple operating systems, and makes a nice simple starting point for security testing.

IronWASP - IronWASP is one of the few security scanners around that's both free and Windows-based. It's relatively easy to work with, and generally returns good results.

And More… - There's a wealth of tools available. I'm just getting started and I've hardly scratched the surface.

I'm going to focus on Fiddler from this point forward, because I've found it the easiest of the free tools to get comfortable with and the fastest to go from poking around the GUI to actually producing useful results.

Using Fiddler

I was playing with Fiddler when I stumbled over that big, potentially very expensive vulnerability I mentioned back in the introduction. It's a good thing I found it when I did: had it gone live, things could have been very nasty indeed.

Setting Up

I installed Fiddler with out-of-the-box defaults. On Windows, you get a plugin to Internet Explorer which lets you launch directly from IE (and you can set it to only monitor IE traffic much more easily than working with other browsers). Depending on what you're doing, some of the plugins can be particularly helpful: my favorites are

Syntax View/Highlight - Provides syntax highlighting for authoring customized scripts and reviewing HTML, Javascript, CSS, and XML. It makes digging through web code that much less painful when all the tags and keywords are color-coded. I'm a big fan of things that make it easier to focus on what matters, and this is one of them.

PDF View - This is essential if your application builds PDF files on the fly. You can click on a tab and see the PDF rendered. For instance, if you're testing a bank statement in PDF format to make sure you can't open another customer's PDF statement, this tool will help your testing.

Your First Fiddler Session

To start with, minimize anything that could confuse what you're seeing. Close down anything that talks to the network except one tab for a specific browser. I'm choosing IE because of the nice plug-in, and then launching Fiddler.

Go to the Filters tab, and enable filtering, then ensure that you're only showing traffic from your chosen browser. It should, in theory, be the only process of that browser running, but some of them, particularly on 64 bit systems can spawn multiple processes.This is the other reason I prefer IE with Fiddler. You click a checkbox and that's it. Done. IE traffic is all that you'll see.

If the web application you're working with doesn't have SSL set up in the test environments, do not turn on SSL decryption. Fiddler acts a proxy for all web traffic, so it can and will disrupt anything that communicates over the Internet. The disruption is much more… interesting if you're testing something delivered over SSL . Fiddler will create a self-signed certificate that sets off every browser warning of untrusted content under the sun. (It's hard to get more obvious than "DO_NOT_TRUST", but I'm sure someone could do it.) You'll find you can't access anything because of all the security warnings you're getting. This is one of the reasons all the professionals recommend working in virtual machines. Your regular system won't be affected while you're mangling the Internet profile of your virtual system.

Browse your application. You'll get a list of every single request that's made, and every response. This list is more comprehensive than you'll typically see from a browser network capture, and you get much nicer views into it. Pick one of the interesting looking requests, then take a look at the Inspectors tab.

All the tabs in the Request data tabs and the Response data tabs will have useful information on them depending on what you're looking at, but for now, have a look at the WebForms tab on the Request section.

Hidden fields, the cookie fields, as well as the things you filled in, are all there for you to see. This is one of the ways to look for Privilege Escalations (a type of security breach where a user is able to force the application to do something they don't have permission to do, such as a blog commenter being able to edit someone's posts).

First, go to the Composer tab on the top row of tabs. This one is the tab I use most often along with the Inspectors. Drag the highlighted request you were inspecting over to the Composer tab. The raw text of the request will be filled in, waiting for you to manipulate it.

Now you can edit any of the fields in the request body, or anything in the query string. Or you can replace the cookie with any other cookie you recorded in your browsing. Or delete it altogether. If you're testing something that can't be done if you aren't logged in, and you have an authentication cookie, try deleting the cookie in the Composer view, then submitting.

If you got back a status 200 OK response, then your next step is to check to see if you were able to change data despite the rules. Imagine what could happen if this was an online banking system - someone who can bypass the normal rules could transfer money out of your account. They could  change your password to something of their choosing, at which point it's game over because as far as the server is concerned, you're the one making the changes.

Other Things You Can Do

See what happens if you add something like these strings to any GET

<script>alert(document.cookie);</script>

%3Cscript%3Ealert(document.cookie)%3B%3C%2Fscript%3E

(These are simplistic examples, but if your team isn't all that experienced with secure code, they can work. It means someone could make a password prompt popup that lets them harvest usernames and passwords)

Follow XKCD's example with little Bobby Tables in any form fields

What You Can Find

The Open Web Application Security Project (OWASP) maintains a listing of their top ten web vulnerabilities. They are currently taking submissions for the 2016 list, but the 2013 list is still usable. Hackers will go for easy targets, so check to make sure those targets are protected. Next, I'll go through a few of the vulnerabilities in the list and how you can use Fiddler to test for them.

OWASP Top 10 - #1: Injection

Injection, is forcing a site to run code you put into it instead of it’s own code or along with it’s own code. It’s the number one vulnerability for a good reason. Anyone can do it with very little skill, and it can be immensely destructive.

The Composer tab in Fiddler lets you check for multiple types of injection by editing  requests you've already sent and changing the values of form fields or query strings. The Big List of Naughty Strings on GitHub is a wonderful place to start because it groups all its naughty strings by what kind of bad thing they can do.

OWASP Top 10 - #2: Broken Authentication and Session Management

This vulnerability happens when the way your application stores credentials lets people access secure data without forcing them to log on first. If you can reopen a closed tab and go directly to a web page that you should need to log in to get to, especially if you logged out before you closed the tab, you've got broken authentication or session management.

Testing for this with Fiddler is ridiculously easy. While you have Fiddler running, log on to the application, do something there that requires you to be logged on, then log off. Select the instance  which a login should be required, right click, and select Replay.

If session management is working properly, you should get a redirection to the login page, or a not authorized error. You should not ever succeed. This isn't that hard after all! You can expect some pushback from developers on this one if you find that it’s failing. Changing authentication and session management means reengineering the entire system, and if they're using sessions with a moderately short lifespan that may be considered enough by your organization.

OWASP Top 10 - #3: Cross-site Scripting (XSS)

Cross-site scripting, or XSS, is probably the single most common vulnerability in web sites according to the OWASP database. XSS is simply forcing a site to run Javascript that the attacker put there. This is one of the ways attackers get hold of real credentials. If they can make the server run Javascript to display a dialog asking you to re-enter your username and password, they can have that dialog email them your credentials while you, the victim, think the site was just being extra secure.

You can use Fiddler to see if your application is vulnerable the same way you'd look for any other kind of injection - using anything in the Script Injection section of the Big List of Naughty Strings (use blns.txt and start at line 268) to see what happens. If you get a Javascript Popup, you have an XSS vulnerability.

OWASP Top 10 - #7: Missing Function Level Access Control

This vulnerability is simply letting the browser decide what form fields to show, hide, or make read-only based on your level of access, and not doing the same set of checks when making changes. It's more challenging to find, but for any kind of web application where people are entering data and expecting their data to be secure, it's crucial to make sure the application checks the user has access rights when the data is displayed, and again when it's saved.

To check for this with Fiddler, you need to know your application well, and know what access is permitted to which users under what circumstances, and be able to access it in successive sessions with different users.

Log on as an admin user, and do something that only admin users are allowed to do. Make sure to save your changes and check that they were applied before you log off. Fiddler will record your session information.

Now log on as a regular user, or browse on the system. All you really need is for Fiddler to have the cookie of the regular user - but you may need to log on to get that cookie, depending on how your application works.

This is where the fun begins. Drag the admin user's form post to the Composer tab. This gives you all the fields that were sent. You want to make a change to the form data that will be obvious - something like changing a name.

Now go to the Inspector and pick your regular user's most recent request. Copy your regular user's cookie from the Raw request tab, so it's in the correct format, and replace the cookie in the Composer request. You're ready to go.

Send your doctored request from the Composer to save the modified data in the system. If the save handles its authentication properly, no changes will be made. Whether you get an error or not will depend on how your application works, but the key thing here is whether or not the saved data changes. If it did, congratulations! You've found a vulnerability that needs to be fixed.

How To Tell Your Developers About The Vulnerabilities You Find

I've seen everything from "Oh no! We have to fix it!" to "How dare you do technical stuff to my code!" from developers. How you tell them there's a problem with their code? More often, it’s not-their-code, because every system accumulates legacy issues after it's been in use, and someone has to maintain it, developers become de-facto responsible for the code. It will depend a lot on how well you interact with them as a team, as well as how bad the problem is and how much work it entails.

My preference is to keep it simple: describe the problem and how you reproduce it, include links to security references describing the issue, and describe potential consequences of leaving the vulnerability in place. Make sure your descriptions use neutral wording and never blame anyone for the problem.

It's Not Really A Problem

Also known as "nobody would ever do that" and "what the [bleep] were you doing?". Yes, we are also known as "nobody", since we just did "that".

You're going to have to prove that there actually is a problem if you get this reaction, so your first step is to reproduce the problem. Several times, if you have to, with the developers watching you do it. If you can't get them to watch, a screencap video can work (Jing is a nice free tool for this).

References from the OWASP top 10 and Information Security Stack Exchange also help.

Be open to the possibility that it really isn't a problem, too. You're working on a test site which may have vulnerabilities you're not aware of because it's been made more open for testing purposes. This is the other reason to head on over to Information Security Stack Exchange - chances are someone has done exactly what you just did, found exactly what you just did, and will have a solution or proof that it is/isn't a problem.

This Can't Happen On Production Because SSL

I've seen this too - and the answer if you can do it is to repeat what you did on production using your data or known test data, then send the write up. But keep that write up to the bare facts of what you did and the outcomes.

I'm Not A Hacker

This is your fallback and go-to line for resistance. "I'm not a hacker and if I can do this, so can a hacker!"

Now What?

Don't be afraid to escalate if your developers are seriously against doing anything, and you're certain there's a real problem. It's very easy for developers to miss the broader picture and reject a security issue because they're not aware that the things they consider edge cases are things that could cost their employer millions if exploited (been there).Or they aren't familiar enough with the domain security requirements (been there, too). Or they don't believe testers know enough about their domain (yes, there as well).

Document, document, document, escalate where needed, and accept the decision. Sometimes things that look horrible from where you stand actually aren't that bad.

References And Tools For Further Learning

There are a huge number of places you can go to learn more, many of them free . This is a long way from a complete list, but it's a good place to start.

Reference And Study Sites

These are my go-tos if I have any questions about whether something is a problem or I need to find a better way to try to test for security issues.

Information Security Stack Exchange - You will find a wealth of information in this stack. Search the questions, and be rewarded by the deep knowledge within the answers. Or just browse a tag that catches your eye. You'll find just about anything related to information security here.

OWASP - The Open Web Application Security Project is another wonderful learning tool. They have a section devoted to helping testers look for security problems, and a whole lot of information.

Troy Hunt's site - Troy Hunt runs an excellent security blog with a whole lot of extras for those who want to look for more information.

PCI Security Standards - If you test anything that takes credit cards, this site is an essential reference.

Bill Sempf's site - Bill Sempf's blog has many links to helpful resources along with interesting and accessible reviews of tools.

Tools For The Tester

The Big List of Naughty Strings - Contains a lovely collection of strings known to cause problems in different environments. Use with caution, but use them.

IronWASP - IronWASP is a decent basic security scanner that won't cost anything but time. I've honestly found its help and explanation of possible issues more useful than the actual scanning, but your experience may be different.

Fiddler - My personal go-to for most manual penetration testing. I get more detail from it than the browser tools give me, and I have more control over what I manipulate.

Jing - Jing is my preferred free screencap and video tool. It will create quick screenshots easily, and can create short (up to 5 minutes) videos that will run in most browsers just as easily.

Notepad++ - Notepad++ is my favorite text editor. It has a ton of plugins, including URL encode/decode, code syntax highlighting (which makes reading code so much easier), and HTML/XML pretty print to auto-format HTML and XML for easier reading.