Articles — scnr

Hello all, I wanted to share some Codename SCNR scripting kung-fu with you. This is something you can use post-scan, to exploit/validate your DOM XSS vulnerabilities. It can get tedious repeating the same steps manually over and over while exploring DOM XSS, but this script will help you automate the boring parts and leave you with all the fun. It will also allow you to intercept and inspect HTTP traffic from Ruby, in the form of HTTP::Request and HTTP::Response objects. In addition, you can still also chain Burp or ZAP to further your investigation.   Happy scanning! - Tasos L.

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

New products and their terminology can be daunting, especially when it has to do with architectural things. To take care of this issue, this article will serve as an introduction to SCNR's distributed terminology, features and the entities that provide them -- bare with me because they aren't that many. However, since there are several different possible setups and ways to spawn scanner processes, this post is going to be on the large side, as we'll be taking the long route. Don't worry though, this doesn't mean that SCNR is complex, quite the opposite; it allows you to avoid complexity...

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