rajeshdilli_at_yahoo.com wrote:
> Hi,
>
> I've been recently going around the web for a couple of challenges
> that AJAX faces. One thing that struck me was the web application
> scanners. I've seen a few vendors (i don't to mention any vendor or
> product name here) products that claim that they have javascript parsers
> and support for AJAX driven applications. My personal experience with
> these tools is that they could not spare well against apps that are
> heavily JavaScript driven and with the introduction of AJAX based apps
> it's a case of uncertainity in choosing the right product (if at all
> there can be one which can progress in auditing AJAX applications). Do
> any of you have any insights or experinces on these tools against AJAX
> based apps.
>
> Thanks
> Rajesh
>
As the author of WebScarab, I've thought about this a bit ;-)
This is a bit of a brain dump about the difficulties and complexities of
supporting JavaScript in an automated tool.
Primarily, there is the issue of state. If you were to parse the
javascript, and start executing it, the state of the browser would be
continuously changing. You'd probably want to execute any onLoad-style
events, and then snapshot the state at that point, before executing any
more of the on* event handlers, probably rolling back in between, so
that the execution of the event handlers does not negatively affect the
state of the "browser" when trying to execute the others.
The implementation of the javascript engine would probably want to watch
for various calls such as window.open, url.location=, xmlhttp.whatever,
and all their variants, in order to pick up new URL's to test, and would
want to look at the contents of any POST submissions that get formulated.
The issue of state is complicated by the fact that the execution of some
events will depend on the state of other DOM objects. e.g. I have to
check a box, before the radiobutton event will do anything. If I'm
rolling everything back to the initial state, clearly that radiobutton
event will never do anything useful.
So, you might choose to not roll the state back after each event has
been called. So, how do you ensure that you trigger the events in a
suitable order to actually achieve coverage of the application logic?
Maybe some of the boffins working on tools such as Clover, and other
java test coverage tools might have an approach? I certainly don't!
The next complication extends the state issue a bit. What about frames?
Cooperating frames can reference function calls in scripts in other
frames. This means you now need to try to track the currently loaded
frameset, and the state of all the other participating frames as well.
Now, how do you roll back? Or do you? And if you don't, or if you do,
how do you address the issue of code coverage now, in a loosely typed,
interpreted language?
Some people might read this as an excuse for my not implementing ANY
JavaScript support in WebScarab. They'd be right! ;-) My brain overheats
just thinking about it!
Regards,
Rogan
P.S. Please check your destination addresses if you wish to reply to me
personally. My email address is obscured to reduce the amount of spam
and list bounces I receive. All emails to discard_at_dawes.za.net get
tossed without me ever seeing them.
-------------------------------------------------------------------------
This List Sponsored by: SpiDynamics
ALERT: "How A Hacker Launches A Web Application Attack!"
Step-by-Step - SPI Dynamics White Paper
Learn how to defend against Web Application Attacks with real-world
examples of recent hacking methods such as: SQL Injection, Cross Site
Scripting and Parameter Manipulation
https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------
Received on Mar 28 2006
Intro
