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 :)
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 :)
1 comment:
Thanks for sharing the post..Application testing is the best techniques for making your system well tested..Thanks for sharing the post..Really nice post..
Automatisation Tests
Post a Comment