JavaScript application testing - Firebug - Part 2

I wrote about how one can use Firebug over here. Today I'll extend that a little by introducing a few of the features I didn't touch upon last time. There's not too many left as I did the bulk last time, but hey..let's complete stuff :)

So the last time, we talked about setting breakpoints inside Javascript to look at code. We'll do 2 things now..firstly we'll actually set those breakpoints and take an actual application and see how these breakpoints help and secondly we'll introduce DOM breakpoints and see how those can be helpful at times.

So here's a client side application. On logging in as an Admin user we can see the first image and while logging in as a normal user, we can see the second image.

 

The goal here is to try and make those extra links appear for a normal user. Since the purpose of this blog is to just show you what breakpoints can accomplish, I won't dive too deep into how I identified the right place to set the breakpoint. Here I know that the critical place is line 4598.

The application is checking if the current user has a role of 'Edit Articles'. Where is it checking? It's looking into the TM.Gui.CurrentUser.userRoles element. Now how do we know what that contains? Well there's 3 ways. The first way is to look directly at the DOM element in question by navigating to the DOM tab and expanding nodes till you reach that element.

The second way is to do this through the console by typing in the whole path. If that path exists, the values will be displayed. Autocomplete by the way is enabled in the Firebug console...use the arrow keys to complete a word (left/right) or view possibilities (up/down) and hit Enter 2 times when done. If you type the whole thing out you need to hit Enter only once.

The final way is by means of something called a Watch expression. This is something completely new. It was to me too a day or so ago :). Navigate to the Scripts Tab and look at the right pane. Now click on watch and then inside the box which says 'New watch expression' and type in the exact same path you typed in the console. Autocomplete is enabled here as well. You can also right click on any property in the DOM and say 'Add to Watch List'.

NOTE though that the Watch is useful only when a breakpoint is enabled. We'll see why very soon.

Coming back to our example, which we've forgotten completely :).. we want to do something so that those 2 extra links appear for a normal user. Now if you've followed through, you'll know that the normal user does not have the 'EditArticles' role at all. And if she does not have the EditArticles role, she cannot get those 2 extra links. This means that we'll have to somehow edit the DOM and add that role in.


If you look at the Watch tab here before editing you can immediately see the value of the specific property without changing tabs to go to the DOM or the Console. You can stay in the Script tab and do it.


If you'd read Part 1 you'll know that this can easily be achieved by using the Console. If you haven't, and are frantically right clicking inside the DOM without success, don't worry. Here's how you do it again.

If you look at the DOM, using any of the 3 above techniques you'll see an additional role (EditArticles) that's added.

Let's now hit Continue (F8) and see if we get an additional link. We sure do :). The exact same exercise can be repeated by setting a breakpoint on the isAdmin line (4597) and adding the "Admin" role to the DOM. If you'd like to try it out,  grab a copy of TeamMentor from Git.

DOM Breakpoints

All this while we've been setting breakpoints in the JavaScript. It's also possible to set these breakpoints in the DOM instead and alert us when that particular property changes. Let's extend this same example now, shall we.

On clicking logout, there's a high chance that the DOM is going to get flushed and we won't have access to any of these menus any more. Let's see when exactly the 'role emptying' of the DOM happens.

Navigate to the DOM and expand the CurrentUser node. Right click on the currentuserName element and click 'Break on Property Change'. You now have a DOM breakpoint set which are also visible in the Breakpoints menu in the right pane of the Script Tab (You may have to scroll down). Let's now logout and see if this gets triggered.

Yes! The DOM breakpoint is triggered and points us to the exact line of JS code that was editing the property. Click F8 and then go back to the DOM to see if there actually was a change and you'll find that the same property is now "undefined". Which means the DOM breakpoint did work :). This is extremely useful when you can see the exact path of an interesting element in the DOM but don't know where its corresponding JS code is.

 Other useful features:

There's the 'Break on Next' feature which will break on the immediate next script. I want to see what happens as soon as I click login? Click the Break on Next button and then click Login.

As mentioned by a person who read the previous article, you can set XHR breakpoints if you want to break on a specific XHR call; that's the easiest approach to do things...many a time. Break on the XHR and then use all these other techniques. Similarly you can also break inside the HTML tab when an attribute is added or removed. Make sure though that you're clicking on a leaf node...the last node...the attribute. You can't break on a non leaf node. The same logic applies to DOM elements as well.

If you want to look at the entire Call tree. For example: If you've broken on isEditor and want to know where it is called from you can look at the Stack (middle menu - right pane - Script menu). The most recent function is at the top and the first caller right at the bottom.

That apart you can edit HTML, add elements, destroy or modify cookies and possibly many other little things. To know everything this fantastic tool can do go on to its webpage and read the documentation :).

Hope you liked this small series. Again..if you  missed it.. here is Part 1.

Javascript application testing - Firebug

Recently I was testing a Javascript application. By Javascript application what I mean, is that a lot of the business logic was written on client side. Now it's a reasonably well known fact that client side logic is easily by-passable.

There's plenty of ways to do it ..intercept in Burp, delete the Javascript from the cache folder on your disk, create your own forms or use Firebug. Maybe more. Largely though I find that a combination of manual probing to detect where client side validation is being used, intercepting every single request for every file type and then dropping the Javascript request responsible...works.

There are times though, like in my last application where the entire UI of the app is constructed client side, where dropping Javascript will not load the app at all or mess it up bigtime. So Burp, in such cases, while you can still certainly use it...is not the best tool for the job. The next thing you will hear, if you google about 'Client side testing' is that 4 out of 5 people will say - Use Firebug.

Now once you understand it, it's an absolutely fabulous little tool to use but until then, it can get a little frustrating to use. So what I'm going to do here is to just point out the features I use the most and why I do so.

Inspect Element

The first feature that I use a lot is the 'Inspect Element'. You can open up Firebug and click the button that's highlighted in Red below and then move your mouse over the upper half of the page. As you hover over each part of the page, the corresponding part of the HTML in Firebug will start flashing. It's all in real time.

When you're clear which bit of the page you want to look at in Firebug, click on that element. Firebug too will stop flashing around. I tend to use this a lot when I want to look at the attributes set for a particular form. For example: If I want to check if the autocomplete attribute has been set on the password element, I can focus just on that and click. Then I can read the HTML on that page in the lower pane.

If you want to change the maximum length of an input field in a form, you can double click on the bit you want to change, and enter a new value. The key here is to ensure that whatever you're typing in is syntactically correct otherwise Firebug won't make the change and will leave you frustrated. For example: If you're entering a string, make sure you put it between double quotes.

Javascript

If you want to change just a part of the Javascript on a page, click on the script tab and then reload the page. All the Javascripts on that page will get loaded. Now you can click on the little drop down there (marked in Red) and see all the Javascript loaded. Click on any one to load it up in Firebug. Don't keep clicking on the dropdown marked in Blue. That's just the main tab that you can use to get there.

If it's a small application you might want to manually review the Javascript on each page. Click menu - Let Javascript load - Review. Repeat the cycle. If it's a huge application like the one I was testing though, there's a high chance you'll go mad very quickly :). Trust me. So you need an upgrade to your testing technique. That's where the DOM tab comes in.

DOM

Anything that's loaded in the browser will read/write something from the DOM. Now lets say you loaded a page up which dealt with logging in to an application and you want to check if the authentication logic is client side. That'd be a rare thing and largely quite a stupid thing to do, but it'll do for now :).

So if it is, there's a chance that some JS functions are being called. But you don't know which one and in which Javascript. So as soon as the login page loads, click on the DOM tab and scroll down a little. In whatever Javascript applications I've seen, there's usually a tree full of elements at the top of the DOM. All the reading and writing from/to the DOM happens here. Just below that though there is a large list of functions (all in green font) as shown in the figure below.

Now read through all of those names and make a little list of which functions 'sound' like performing a login sequence. If you click on each of those functions in the DOM, you'll immediately jump to the Javascript which has the code for that function. NOW you can study just that code and see if its insecure. Yes, you're still studying code..sure..but at least the scope is reduced a little.

Setting Breakpoints

Now we've made progress and come up to a point where you know what bit of code is "possibly" doing what. I say possibly, because you haven't actually run it or in this case, clicked on the login button to actually make it happen and see if THAT function is triggered. Let's now confirm that.

If you look at the screen-shot below it'll show you the exact line number on which those 2 functions are called. You want to make sure that those ARE called. So you set a breakpoint on those lines. A breakpoint, for anyone reading this and not too familiar with the term does what it says. It breaks. Breaks what? Execution. Of what? Code. What code? Javascript. When? When I click login.

So I'm just saying..I'll click Login and if the code here is triggered and my guess was right..don't go on. Stop right there. Set breakpoints as follows..set it on the first line of the function and not the definition itself. I'm not sure the line that has "function" is triggered; it may be..I'm just not sure as I haven't had success. Here's a screen-shot with the breakpoints.

Now try and login..

Yeah..actually put in a user-name and password..and login. If your function guess was right, you should stop right where you put a breakpoint. If it doesn't stop, it's the wrong path flow for THAT function. So maybe there's some other place login is called. Search for all such instances..and whenever you see a function with login in it...set a breakpoint.  Here's a screenshot where I've searched for login, a breakpoint has triggered and the credentials I entered can be seen in the Right side pane.

Now it's like Burp inside a browser window :). Read. Edit. Forward. Only the forward button here is the Continue button .. the right pointing arrow. If you want to go Step By Step and see what happens...and many times you will want to do this, you can use the Step Into or F11 key to now proceed line by line and watch the path the code takes. Again..when you're editing stuff..make sure you are syntactically correct. Otherwise the change will not persist.

Adding to the DOM

So the last cool feature in Firebug that I'll go over today is how you go about adding an element to the DOM. So suppose you want to add a parameter called 'admin' and set its value to 'YES' so you can try logging in as admin, you have to use the Firebug console to do so. So first decide where you want to add the property.

Once you're clear right click on a different property; in this case any root element like PR_TAB_WIDTH and say "Copy Path". Then click on the leftmost tab called Console and paste the path into the bar at the bottom and change its name and value. Like this..

And hit Enter. Now go to the DOM and you should see a new property called Admin with the value YES. It didn't work here of course..to give me admin privileges, but you get what I am trying to say :)

So that's it...start playing around with Firebug, it's a supremely powerful tool, specially when you're testing JS applications. Until next time..Cya :)