The Next Evolution of Browser-Based Pen Testing Kits: OWASP PTK
Imagine if there was an open-source add-on that turned your browser into a powerful and feature-packed application security testing kit. How much would that affect your output and productivity? Imagine if it was also free. How much would that affect your bottom line?
- Where did the idea for OWASP PTK come from?
- How did you improve on the current browser-based methods?
- What was the biggest problem you had to solve with OWASP PTK?
- Why did you choose to make OWASP PTK browser-based?
- What is the driving force behind keeping OWASP PTK effective?
- How is OWASP PTK evolving offensive security?
- What is on the horizon for OWASP PTK?
Where did the idea for OWASP PTK come from?
Dennis: My work in application security began in 2011, and it was only by luck that I started where efforts to advance automated pen testing had begun. I was hired as a research engineer by a fledgling startup and became part of a team on the verge of achieving critical advancements in the field. I’ve since been involved in web application security work exclusively, and working within the browser (Chrome and Firefox) is a mainstay. This work intensified with the onset of modern web technologies like SPA and Javascript frameworks, which were much more browser-dependent.
These experiences sparked the idea of developing a utility to provide easy access to pivotal information about an application's workings to solve not one but two problems I was having then. The first was to relax my fear of browser-based vulnerabilities becoming hidden, and the second was to speed up my reconnaissance work.
Initial PTK development work began shortly after that.
How did you improve on the current browser-based methods?
Dennis: I started by combining as many existing extensions as possible to eliminate having to install each one. Then, just after Rapid7 purchased the Dynamic Application Security Testing (DAST) technology I’d worked on for years, known as "NTO Spider", I began noticing a problem working with multiple applications. Becoming necessary was a better insight into the underlying technologies (MPA, SPA, framework, API authentication, how many domains are behind the front end, etc.).
I overcame this obstacle by putting a Wappalyzer NPM module in the PTK to provide a better understanding of the technology stack and specific rules to see if any WAF/CDN is in place.
What was the biggest problem you had to solve with OWASP PTK?
Dennis: As far as I can recall, authentication handling is the most formidable challenge to achieving a valuable DAST scan output. An authentication mechanism must be configured and functioning correctly to succeed, which, at best, is time-consuming. Solving this problem became central to my objectives for the PTK, which was then rapidly expanding. However, with a growing number of SPA applications as fuel, the problem became more chronic. This, in turn, produced intense pressure for support from users of Rapid7’s commercial DAST scanner with authentication-related difficulties.
It took a custom version of PTK I built to include modules for recording HTTP traffic macros linked back to the scanner for replay to solve the problem. It was revolutionary development at the time, I’ve been told. That it solved a dire business problem while giving the PTK’s usefulness a big boost was gratifying. So too, was Rapid7 releasing its own branded version of the plugin solely powered by PTK codework.
Why did you choose to make OWASP PTK browser-based?
Dennis: As I worked to refine the PTK’s ability to offer quick and reliable access to the application stack came the idea for the tool's next big step forward - running a vulnerability (DAST) scan while in the browser. An idea intended to solve an array of problems - no need to think about authentication as it's already handled by the browser – letting the PTK focus on tracking all requests and responses and sending modified requests with different attacks like SQL or Command-Line Injections.
Moreover, it opens the door to even more advanced and out-of-the-box approaches, such as using a window postMessage mechanism to bypass WAF protection and still execute XSS. One of these specific attacks is the JWT None algorithm attack, where the PTK can identify the weakness in your JWT library and exploit it on the fly.
What is the driving force behind keeping OWASP PTK effective?
Dennis: Bad actors will continue finding new and clever ways to compromise enterprise technology assets, such that specialized tools (like the PTK) will be only as good as their attack surface coverage.
We intend to be fastidious about keeping the tool up-to-date and relevant. For example, to be a step ahead, support for SCA for javascript was added, allowing the real-time ability to analyze third-party javascript libraries for known vulnerabilities. Thus providing a one-click option to better understand your application's security posture.
How is OWASP PTK evolving offensive security?
Dennis: The PTK provides a mechanism that allows many to get value from it. A manual penetration or vulnerability tester can use the PTK to gain insight while learning the workflows available. It will provide further insight into where to explore further.
Additionally, testers can take advantage by not having to understand in-depth security tests but being able to execute them while they are doing manual testing processes. Lastly, developers can leverage the PTK while they are building the applications. The user interface/user experience and backend teams can all leverage it. The ability to test without configuring a third-party tool and worry about connectivity or proxy issues can genuinely provide a “Shift Left” experience for security.
What is on the horizon for OWASP PTK?
Dennis: Other useful security-relevant tools have been added to the PTK over time; Decoder/Encoder, Swagger, and Session Lookup ability for researchers working with any application, to name a few.
Most recently, Chrome Manifest V3 with declarativeNetRequest API support and cookie editor functionality has been added. In 2023 a Request Builder, Custom Attacks, Selenium Support, and Javascript IAST Scan are on the PTK dev roadmap.
Additionally, from my long-standing partnership with the unsurpassed appsec automation experts at True Positives, some degree of integration with their just new to market managed DAST service, True Inspect, is being discussed. And they are also experts with the OWASP PTK across North America.
