A shared environment containing private and confidential information requires excellent access control. To verify that the access control works as it should, it has to be tested. But testing authorization isn't easy:
- There is very limited tool support. A tool would need to be trained to understand how it should operate and what the logic of the each page is. This training would eliminate the savings on using a tool in most cases.
- Applications are different, and methods and techniques may need to adapt for every case.
- There is very limited course coverage. I have been to a few courses on application security/ethical hacking/penetration testing and none of them have really covered the topic. It is probably avoided as it is hard to teach on it due to the previous two reasons.
- It is complex and time consuming. If you have four actions on an object (read, write, update, delete), as a minimum you will need to check all instances where the user should be denied access. If the user can access an object in a different contexts, you will need to repeat all the checks for every context.
- It can require a lot of request modification. Sometimes it is just about incrementing a number. Other times it requires copying GUIDs or complex structures from another session. And sometimes it is even more complex and the solution is to copy cookies and relevant headers between sessions.
So even though "Broken Access Control" is number four on the OWASP top 10 list (2017), I think we're often not doing what we should to prevent it. The vulnerability ranks highly because it is prevalent and because the consequences of getting it wrong are devastating. It will let someone without permission access/modify/delete other people's data.
What is authorization testing?
Basically we need to check that a user only sees what the user is supposed to see. In simple terms it is a test to ensure we are blocked from seeing or doing something we don't have permission to see or do.
For example, let's say we have user A who is an admin. Being an admin, user A has access to everything under https://example.com/admin. User A should also be able to get a list of all objects when accessing https://example.com/objects, as well as access all individual objects https://example.com/objects/1, https://example.com/objects/2, https://example.com/objects/72324.
User B on the other hand should not be able to access the admin section, and when accessing https://example.com/objects only the few objects he or she has permission to view should be visible. If user B only has permission to view object 524, then https://example.com/objects/524 should return the object, while https://example.com/objects/523 should not return any objects or grant access.
In some cases, such as in the above examples, we can perform authorization testing on GET requests just by working in the address bar of the browser. As user B, access https://example.com/admin and see what happens, then check what https://example.com/objects/523 returns. You should also check if the response to https://example.com/objects/523523523 differs from the previous to see if there is a difference between unauthorized and non-existing objects.
But generally you need a web proxy. Fiddler is my favorite, it is free and you can
download here. It lets you break on requests to change anything in the request before sending it to the server, and it also letss you replay old requests and modify them. I will divide the changes into three categories:
- Ids of objects in URL or request parameters.
- Authentication, such as cookies or access tokens
- Everything else, such as HTTP verb, referrer, content-type etc.
Category 1 was discussed above. Category 3 is probably the least likely to return anything interesting, apart from the HTTP verbs, but most of the verbs can be tested in category 2.
Impersonation
To test authentication change (category 2), you will need to identify all the authentication headers. This could be cookies, X-Auth-Token, Anti-CSRF token, session ids and others. You will have to copy one or more of these into every request you are testing. What you are doing is that you are transferring all information on the user. The server will then view the request as coming from the user sending the request you copied the items from.
Replacing authentication and Anti-CSRF tokens is a lot of work, and if you get it wrong your test may return a false negative. So we should automate it.
In Fiddler, go to FiddlerScript. If you haven't enabled it already, you can
download it.
Inside class Handlers, insert the following:
public static RulesOption("&Toggle user")
var m_replace: boolean = false;
static var replaceUserHeaders = {
'Cookie' : '',
'X-CSRF-Token' : ''
};
Then locate the line
static function OnBeforeRequest(oSession: session){
Right below you can paste these lines:
if (m_replace){
for (var key in replaceUserHeaders)
{
var value = replaceUserHeaders[key];
if (null != value && value != ""){
oSession.oRequest.headers.Remove(key);
oSession.oRequest.headers.Add(key, value);
}
}
}
Now you can have Fiddler swap authentication tokens for you. If only cookies are used for authentication, copy the cookie value from a request made by user B and insert it between the two quotes in the script after 'Cookie' :. If other headers are necessary you can add them as well. If the values are blank the header is skipped. Save the script.
Now log in as user A and go to Fiddler again. In the menu choose Rules > Toggle user (or hit Alt, R, T). Fiddler will now replace all the headers you asked it to. (It may also do this for all other requests based on your Fiddler settings. That's why you suddenly see a lot of login pages, but can't log in to anything else in your browser)
Switch back to the browser. It has been loaded in the context of user A. Click on something and see what happens when the request is sent as user B. Was the result as expected? You'll often have to go back to Fiddler, turn off "Toggle user" and recover to a non error page in the browser before you can proceed and test your next item.
Tip: Use different browsers for users A and B, or use an incognito window in Chrome that doesn't share cookies with the main instance. Don't log out from A or B as both sessions must be running at the same time.
Alternatively you can perform some actions as user A, turn on Toggle user and replay the requests in Fiddler by selecting a request and pressing "r" or by dragging the request to the Composer in Fiddler and then click execute.
Introducing steroids
Do you want to go really fast? Let's say you are testing a REST API. First you can configure Fiddler to filter out everything you don't need to test such as js, css and perhaps image files. Then you get the authentication headers for user B. Then you let user A log in and perform a number of actions in the application. You should get a list like this:
Note the "204" responses - these are the result of PUT requests, whilst other requests are GET. There may be some more requests that are not interesting; these should be deleted before you proceed. Then you select all the requests and click "r". Fiddler will issue all requests again, swap the authentication headers and you will see the result. Let's just hope your session hasn't expired.
Here are my results. Previous requests are selected and have a blue background. The first new request is loading the single page application and the second is loading a list of available items. The forth request only returns current permissions. The rest return 404 as intended. Everything is as it should be.
Results may vary. The HTTP status may be 200, 301, 302, 401, 404 or something else; you will need to know your application. If it is 200 OK it was a legitimate request, you broke authorization or got an error page. Just looking at the size of the response (the "Body" column) in the request list in Fiddler will give you an indication. If you get 3xx, 4xx or 5xx the authorization is probably sound (but there may be other issues). In this example GET /surveydesigner/api/surveys?... should return a valid response for all as it should list accessible objects, but the returned content should be different. In my example A gets a response of 45.537 bytes while B only gets 914 bytes.
There are some cases where this doesn't work. For example I once tested an application that logged me out every time I tried to access something I was not authorized to see.
However in most cases it works and in many cases it saves me almost all the hassle of laborious authorization testing. I set it up, click around the application, select all the requests and hit a button. All the red responses indicate sound authorization checks and I can focus on the other few and check if they are interesting.
