These tools leverage the advantage that white hat penetration testers have over external attackers: they have access to server binaries/bytecode and the server-side source code.
A key part of assessing an application is determing its functionality and exposed endpoints.
Attack Surface Detector
Attack Surface Detector (ASD) performs static analysis on a web application’s source code to determine the endpoints it defines, including the paths, their expected HTTP verbs, and the names and types of parameters. It supports several languages and frameworks:
-
Java – JSPs, Servlets, Struts, Spring MVC
-
C# – ASP.NET MVC, Web Forms
-
Ruby – Rails
-
Python – Django
The value of ASD is in enabling testing, whether manual or automated, to be faster with better coverage.
-
When doing manual black box testing, it’s easy to miss endpoints if you’re time constrained. Also, there may be a legacy, insecure endpoint that is no longer used by the application but is still present and accessible if you know it’s there.
-
Getting high application functionality coverage is always a challenge for web app scanning tools (DAST), so by feeding in a set of known routes, better coverage can be achieved.
ASD has a plugin for both ZAP and Burp Suite, enabling easy ingestion of routes in JSON format.
A screenshot of ASD within ZAP
@Override
public void processToken(int type, int lineNumber, String stringValue) {
if (type == '{') numOpenBrace++; // oh no
if (type == '}') numOpenBrace--;
if (type == '(') numOpenParen++;
if (type == ')') numOpenParen--; // y u do this 2 me
if (type == '[') numOpenBracket++;
if (type == ']') numOpenBracket--;
if (type == '#') { // make it stahp
isInComment = true;
}
// ...
I think lightweight static analysis on web apps is an interesting and useful direction to investigate, and I’m always a fan of people building more useful static analysis tools, but as I mentioned in my 2019 ShellCon presentation, you almost always don’t want to build your own lexer or parser. Languages are incredibly complex, have countless edge cases, and evolve over time. Instead, you want to leverage an existing parser for the language (like whitequark/parser) or a parser that can handle multiple languages, like GitHub’s semantic.
I would also argue that dynamic analysis is a better fit for extracting web app routes, due to how loops and other dynamic constructs can programmatically generate routes, but that’s a grump for another time…
Code Pulse
Alright, let’s take a look at Code Pulse, the second tool described and demo’d in this talk. Code Pulse is an interactive application security testing (IAST) tool (vendor description), which basically means that it hooks into an application’s runtime / instruments the bytecode to give you live, continuous understanding of the code paths that are being executed. Code Pulse currently supports Java and .NET applications.
This has a number of benefits, including:
-
App owner / security tester: which parts of the application are actually being exercised?
-
Security tester: Has my input reached a potentially vulnerable code location? In theory, an IAST can tell you this even if your specific input would not have exploited the issue.
-
Which tools or testers are getting the best coverage?
By having better insight into the running application, testing can again hopefully be faster and more effective.
A screenshot of Code Pulse. Different JARs, classes, and JSPs are represented by different blocks
Demo
The demo starts at 26:28, where Vincent shows how Attack Surface Detector can be used to extract the routes from WebGoat. These routes can then be imported into ZAP, causing its spidering to be more effective.
At 36:27 starts demoing Code Pulse by uploading the .war file for JPetStore, an open source Java Spring app. Code Pulse generates an inventory for all the contained code, running Dependency-Check to look for out of date dependencies, Attack Surface Detector to extract endpoints, and instruments the web app’s bytecode to give you visibility into what code is running as you test.
Vincent shows how you can “start recording” in Code Pulse, log in to the application as one user and perform some actions, then record a new sessions with a different user. Code Pulse allows you to then easily visualize which code blocks were exercises by both sessions, as well as the code unique to one user.
Access Control Bug Heaven
This seems really useful for testing for access control bugs. I’d also recommend my friend Justin Moore’s Burp extension, AutoRepeater, which imho is the most powerful/flexible access control-related Burp extension.