A new plugin has just been added to Codename SCNR called "sink_tracer" and it takes advantage of SCNR's input sink tracing capabilities to provide insights into the inner workings of a web application from a penetration tester's point of view.
Some very interesting technology was presented a few days ago in the following articles: Following the data: Taint-tracing in the JS environment Following the execution: Taint-tracing in the JS environment Client-side crawl: A DOM state exploration Thusly, I'd like to clarify how it is used during scanning by Codename SCNR. Through continuous monitoring of each page's JS environment, Codename SCNR can handle Single-Page-Applications like a breeze, something notoriously difficult to handle by most DAST solutions, since they're only, well...DAST. Let me clarify, Codename SCNR is marketed as a DAST product, but that's only when it comes to the server-side, and...
In our previous article we discussed data-flow tracing, i.e. following a piece of data as it travels through the JS environment of a page. In this article we're going to concern ourselves with tracing the execution flow of the page. Imagine this scenario: either via manual or automated testing we managed to identify an input vulnerable to XSS. Wouldn't it be nice if we could track exactly that vulnerability came to be? Well, we're going to soon find out. The methodology isn't that much different from data-flow tracing, the only difference is that we're going to be using a little...
Say you need to do a manual pentest on a web application with a lot of client-side code, like a single page application of the AngularJS sort.
It would be very helpful to understand how the app transitions through different states based on DOM events. For example, which flows lead to which results, and also the steps for those flows.
What we're talking about here is basically a client-side crawl.
With a simple script, you can print-out the client-side crawl that SCNR does and keep those result at hand to help you with your manual audit.