Authorization testing – the thought process…

So Suds was working just fine as I said in my last post. Time to start coding. The goal of this little script that I was trying to write can be summed up as follows:-

a) Get  a list of all methods and all users with their credentials.
b) For each user, invoke each method and store their results.
c) Analyze these results later, to see if anyone was allowed to perform an operation they weren’t authorized to.
d) Generate a report.

Yeah. Quite straightforward. On paper at least..or should I say on the blog at least? Not funny? Oh well…I tried. So going on..

If you remember the previous script I wrote to test Suds, I printed out the results of the client object. This results in a list of all the 121 methods getting printed out. First of all, I wanted to have a top level view of who the attackers were for each method. And that’s where this Google Doc comes in. Now for scripting purposes, I divided this list into 2 major categories:

— Methods which didn’t need parameters.
— Methods which needed them.

The parameterless methods are easier to call because I don’t need to know exactly what to fill as an argument..coz there ARE no arguments. So I could focus on the task right now, which was to write code which did a) to d) as listed above…and not get bogged down in the details of the application. There’d come a time when I’d have to do that..of course, but not now. Everything in life..and definitely code..has a time and place. Ha. I’m a philosopher too B-)

So I first parsed the entire method list and extracted 45 methods which didn’t contain parameters. Now I need to call those 45 methods for each user and record their results [See b) and c) above]. So I logged in to the application, created a ‘reader’ and an ‘editor’ and got their password hashes as well. Stored these in a file to be read by my script. Lastly, there might be some methods for which the reader and editor were “supposed” to have access…much like the admin user is “supposed” to have access for the whole application. So for each method, I added code to track the ‘attacker list’ as well. Now..for each user I logged in [Added a case to bypass login for anonymous], added the CSRF token and requested every single one of those 45 methods. Stored the results. Wrote a little exception handler to store the errors as well. Wrote these results to a CSV file. Yep. Worked. Good so far?

That left me with the methods which had parameters. Now each of these methods has a specific data type; like xs:string or ns0:guid or whatever. Unless you know what you’re supposed to fill in as a value you can’t query it successfully. So I now need sample values for each data type. So after a mixture of browsing the app and playing around with SoapUI as an anonymous user, I finally came up with a file which contained 54 unique data types along with sample values for every single one of those data types. Added a function to call all these methods which have parameters as well. So the pseudo code just translates to..

<br />
For each user{<br />
 Call methods with no params<br />
 Call methods which have params<br />
 Store result<br />
 }<br />

So this works and I now have a result in a CSV file for every single user. Some of the methods have returned properly; while others have thrown exceptions due to SOME reason..don’t know what. If its a Security exception, then you could possibly argue that the ‘user’ making the request doesn’t have the permissions necessary to invoke that method. Anything else, its probably something to do with the values of the parameters passed. So I now need to look at all the exceptions thrown, and possibly adjust my sample values list a bit so the very least..a NON security exception is thrown. If you’re interested, that code is here.

Now at this point of time, I can’t go any forward unless I do what I said. So I now pick say 10 or 12 of the most common methods used, ensure that I can get values returned after I invoke all of them and then write Unit Tests and Abuse tests for them. What do those mean and why do I need them? That’s something for the next post.

This entry was posted in Uncategorized, WebServices. Bookmark the permalink.

One Response to Authorization testing – the thought process…

  1. Pingback: Testing TeamMentor Web Services – 4 | TeamMentor Development and Testing

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s