There’s a new version out and you definitely don’t want to miss this one. A lot of effort has been put into this release and the improvements in performance, coverage, integration and portability (yes, there’s finally a Windows package) speak for themselves.
So, as usual, let’s go over the most important changes.
You can get the skinny on the performance changes from a previous blog post, however, more changes were introduced since then and these are the final numbers:
|Requests||Avg browser job duration||Duration||Requests||Avg browser job duration||Duration|
As you can see, anything having to do with the browser operations is now a few times faster than before.
In addition, you will see a significant drop in RAM consumption and CPU utilization.
The new version also has some important coverage improvements which will be discussed in a bit, so in reality there may be cases where the extra workload from the improved coverage may increase the scan duration, or it may not, some real world cases have even shown a 6-fold decrease in scan durations and 80% less RAM consumption, my point is that YMMV depending on the characteristics of any given web application, but the system is much faster and more efficient than before.
arachni http://testhtml5.vulnweb.com --audit-links --audit-forms
arachni http://testhtml5.vulnweb.com --checks -
There ware cases where previous versions of Arachni didn’t do so well, specifically, event delegation and effects.
Event delegation is tricky and even though the system had custom tracking for jQuery, it could not track event delegation when performed via other means (vanilla JS code or some other framework). This release rectifies this situation by building a sort of event inheritance tree between DOM elements, so now no events should be missed.
A somewhat common pattern these days is using effects to display certain functionality after triggering an event.
For example, a modal dialog fading-in after a button has been clicked; this requires the system to wait for a bit after clicking the button, otherwise the dialog won’t have a chance to show. If you check for page changes immediately after firing the click event, nothing will have changed yet and you’ll miss whatever functionality was exposed via the new dialog and there’s no direct way to know for how much to wait either.
However, this kind of functionality is usually powered by JS timers (like setTimeout()), so the system now checks for changes in those timers and if a new one appears after an event has been triggered, the system will wait for it to complete before proceeding.
Integrating with Arachni has now become easier than ever, thanks to the brand new super simple REST API.
For a quick taste of what using the REST API looks like, check out this brief example.
MS Windows support
And now, for the pièce de résistance, there finally is native MS Windows support in the Arachni codebase, as well as a nice portable package available for download.
I’m expecting the occasional bug to pop up of course, but as far as I know it’s stable — not as fast as when running on Linux and OSX though for some reason.
That’s all folks, enjoy and don’t forget send feedback.