So, if you’ve been reading what Dinis has been writing about, you’ll know that we’ve been doing a lot of work on TeamMentor. Testing all the exposed Webservices is a part of this activity. So what I’m going to do in a series of blogs starting with this one is describe my entire thought process while testing. I trust you will enjoy reading the same :). So here goes..
Once this was clear, we decided we’d test if authorization was implemented properly for each of these Webservices. So, in simpler terms…”Can, I, as an attacker invoke a Webservice method to view, modify or delete data that I wasn’t supposed to?”. So who are the attackers here? There are 4 roles that TeamMentor uses:- anonymous, reader, editor and admin. Of these, the admin role has access to ALL the methods and can do pretty much anything he wants with the appliation. So, from an authorization perspective, he isn’t an attacker. So we need to now check – “Can an anonymous user, a reader or an editor read,modify or delete data via a Webservice method?”
So, once that was clear, I decided that I needed to understand each of these Webservice methods better, before invoking them. The first thing I did was to browse through the application and see if there was any way in which I could invoke these Webservices through the application. Turns out there was a way. You need to login as an Admin and go to the Control Panel – Admin Tasks. You have there two text boxes where you can type in a method name and the parameters it takes and click Invoke. The problem here though, was that since we know nothing about the application yet, we don’t know anything about the Webservices either. So right now, this is kind of useless for us. So we continue looking. Turns out there is another way. You go to Control Panel – Webservices. Here, you had a list of Webservices already sorted into categories with data already hard coded. So for e.g I have a hyperlink which says “GetAllGuidanceItems”. I click. Automatically a box is populated with the full path of the method name along with the parameters that are necessary for that method to be invoked. I just have to click Invoke and I get a result. Yay 🙂
I clicked through every single hyperlink here to first check if all of them were working. Turns out they weren’t 😦 Oh well..its a start. At least I had some way to “query” the application once I understood more about it. The next logical question though was…If some links aren’t working, how do we test them? Well, for now, we don’t, we’ll assume that the application is not handling those methods correctly. And make a note of those methods. But are there any more methods which aren’t listed inside the application AT ALL? Ooops…maybe. Lets find out.
If you’re using Webservices, there’ll almost certainly be a WSDL file which defines all these methods. So I fired up SoapUI and gave it the full path of the WSDL file which defined these services. And waited…And waited. 121 methods. Much more than what was listed in the application. So I now have to find a way to test all of that :). A quick, easy and repeatable way to test it. And no…its no fun pointing SoapUI to Burp, intercept ON, Edit request, send on, verify result. For 3 users. For 121 methods. No fun at all. And even assuming I did that, the next time some one wanted to test this..maybe next year…he/she would have to do this all over again. Major pain. So some automation…somehow…is needed. What? How? Stay tuned 🙂