Articles — tracer

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...

Frustratingly enough, something fishy is going on with an input you're manually checking but you can't quite put your finger on it. There must be something going on within the flow its value follows throughout the client-side but its complete behavior eludes you due to high complexity. Break-points need to be set and notes to be kept. Well, fret no more! Codename SCNR to the rescue with its client-side data-flow tracing!   What I'm talking about is this: You configure a taint for the JS environment -- i.e. a value that SCNR needs to track. You operate the browser via...

So, suppose we're preparing a manual penetration test of a web application; wouldn't it be nice to be able to know beforehand the behavior of each individual input? For example, changing an input's value may change the response we get in a certain way, or even not, which is equally valuable information. Let's say that inputs that change the behavior of the web page are called active and those that don't are called blind. Furthermore, it would be of even more interest if the value we input gets included in the HTTP response (or even written on the DOM client-side)...