Finding the WSDL and why should I automate?

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..

Team Mentor is an application that is written in .NET and Javascript. So, for the uninitiated, the flow is Login – Click on a Guidance Item – Read Content. Now all of this is in Javascript. So when I login, there’s an XML HTTP Request call made to an exposed Webservice method ‘Login’ which takes as input a user name and the hash of a password; passes these inputs on to some .NET code on the server side..which “handles it” somehow (I don’t know how yet :)) and returns back to me, the content of the guidance item. Once I login, as a customer, largely, I’m going to want to read the content in each of these guidance items. So I click on a row there to learn more about, say, parameterized queries. Immediately, there’s an XMLHttpRequest fired to a WebService method – GetGuidanceItemHtml with the guidance item ID as a parameter. Again, .NET somehow retrieves this data and displays it to the user. So, I guess what I’m saying is, the frontend is a lot of JS and the backend is a lot of .NET and the application is using Webservices as a link between the two. Makes sense? Classic webservices..right 🙂

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 🙂

This entry was posted in WebServices. Bookmark the permalink.

One Response to Finding the WSDL and why should I automate?

  1. Pingback: Testing TeamMentor Web Services – 2 | TeamMentor

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