There have been exciting developments for v1.1 and I’d like to ask for your help in testing the new goodies. We’ve got support for a new Ruby interpreter (JRuby), support for a new OS (MS Windows) support for new elements (XML and JSON) as well as some serious performance improvements.
MS Windows support via JRuby
It’s been a long time coming, but native Windows support seems to finally be here — barring any unforeseen show-stoppers, of course.
This feature has been requested for a long time so don’t be shy, help us test it, in hopes of providing an official Arachni Windows package for either the v1.1 release or a follow-up version.
Another cool thing about this is that Java application can now directly integrate with Arachni and Arachni can now directly use Java libraries, both due to JRuby. Don’t know how this may help, but it’s a nice capability. :)
Truthfully, Arachni does indeed run on Windows via the official Ruby interpreter, however there have been serious stability issues, which involve the process dying without any indication of what went wrong. Windows ErrorLevel codes point towards a memory access violation error, but that’s as far as I’ve gotten with that. If you’ve got experience with Windows debugging and the Ruby interpreter please do get in touch.
XML and JSON element support
A natural follow-up to adding real browser analysis is extracting XML and JSON inputs from requests and auditing them like any other element. The Framework can now do this for you.
There’s not much to say here really, auditing these elements is enabled by default and everything is automated.
If you’ve got sites that use XML or JSON in your pentest TODO list please give Arachni a spin and let us know how it does on that front.
The focus during the development of Framework v1.0 was, of course, the architecture surrounding the browser analysis. It was a conscious decision to provide a clean, scalable design but avoid clever optimizations, and instead introduce them carefully and in small batches.
The sheer complexity of that system mandated that stability and feedback from real-world use-cases be the top priority — I’d rather optimize a working system rather than fix a fast one.
Here’s the first batch of optimizations:
- An inter-browser, inter-scan, shared, HTTP resource disk cache has been enabled. The first time a browser hits a cacheable resource it will save it to disk and subsequent browser calls (from any browser worker) and subsequent scans won’t have to request it again.
- The browsers are now smarter and can determine when forms and cookies are actually involved in DOM processing, and thus avoid unnecessary (and costly) DOM audits.
- This wasn’t that hard for forms, just paying closer attention to their associated DOM events.
- This was a bit tricky for cookies, as they’re not DOM elements, so the browsers are using their JS data-flow tracing capabilities to determine whether a page is using cookies at each given DOM state snapshot.
All in all, the above will save thousands of HTTP requests (which would be very slow, coming from the browsers) and thousands of browser DOM audit operations (and thus more thousands of HTTP requests).
The cache business was quite frankly an oversight, it should have been used from the start, my bad.
Take it for a spin
Now, down to business, as there are no packages yet, setting up Arachni can be a bit of a hustle, but clear instructions are available for both the Framework and the WebUI — the WebUI will automatically pull in the Framework, so you don’t need to setup both.
So, take it for a spin and let me know how it works. :)