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.