Let’s take the same concept from the first part of the article even further.
Let’s say that viewing
/users/id/104/edit
(or some other random numbers) gives a permission denied error.
So, viewing the edit profile page is not allowed. However, that does not necessarily mean it’s not possible to edit anyone’s profile information – it just has to be done without without viewing the edit profile page. You’re going to need a tool for that.
I recommend TamperData, a firefox extension, to get started quickly. If you don’t have TamperData (or anything similar) yet, get it! It’s a must-have when testing web applications.
Introducing TamperData
I’m going to show you how to use TamperData by providing an example scenario with screenshots. I have a simple web application in front of me. I’m logged in as user indrek_test. This is how the edit profile page looks like:
I fire up TamperData, click Start tamper..
..then submit the form by clicking Save, then in the popup click Tamper ..
..and this is what I see (click to view full size image):
On the left, there is the request that will be sent to the server. This is useful if you’re doing more complex security testing, but out of the scope of this article.
On the right, you can see the POST data that will be sent to the server along with the request – in this case it’s the data I’ve entered into the form. You can change the values here or add new values.
Note that in addition to the form data, there is another field: id. This was not in the form, that means the developers didn’t intend it to be changeable.
So, if you change some of the data, most notably the id..
..and submit, this is what you’ll see:
The current account’s email address is the same as before, so that probably means another account’s email was changed. If you could somehow find out that account’s username, you could use Forgot Password functionality (if it exists) to gain access to his account.
Web applications often provide a way to delete your account.. or in this case probably other people’s accounts too, because if there is no authentication when editing a profile, you can be quite sure there’s no authentication when deleting the account.
However, in modern web applications, the user ID is not always in the form – sometimes it’s in the URL.
Before I continue, let’s quickly go over some terminology. Your web browser can send different types of requests to the web application. The most common is a GET request – this is sent out every time you view a web page. If you go to /users/id/105/edit with any browser, you are sending out a GET request to that URL.
On the edit profile page is the profile editing form. If you submit that form, you are (usually) sending a POST request to a URL specified by the developers. A POST request is usually meant for sending data, not simply asking the server to view a web page.
As I said before, in some modern web applications you often don’t have separate URLs for viewing the edit profile page and submitting the edit profile form – they can be on the same URL, but the web server acts according to the type of the request (GET or POST).
So in a slightly modified version of the same web application, the POST request looks like this:
As you can see, the user id is no longer sent with POST data. That means the application is probably using the user id in the URL to figure out which user’s profile is being saved.
So in this case, if I edit my profile and click ‘Save’, a POST request is sent to /users/id/105/edit – that’s the same URL that’s being used to view the edit profile page. But since it’s a POST request not a GET request, the application knows a form was submitted.
If you want to try changing another user’s profile in this case, you should simply send the POST request to another URL. I haven’t figured out how to change the URL of a post request while you’re sending it with TamperData, but you can repeat the request later and send it to another URL.
In the TamperData main window, I right click on an already sent request..
..click ‘Replay in browser’..
..and change the URL to edit another user’s profile.
And there you have it.
Conclusion
Developers tend to forget or overlook things, especially when it comes to security. So from the web application security perspective, forms are always something you should look at. I once stumbled upon an online shop that used a multi-part form to send the price of the items you were buying with a POST request. Not a good idea.
So whenever you are submitting any data to the server, you should have TamperData open. Actually, you should have TamperData open all the time, as it will give you an excellent overview of the traffic between your server and your browser by logging all the requests and responses.
Once you get used to looking at and modifying requests with TamperData, you’ll probably notice that it’s not very comfortable to use it in some situations. There are many similar tools you can try out (Fiddler2 for example) but if you’re just starting, TamperData is a good choice.
So yeah, now you know how to unravel massive security holes just by looking around and manipulating urls and some data. Have fun!
