A new version of IronWASP (@ironwaspsec) is here with some important bug fixes and a brand new feature - JavaScript Tracing!
I spoke about this feature and the technique behind it at nullcon last week and here it is as promised!
Discovering vulnerabilities on the client-side is a tough task particularly because of the lack of tools that make this possible. Dominator Pro is perhaps the only effective tool for finding DOM XSS right now.
I had tried to address this problem through static analysis, the very first version of IronWASP came with a fancy debugger-style visual taint tracking system. I had even debated the merits of static analysis with Stefano. But the short comings of static analysis are far too important to ignore.
Just knowing that the keyword eval is present in a page is of very little practical use, unless we know if it actually gets called and if it does then what were the values of the arguments that were passed to it. This can only be achieved through dynamic analysis, so after working together with Nafeez we made this possible in IronWASP.
This feature is very easy to use, the new version has a separate tab named 'JavaScript Tracing', check the 'Enable JavaScript Tracing' box and IronWASP will start logging dynamic events from all pages proxied through it. The events that are currently being traced are:
1) eval method calls
2) setTimeout method calls
3) setInterval method calls
4) Function method calls
5) XMLHttpRequest open and send method calls
6) Addition of new HTML elements to the DOM
7) Addition or updation of attributes of an HTML element
These events are logged under the sections 'Native Method Calls', 'Dom Changes' and 'Ajax Calls'. In addition these events are also analyzed to see if any portion of the URL appears in the sensitive sections of these events. If a match is found then it is shown under the 'Observations' section, along with some basic suggestions on how you can test to see if the observation is actually a valid security problem.
I opened google.com and searched for "ironwasp" after enabling JavaScript tracing and the tool captured:
23 calls to the eval method
737 instances where either a new node was added to the page or an element's attribute was modified
14 Ajax calls
And there were 3 instances where some part of the URL ended up in eval calls and in the new HTML elements that were added.
The image below shows the report corresponding to one of the observations.
This is version 1.0 of this feature. I have already got feedback for new additions from some of the wonderful people who attended my nullcon talk and also from Mario himself! I would be addressing these concerns in the future versions along with expanding the scope of the events we monitor. If you have any feedback that you think could help improve this feature then please do share them with me.
Happy JavaScript vulnerability hunting!
Please follow @ironwaspsec to keep track of all IronWASP related updates easily.
And now enjoy some pictures of mine taken during the talk. I now officially hold the record for the coolest shades worn by a speaker at nullcon, lets see if my record gets challenged next year ;)
Post by Lavakumar Kuppan
I spoke about this feature and the technique behind it at nullcon last week and here it is as promised!
Discovering vulnerabilities on the client-side is a tough task particularly because of the lack of tools that make this possible. Dominator Pro is perhaps the only effective tool for finding DOM XSS right now.
I had tried to address this problem through static analysis, the very first version of IronWASP came with a fancy debugger-style visual taint tracking system. I had even debated the merits of static analysis with Stefano. But the short comings of static analysis are far too important to ignore.
Just knowing that the keyword eval is present in a page is of very little practical use, unless we know if it actually gets called and if it does then what were the values of the arguments that were passed to it. This can only be achieved through dynamic analysis, so after working together with Nafeez we made this possible in IronWASP.
This feature is very easy to use, the new version has a separate tab named 'JavaScript Tracing', check the 'Enable JavaScript Tracing' box and IronWASP will start logging dynamic events from all pages proxied through it. The events that are currently being traced are:
1) eval method calls
2) setTimeout method calls
3) setInterval method calls
4) Function method calls
5) XMLHttpRequest open and send method calls
6) Addition of new HTML elements to the DOM
7) Addition or updation of attributes of an HTML element
These events are logged under the sections 'Native Method Calls', 'Dom Changes' and 'Ajax Calls'. In addition these events are also analyzed to see if any portion of the URL appears in the sensitive sections of these events. If a match is found then it is shown under the 'Observations' section, along with some basic suggestions on how you can test to see if the observation is actually a valid security problem.
I opened google.com and searched for "ironwasp" after enabling JavaScript tracing and the tool captured:
23 calls to the eval method
737 instances where either a new node was added to the page or an element's attribute was modified
14 Ajax calls
And there were 3 instances where some part of the URL ended up in eval calls and in the new HTML elements that were added.
The image below shows the report corresponding to one of the observations.
Happy JavaScript vulnerability hunting!
Please follow @ironwaspsec to keep track of all IronWASP related updates easily.
And now enjoy some pictures of mine taken during the talk. I now officially hold the record for the coolest shades worn by a speaker at nullcon, lets see if my record gets challenged next year ;)
Post by Lavakumar Kuppan
