Authorization testing…analysis logic added

I’ll keep this one short. If you’ve been following my ramblings lately, you’d know that I’ve been trying to create a repeatable testing methodology for testing the TeamMentor web services. Right now, I’m focussing on authorization testing. I wrote some code last week that was quite useful. That code however did not give me control over which methods I wanted to test and did not do any kind of analysis on the results obtained after the method was invoked. I’ve fixed that now 🙂

I modified the code to now read what methods needed to be tested from a file. This file is fully in your control, and you can add and remove methods as you wish. Another cool(a little anyway ;)) thing that I did was to modify stuff a little so that it now does some basic analysis. I’ll very briefly describe it here.

I already built in a feature to add attackers to a method. So for example: I could say that the method GetAllLibraryIds must be accessed only by an admin and an editor. An anonymous user and a reader, hence, become attackers; and the method is invoked for both of these. If, after the method is invoked, a security Exception is not thrown and recorded, it’ll mean that the reader for example can successfully invoke the method. If an exception isn’t thrown, but the output format isn’t quite right, a message to that effect is printed; this however is still unsafe and further manual verification needs to be done. If a method didn’t have a specific user as an adversary, a simple NA is printed. All quite basic but quite cool IMO 🙂

Since I’d built the unit tests for all these methods prior to this, its now going to be very easy for me to know “what a correct value” is and do a compare to verify a bypass. I can keep talking about the code though…but some of you might just want to directly look at the code without tolerating my babble :). For all of you, here’s the new code.

I’m really close to testing authorization bypass for the 15 methods I wrote Unit tests for. I just need to check with Dinis though; on what “normal business functionality” is…for each of these methods. As in, Is a reader “supposed” to invoke GetAllViews() or not? Repeat for each method. Once this is done…it’ll end (mostly) 1 complete cycle for testing auth bypass on Web service methods. I think so anyway..if not…I’ll let you know that I goofed up.

Lastly, I thought you might like to look at a screenshot of the report that’s generated. Nothing don’t be disappointed 🙂

This entry was posted in WebServices. Bookmark the permalink.

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s