You might recall that a month ago, I gave a lecture on web security to the “Distributed Client-Server Programming” class taught here at Mississippi State University. The goal was to give them a heads-up on what mistakes are commonly made by web developers, so they could try and avoid them while developing their final group projects. Yesterday and today, I have been sitting in on their final presentations, and (playfully) tinkering with their sites as they demonstrate them. They’ve definitely tried hard to work security into their projects, and it’s been interesting to play around and show off how things can go wrong.
They’re definitely learning a lot too, because one of the students actually pointed out the vulnerability I’m going to describe here before I found it 
. I thought it was a neat opportunity to show off how to attack bad access controls, so I decided to make this post about it as a tutorial on how to use PortSwigger’s excellent Burp Suite to bypass things like this. I’ve even set up a page on my site here that you can try it on .
The original student team’s project had two interfaces, the user’s interface, at $baseURL, and an admin interface at $baseURL/admin . When the user logged in, it would send them to the appropriate interface, based on the “admin” flag the user set in the database. To prevent normal users from going into the admin interface, the following code is used for all admin pages:
This lets the web browser know that it should head back to $baseURL. The problem is, that the php code/page just keeps on going: parsing parameters, sending the interface, and all the things that it would do for a real admin. A well-behaved web browser honors the “location:” in the header, however, and doesn’t render anything below. Unfortunately attackers aren’t well-behaved…
To show off how to beat this, I’ve set up this page for you to play with. Open it up in a new tab, and you’ll see that it uses “location:” to send you straight back to the root page of this site. Here’s the code:
Now, the page does get to the “You’re not supposed to be here, lol” part, it simply doesn’t get a chance to render. To see it, we’ll have to take the “location:” part of the header out. We’ll do this with Burp Suite, so go ahead and get a Java VM on your machine if you haven’t already, download Burp, and get it running.
Burp acts as a web proxy, and allows you to intercept requests and responses, and then modify them before they’re sent along to the server or client. This is very handy stuff for attacking web applications. Once you have it up and running, change your web browser’s proxy settings to use it:
Burp is already set up to intercept client requests, but you’ll need to turn on the functionality for intercepting server responses in the “Options” tab under “proxy”, in the “server responses” section. Check the “intercept if:” box here:
Now, go back to the “intercept” tab, and open this in a new tab again. Your web browser will just sit there (if you’ve got it all set up right), while the request has been intercepted by Burp:
Go ahead and click “forward” here. In this case, there’s not much to see in the request, but a lot of the times when using Burp on web apps, you’ll be changing things before forwarding along. Now, it should intercept the server’s response:
Notice that the whole page got sent (complete with the typo on the closing h tag that I just noticed, lol oh well). Also notice, in the header, the line “Location: http://mcgrewsecurity.com/”. This is what’s making your browser jump to another location, rather than display the page, so just highlight it and cut it out. The response should look like this after your modification:
Now, go ahead and click “forward”, and it’ll send the page along to your browser. There you go :
Note that even though we had to do some trickery to get the page to display, if it actually processed any POST/GET parameters (as admin pages tend to do), it would do so in this case, regardless of whether or not the browser redirected. All the attacker would have to do is supply the correct parameters. Burp makes things like this a breeze .
I’ve never personally seen a system that did access control like this, but when this was pointed out to me, I thought it was interesting and educational enough to share . Definitely something to look out for, and maybe if you haven’t used the Burp Suite before, you’ve got a nice new tool to play around with.
you suck
[...] covered web application testing using proxies (specifically Burp Suite) before, and I do that sort of thing pretty often. It can be a pain, requiring that I have launch Burp and [...]
how do you trick your time in your host with this burp?
example:
in a site where in a member can only vote for 12 hrs interval. how would you trick that site that you can still vote a lot without waiting for 12 hrs?
pls help.. nid this to learn.. i can’t figure it out!
This depends on what the server is doing to measure the time since you last voted. If it’s doing something like storing the time-of-last-vote in a cookie somewhere, then you’ll need to modify that cookie value. If it’s storing it server-side associated with a session ID in a cookie, then you need to get another session ID (generate one, come in as a different user, etc). If it’s storing it server side with your IP address, you need to come in from a different IP address (which Burp isn’t going to help you with).
Hi,
I didn’t read the entire page because your fonts are ugly and white on black is not a pleasant facade in which for me to read. But Burp Suite is severely limited. The most powerful functionality is Intruder and the attacks are time-throttled. Portswigger wants about $170 for the real thing. But if you but the book, there is Java source which provides much of the intruder functionality.
What do you think?
Hi Fred!
Sorry you don’t like the theme. If you’d like to read it in a form that’s pleasant to you, I’d recommend loading the feed up in the RSS reader of your choice.
I honestly don’t use the Intruder funcitonality that much. When I get to that point, I’m just more comfortable writing/extending my own scripts. I realize I’m probably reinventing wheels by doing this, but it’s what I’ve done for a long time, so it’s a comfort-zone thing. Intruder is very nice and powerful, as you said. I’d say it’s probably well worth the $170 if you plan on using it regularly. That’s a pretty small chunk of what you’d make off of one assessment/pen-test/whatever, then it’s yours to keep.
I don’t really see any problem with Portswigger trying to make a buck off of it. He wrote a very nice tool, and I think he deserves it. As you said, if you know what you’re doing, you can roll your own functionality. It’s a time/money trade-off like anything else.
Thanks for the comment, Fred. Gave me something to consider.
Well the if statement should also have an else, and what the admin is supposed to see should be inside of there. If this was done you wouldn’t have the ability to perform this bypass. Pretty poor coding to just have that one check at the top before loading the whole page anyway.
A good find nonetheless!
Hi Eric! Yes, that’s one way of fixing it. This was in a student term project, and I’ve never seen the same mistake made in a production application (although it seems like an easy enough mistake to make that it wouldn’t surprise me to see it again).
The original intent of the post was to use it as a unique situation to have a short Burp Suite tutorial, for the students of the class and the readers. Judging from the google referrals I get for this post I’d say it’s working out
.
Thanks for commenting!
how can i use basic things in burp suit
I configured the browser, now I cannot access any sites. The proxy in Burp Suite was found to be running at port no 8080. Can you please help me in case I’ve gone wrong somewhere .
It’s hard to say what might be wrong. You may have some personal firewall software blocking Burp, or you may not have configured the browser to point to the proxy correctly.
Kiki’s probably trying to access sites before loading the targets in the “target >> scope” tab. You can’t just visit any site in your browser while the proxy is set, only what Burp allows – and it only allows what you’ve previously established as your target. Sorry to post on such an old topic, but I’m willing to bet that was the problem.