Read on Twitter
Putting the Burp Suite Pro 2020.8.1 embedded browser through its paces today. Follow this thread for information as it becomes available. I plan on testing it in 2 phases against 2 different applications.
Phase 1 will be unauthenticated with permission to self-register. Phase 2 will be forced authentication with known credentials and no self-registration.
App #1 will be a MVC app with server-side rendered view and a mix of HTML and event-triggered behaviors. App #2 will be a client-side rendered app with a RESTful backend. Both apps have the capability of doing OIDC. If the crawler gets through native forms auth, I& #39;ll try that.
Starting over with Burp Pro v2020.9 since it was JUST RELEASED DURING MY TESTING...
Results for App #1: Phase 1 and 2 netted same results. Out of 18 easily discoverable dynamic resources, the crawler found 8. Of the 8 found, 4 were JS rendered, so it& #39;s doing something, but 9/10 missed were also JS rendered, which is discouraging.
Okay. I& #39;m just going to quit App #2 at Phase 1. It found the static JS files that build the client front end... and that& #39;s it. The crawler didn& #39;t resolve a SINGLE REST resource. Giving it creds won& #39;t help. So... my final analysis here in a minute. Gotta draft this up...
The embedded browser crawling capability in Burp Suite Pro is minimally, if any, better than it was several months ago. (1/10)
I& #39;ve been testing the crawler against JavaScript rendered apps since Burp v2 beta came out and the embedded browser capability was announced. It has never been effective, and as you can see in this thread, remains limited in stable release. (2/10)
For a DAST platform designed for a set-it-and-forget it approach, the current crawler is not a viable option. If a scanner cannot find JS rendered content, then it can& #39;t test it for vulnerabilities. If it can& #39;t test for vulnerabilities, it is useless. (3/10)
Since Burp Scanner is the core of Burp Enterprise, I must warn potential customers to be wary. You may not be getting what you expect. In addition to the crawler, Enterprise only understands native single-factor forms auth. This is a whole other issue. (4/10)
These problems are not unique to Burp. The DAST market is wrought with products that can& #39;t handle modern application architecture, and I don& #39;t know of a single one that can. They are trying to accomplish a near impossible task. (5/10)
DAST solutions are attempting to automate the job of a zero-day exploit developer. You& #39;d never see this attempted in any other space for a reason. Too much human context is required and there& #39;s too many variables. (6/10)
Burp Suite Pro still stands as the best manual analysis tool on the market for security testing web apps, and what my personal research continues to reveal is that it has never been more important to have applications tested manually. (7/10)
DAST solutions simply cannot effectively discover modern applications, and even if they could, cannot analyze with the context that is needed to discover authentication, authorization, session management, and business logic issues. (8/10)
@PortSwigger I know this thread isn& #39;t good news, but it& #39;s honest news. I appreciate the efforts you are making and the tools, information, and products you provide to the community. We wouldn& #39;t be nearly as effective with you. (9/10)
@PortSwigger Please feel free to contact me directly to discuss this and further research. I& #39;m always up for helping to improve things. (10/10)
