http penetration testing proxy web security

Burp suite tip / tutorial: renaming tabs

This will be a quick and simple tip that you may not have been aware of, you can rename tabs within Burp. A friend of mine who works out of Raleigh turned me onto this. I find new sometimes obvious and hidden features in Burp all the time and this is one of them.

I find this feature handy especially in a large application as I can easily keep track of what I’m testing.  I use the tab renaming on the Repeater and Intruder functionality. In order to rename a tab simply double click the tab which will allow you to edit the tab.

Repeater before

Repeater after

Intruder before

Intruder after

Hope this simple tip helps you perform better application pen testing.

web security

Burp suite tutorial / tip: determining cookie functionality

When testing web applications you may come across an application that passes a ton of cookies along with each request. Cookies are used to maintain state within the application and typically only one cookie is needed within the application. There are times when other cookies are used as well and when testing web applications it may be difficult to determine what cookie is associated with session and functionality. Hopefully my technique of determining cookie functionality will also help others as well. Let’s get started with an example. I’m going to take a look at ubuntu forums as an example.

So configure burp to capture traffic and make a request to Ubuntu forums. Below is the screen shot of Burp making the first couple of requests to

Here we see that simply going to the forum home page without authenticating we get two cookies “bb_lastvisit” and bb_lastactivity”. We’re lucky in some sense as these cookies are fairly descriptive, often times cookies have nondescript names which makes it even more difficult to understand their functionality. Now let’s authenticate and see what other cookies come into play.

Now we have two additional cookies (bb_sessionhash and IDstack) that get submitted with each request. At this point it’s a safe bet to say that either IDstack or bb_sessionhash is responsible for handling session to ubuntu forums. One of the quick and easy ways to determine which cookie is truly used for session is to intercept a request that requires authentication, manually delete that cookie and see if you get kicked out of the application. Below is a screenshot of me performing that action.

In this example I clicked on my profile because some portions of the profile require authentication to view. So I deleted the IDstack cookie to see if it had any affect on session. After forwarding the request it did indeed bring me to my profile so the IDstack cookie isn’t responsible for handing the session. We can see this in the browser as shown in the screenshot below.

Next let’s try the getting rid of the bb_sessionhash cookie via the same method.

After the bb_sessionhash cookie is removed we do indeed loose the authenticated features of the “My Profile” page as seen below.

So now we have identified the cookie that maintains session for this application. It’s also a good idea to delete all the cookies except for bb_sessionhash or your particular cookie in question. I did go ahead and delete all the cookies except for bb_sessionhash and I maintained session so the other cookies have nothing to do with session in this instance. In this scenario you can wipe your hands clean knowing that you’ve correctly identified the cookie that properly handles the session but sometimes other cookies will appear within the same application when you stumble across other functionality. One example of this is when a web application has some reporting piece to it. I’ve seen where the reporting functionality may be a bolted on third party application that uses it’s on session handling which would call another cookie. Because of this I like to only pass the cookie that handled the initial authentication and see if any other functionality, a la reporting, gets broken with only the one cookie being passed. So what I like to do is set up a intercept rule that will only pass the initial authentication cookie and monitor what gets broken as I walk the application. To setup this rule go into the Options tab within the Proxy tab and create a “Match and Replace” rule to perform this. I add a rule with type of “Request header” and then paste the entire cookie line into the “Match” field then I only place the session handling cookie in the “Replace” field which in this case is the bb_sessionhash cookie. A screenshot of this rule can be seen below.

After this every single request will only contain the cookie you’ve identified as the one belonging to the main session. If you look in the history tab and view a request after you’ve made the rule you’ll see where this comes into play as seen in the screenshot below.

Now you’ve successfully isolated one cookie that deals with initial authentication and while you’re walking the app and you stumble across some broken functionality it may be because another cookie got introduced into the application. Hopefully this rule will help you identify other cookies that get introduced into the application. Also hopefully this will keep you mind open to other rules that you can make regarding sessions within the application.

Please leave feedback and let me know if this was helpful and if you know of any other good burp suite tips please leave feedback on that as well.

http penetration testing web security XSS

Burp suite tutorial / tip: using intercept to locate automated scanner findings

So the problem I have in my job and maybe others do as well is that when assessing a web application for vulnerabilities you want to throw automated tools at it first to get the low hanging fruit. So you get the results back and you have some good findings but you’re not exactly sure where that finding resides inside the application. Meaning first click here, then here, then here, and modify parameter X. It’s not crucial to know this because with burp or any decent web proxy we can replay that request to retrieve and prove the vulnerable results but when dealing with laymen and even developers you have to hand hold them through the exploitation process via the browser as much as possible hence the need to know where in the application the vulnerability exists.

In big applications simply knowing a what GET or POST request is vulnerable may not tell you where the vulnerability lies. Let’s say the scanner reports back that is vulnerable, well this is a generic URL without much context so it’s not obvious where you would have to browse to stumble upon that request. It’s even worse for POST requests because going directly to the URL without the parameters can produce errors within the application.

Let’s walk through an example of using the burp intercept feature to find where scanner results are located. I’ll be using an intentionally vulnerable web application named Peruggia found within the owaspbwa project which is a great project to learn web app testing. So I ran the active scan against peruggia and got the following results.

I’m going to focus on the highlighted cross site scripting vulnerability in the screen shot above. I picked this request for a number of reasons but first let’s take a look the details of the request below.

Here we see it’s a POST request and I wanted to focus on a POST request because some of the challenges faced with these requests. In the top third tab we see the response was redirected which means we’ll get a 302 status code. If you were to copy and paste the URL into the browser and make that request you’ll be redirected to the home page. This is the nature of POST requests we can’t just put the URL into the address bar and be take to that location. Because of this it can be hard to determine where in the application the vulnerability exists. Especially for XSS (cross site scripting) vulnerabilities I like to obtain screen shots of the alert box to prove to the customer that I was able to exploit the vulnerability. With a GET request this is easier but POST requests add a level of difficulty.

Let’s walk through an example to understand the challenges. I’ll be starting out on the about page of the Peruggia application. Next I’ll paste the URL from the XSS finding into the address bar.

After I enter this request I get redirected to the home page.

This is also reflected in burp where we see the 302 redirect status code that sends us back to the home page.

So the challenge is to find that “comment” parameter that burp flagged as vulnerable but without a simple GET request this can be difficult. I didn’t pick the greatest example because the “comment” parameter shouldn’t be that hard to find in this application because it’s fairly small and the parameter is actually providing some context, adding a comment, which doesn’t always happen. So for this example let’s ignore the big comment box on the home page and pretend we didn’t see that.

We’ll now set up a rule inside the proxy intercept to alert us when we stumble across the vulnerable “comment” parameter. Let me explain the term stumble for a second. When I get a result back from a scanner and I’m not sure where it’s located inside the application I’ll typically start walking the application and monitor my proxy history to see if that parameter was passed within a request. This can be a pain in the butt so setting up a proxy intercept rule can help automate the process. The rule is somewhat counter intuitive because we’ll leave the intercept on the entire time and let it catch when it sees our parameter. In this case we’ll disable the default file extension match rule and add our new rule to look for the parameter in question. Below is the rule I setup to catch the vulnerable parameter “comment”.

Now the next thing is to start browsing / walking the application and the proxy intercept will automatically alert you when you come across the vulnerable parameter. So while walking the application I decide to post a comment on a picture to ensure I’m touching every functionality of the application. My intercept is on with my new rule waiting for it to flag the vulnerable parameter.

After I make this request my proxy starts blinking and alerting me to the fact that I’ve come across the “comment” parameter.

Unfortunately for large applications it may take some time before you stumble upon the proper vulnerable parameter but hopefully this will help you out when trying to pinpoint the location of automated findings. Of course once we’ve found the vulnerable parameter that the automated scanner has found we’ll want to capture a screenshot of the exploit and this case we’ll need to document that we’re abe to execute javascript inside the application. So now I’ll capture that POST request again and insert the classic javascript alert message.

And now the alert message proving to the application owner’s, developer’s, and customer’s that executing javascript is possible.

XSS FTW. Hopefully my little small tip will help you when trying to hunt down where in the application an automated finding resides. Happy bug hunting.

SQL injection web security XSS

Firefox add-ons for web app assessments

These add-ons are mainly related to web application security, you see these types of list related to firefox add-ons but these are the ones that I think are the most helpful. Firefox has a nice category called web application security penetration testing that has a lot of the plugins I’ll mention.  Not all plugins in this category are worthwhile which is why I’m sharing my list.

Detecting cross site scripting

XSS – me

Acunetix xss scanner

I’ve included the link to the Acunetix add-on from my site. You have to sign up with Acunetix in order to receive the add-on and even then it comes bundled with an executable. If for some reason my link doesn’t work with your version of firefox then simply go to the Acunetix site and download their latest version.

Detecting sql injection

SQL inject me

Developer tools are always handy to have because if you can build it you can break it. The web developer add-on will allow you to easily see hidden form fields, javascript, cookies, etc. Firebug will allow you to easily see how the application is built by simply mouseing over the layout. Firebug is also a debugger and will allow you to set breakpoints for javascript, both are a must have.


Web developer

Modification tools, if you want to modify a request before it’s sent to the server tamper data is a great tool inside the browser for the job. User agent switcher will allow you to pretend to be any browser you’d like, don’t forget the starbucks iphone problem. Add n edit cookies is another modification tool that will allow you to easily change cookies so that you can impersonate a cookie you have obtained.

Tamper data

User agent switcher

Add n edit cookies

Miscellaneous add-ons. Show IP is a great add-on that will show you the IP connecting to, this may seem lame at first but when you are assessing multiple environments or malware this is always handy. Leet key is another great tool inside the browser that will perform encoding (base64, URL, rot13, etc) and even generate hashes.

Show IP

Leet key

Notable mentions

Foxy proxy


If you have any other recommendations please let me know.

Uncategorized web security XSS

How to write a web app worm

When I say web app worm I mean a web site specific worm such as twitter. Twitter has been picked on (they should be because it’s a meaningless app) when it comes to web app worms so why stop now. There are other types of worms that could include web servers and databases but that won’t be addressed in this write up. The web app I’ll pick on for this example is Gruyere. Gruyere is an intentional vulnerable application that a handful of folks over at google wrote to point out some of the major vulnerabilities within web applications. Gruyere is very twitter like so my example would be relevant to other applications that function in similar ways.

Most web site worms spread because they allow javascript to be inserted somewhere into the web application. For example in twitter when a status is updated (via a moronic “tweet”) you are allowed to insert words, sentences, and even links to other interesting sites. If twitter allows you to input all this information what do they block? Javascript is a well known programming language that you should never allow to be inserted into your web application. Even though many web developers know this they continually make mistakes and allow javascript to be inserted into their web apps. There are different categories of javascript attacks such as XSS and XSRF, I’m not a big fan of this naming convention but  you should be familiar with the terms and what they mean. Most all web app worms are spread via the XSRF attack. Basically a XSRF attack is where javascript (possibly other languages) is inserted into the web app, that javascript will then make a request on behalf of the user. This request could be malicious in nature or in case of the twitter worm examples just for fun. The example I’ll be going over will be a classic XSRF attack where I’ll insert javascript to make requests on behalf of the user.

Let’s get started. I went ahead and created several accounts within Gruyere to demo the attack, in this case Travis will be the attacker.

To create a web app worm first you’ll need to discover a vulnerability within a web app that allows you to insert javascript. Luckily the “New Snippet” functionality will allow us to insert javascript. Now to find vulnerable input that allows you to insert javascript may not be that easy. In order to successfully insert javascript you’ll need to be able to insert certain characters such as “<” and “>”. One great tool to find these characters which will in turn find vulnearbilities is Firefox addon named “XSS Me”. XSS Me will tell if an input will allow certain characters. So now that we have vulnerable input how do we get this worm started? As the attacker I will place the following link into a new snippet.

Now all I’m doing here is creating a link to my evil code, to create a worm you don’t have to keep your evil code in another location you could insert all the evil code you need into the vulnerable web app itself. Most of the time inserting all of your evil code into the app itself would be ideal but it really depends on what the vulnerable app will allow you to do. Now that we’ve inserted a link to our evil code what exactly does our evil code look like, below is the source code in evil.html.

<p <body onload="Wait();"><img src="">
function Redirect()
function Wait()
setTimeout("Redirect()", 1000);

Now let’s break evil.html down line by line. All the magic is happening in line one. The first thing that is written is the html paragraph tag “<p”, this is done specifically for this app because anything after the <p> tag would allow other characters. Next is the html body tag with an “onload” action. An action in malicious code is common so that the attacker perform other steps, another common action event is an onmouseover event. Once the page loads it will call the “Wait” function, we’ll come back to that in just a bit. After the wait is the image tag (<img>) to make the XSRF request for me. The request is to add a new snippet to whomever clicks on the link. In this case if a victim were to click on my link it would create a new snippet for them with a link saying “kitten videos”. To add a new snippet within Gruyere the url would be the following

Anything after the equal sign would show up as a new snippet so I inserted the following “malicious” snippet

So what does all that mess mean? If you take all that mess and url decode it’s the following.

<a href="">kitten videos</a>

In this case I had to url encode my attack so that it would work, this is not uncommon when performing these types of attacks. So as the attacker I’m placing a link inside a new snippet for the victim that says “kitten videos” but that link is still pointing to my evil.html. Now let’s get back to the wait function. I won’t break it down line by line but what happens is when the page fully loads the code will jump to the wait function on line seven. After that setTimeout will execute after one second which calls the Redirect function, the Redirect function will redirect the user to the home page of Gruyere. The whole point of everything after line one is to simply redirect the user back to the homepage after the attack. So now that we have planted the seed of attack let’s see what happens when Alice clicks on our evil link.

Just by clicking on our “evil” link Alice created a snippet that she herself didn’t write, it was our malicious javascript that created the link. Now let’s login as Bob and click on the “kitten videos” in Alice’s snippets.

Bob has now updated his snippets just by simply clicking on the link in Alice’s snippet. You can now see how this can snowball much like other web app worms have spread as well. So in only a few lines of code I have created a worm that will replicate throughout the application infecting whomever clicks on my malicious link. The twitter worm was very simple as well. I could have just as easily made it that if a user were to simply view my snippet that they would get infected as well. Once you allow javascript to be inserted into your app that are a number of things an attacker can do to manipulate your application.

Hopefully this small write up at least some what explains how web app worms get created and how simple they can be. Developers of major applications such as twitter need to better test and review code they have written. As one of my links points out a seventeen year old kid exploited the mighty twitter, just goes to show you how well major applications are focusing on their security. As a user I would never click on a link that you don’t trust and turn off javascript for web apps that don’t need javascript in the first place. If another worm pops up in twitter or facebook I won’t be sad.