Re: [W3af-develop] Crawling RIAs

[Andres R. <and...@gm...>]

Daniel,

On Thu, Jun 28, 2012 at 12:56 AM, Daniel Zulla <da...@de...> wrote:
> Probably I need to add something, in order to clarify the code snippets:
> I patched my Webkit browser engine to automatically modify the
> .attributeList of a QWebElement as soon as a JSEvents is attached to it.
>
> So I automatically get every event by simply iterating through the
> attributelist, looking for on*= -

That sounds interesting! We might end up doing something similar to
that; but I hope we can avoid modifying ANY C/C++ code.

> but you may need to find another approach
> because what you use right now looks a lot like PhantomJS.
>
> Correct me if I am wrong.
>
> Best,
> Dan
>
>
> I agree. My response was not very clear.
>
> Actually, what I wanted to state:
> There are two different approaches to detect those custom events. If I
> interpret your E-Mail correctly, you are about to use the static approach /
> you want to parse the HTML Tree to extract hard-coded onsomething="" events.
>
> Of course there is nothing wrong with that, but you may also want to extract
> the custom events of every WebElement the dynamic way. If you simply walk
> through the HTML, you may miss something like
>
> jQuery.bind('onmouseover', some_element);
>
> some_element may now be listening to the onmouseover event, but if you only
> parse the element attributes, you may miss that.
>
> I've copy&pasted some code of my own project to explain my solution for the
> problem:
> https://gist.github.com/1540f8b3bfc866b907f8
>
> Best,
> Dan
>
> Daniel,
>
> On Thu, Jun 28, 2012 at 12:18 AM, Daniel Zulla
> <dan...@go...> wrote:
>
> You will need a function that simply returns a list of tuples:
>
> [0] -> the Web Element (a, form, ...)
>
> [1] -> a anonymous function that fires the event
>
>
> Yes, that makes sense, but isn't it the same as the following?
>
> * For each state in which the automated browser is in, be able to
> return a list with all the custom events available (ie. if there is a
> tag with <div onmouseover="..." this should return something like [(
> <div object at 0x...>, 'onmouseover')] )
> * Send an event, for example ( <div object at 0x...>, 'onmouseover'),
> to the current DOM
>
> The anonymous function and the list of tuples is an implementation
> detail that might change from one library to the next one, right?
>
> It is pointless to fire arbitrary events against WebElements -
>
>
> If I have the possibility to send an event to a specific tag; and I
> have the list of tags with custom events, I think it makes sense to
> just send those. I think I won't send events to things that don't have
> custom on...* handlers (maybe click a link? not sure yet, just want to
> have generic requirements that allow me to experiment later).
>
> At some point, you will want to ask a WebElement which Events it is waiting
> for.
>
>
> Same/Very similar to the following?
>
> * For each state in which the automated browser is in, be able to
> return a list with all the custom events available (ie. if there is a
> tag with <div onmouseover="..." this should return something like [(
> <div object at 0x...>, 'onmouseover')] )
>
>
>
> List,
>
>
> On Wed, Jun 27, 2012 at 5:16 PM, Andres Riancho
>
> <and...@gm...> wrote:
>
> Taras,
>
>
>    This might be an interesting read for your ajax research:
>
>
>  http://blog.watchfire.com/wfblog/2012/06/automated-blackbox-crawling-the-next-generation.html
>
>
>    After reading this paper, I came up with a requirement list for
>
> our RIA crawling engine, the algorithm we implement afterwards is
>
> independent from the requirements; but with these it should be
>
> possible to do almost anything:
>
>
> * Load an URL
>
> * All HTTP traffic from the automated browser should go through an
>
> HTTP proxy we define
>
> * For each state in which the automated browser is in, be able to
>
> return a list with all the custom events available (ie. if there is a
>
> tag with <div onmouseover="..." this should return something like [(
>
> <div object at 0x...>, 'onmouseover')] )
>
> * Send an event, for example ( <div object at 0x...>, 'onmouseover'),
>
> to the current DOM
>
> * We need to be able to store events like ( <div object at 0x...>,
>
> 'onmouseover') in order to store a path and replay it if wanted
>
> * Ability to tell if the latest event that was sent by us caused a
>
> full DOM reload or not
>
> * Dump current DOM (with all JS and external resources) to a string.
>
> Useful for comparing two states and restoring a state
>
> * Load a stored DOM into the automated browser instance. This restores
>
> a saved state.
>
> * (optional) Take screenshot of current page
>
>
>    @all: Any other thing you can think of?
>
>    @Taras: What's provided by the library you're currently experimenting
> with?
>
>
> Regards,
>
>
> Regards,
>
> --
>
> Andrés Riancho
>
> Project Leader at w3af - http://w3af.org/
>
> Web Application Attack and Audit Framework
>
> Twitter: @w3af
>
> GPG: 0x93C344F3
>
>
>
>
> --
>
> Andrés Riancho
>
> Project Leader at w3af - http://w3af.org/
>
> Web Application Attack and Audit Framework
>
> Twitter: @w3af
>
> GPG: 0x93C344F3
>
>
> ------------------------------------------------------------------------------
>
> Live Security Virtual Conference
>
> Exclusive live event will cover all the ways today's security and
>
> threat landscape has changed and how IT managers can respond. Discussions
>
> will include endpoint security, mobile security and the latest in malware
>
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> _______________________________________________
>
> W3af-develop mailing list
>
> W3a...@li...
>
> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>
>
>
>
>
> --
> Andrés Riancho
> Project Leader at w3af - http://w3af.org/
> Web Application Attack and Audit Framework
> Twitter: @w3af
> GPG: 0x93C344F3
>
>
>



-- 
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3