Burp Suite Website Scanning

2/15/2022by admin
  1. Burp Suite Website Scanning System
  2. Burp Suite Website Scanning Service

PortSwigger recently wrote a blog post on API Scanning with Burp Suite. It explained how Burp’s crawler parses OpenAPI documents and how it will create sample HTTP requests for endpoints mentioned in the OpenAPI doc. I even covered that in my newsletter.

5 Burp Suite - GUI proxy server for manual analyse of HTTP and Websocket protocols › Everyone in our team uses Burp Suite › The ability to write your own plugins › Large open source community › New approaches, researches from the creators of the product. In our last Burp Suite Tutorial we introduced some of the useful features that Burp Suite has to offer when performing a Web Application Penetration Test.In part 2 of this series we will continue to explore how to use Burp Suite including: Validating Scanner Results, Exporting Scanner Reports, Parsing XML Results, Saving a Burp Session and Burp Extensions. BReWSki - BReWSki (Burp Rhino Web Scanner) is a Java extension for Burp Suite that allows user to write custom scanner checks in JavaScript. Extensions for assessing Single sign-on (SSO) and OAuth related applications. SAML Raider - SAML Raider is a Burp Suite extension for testing SAML infrastructures. It contains two core.

I created a demo environment using the Vulnerable API (vAPI) project to see Burp’s API scanning capabilities over real-world projects. vAPI is an intentionally vulnerable API implemented using Python Flask.

(If you want to see manual analysis and exploitation of vAPI by Matthew Valdes, please check out my write-up).

For this example, I am using jorritfolmer’s vAPI fork. This forked version, unlike the original, is implemented using Python Flask + Connexion and exposes OpenAPI JSON doc at the /openapi.json endpoint.

Also, the forked version has some disadvantages:

  • it doesn’t support XML payloads (meaning XXE is impossible)
  • a GET endpoint is missing (which deleted an information disclosure issue)

Importing the API definitions to Postman gives the following requests:

The exposed API endpoints in OpenAPI doc are:

Now let’s see if our vAPI environment meets API Scanning’s prerequisites.

PortSwigger’s API scanning documentation says the OpenAPI must be of 3.x.x version, and the API definition must not contain any external references. Luckily the OpenAPI doc from the vAPI project follows both - it uses OpenAPI 3.0.1 and doesn’t have any external references.

Active scanning vAPI

I opened the / path of vAPI and found the following JSON output.

Let’s assume that Burp’s active scanning will automatically discover the /openapi.json endpoint and then parse the document to add more paths.

Goto Target -> Site map -> Right Click on target -> Actively scan this host

The audit finished pretty fast and didn’t find the /openapi.json endpoint. But the active scanner bruteforced multiple query parameters for the known endpoints.

Discover content and Active scanning vAPI

Our above assumption was wrong. Maybe that’s because vAPI doesn’t have any webpages / URLs mentioned that link to OpenAPI doc.

Now let’s see if Burp can discover this endpoint with its Discover Content option.

Goto Target -> Site map -> Right Click on target -> Engagement tools -> Discover content

I launched the discover content session with the default configuration without any custom wordlist.

Once the discover content session is complete, we see it has found two endpoints: /console (with different query params) and /user.

Burp has found a /console endpoint that’s not documented. The /console endpoint exists because the Flask app runs in debug mode. The debug mode is indeed an issue, but it’s because of the server, not API.

It hasn’t found the openapi.json file yet.

Explicitly adding openapi.json to Burp Crawler & Scanner

Maybe passing the OpenAPI file directly to Burp’s crawler and scanner might work.

Goto Dashboard -> New Scan -> Paste the URLs -> Click OK

I will use the default configuration of Burp Scanner for the scan.

Yaay !! It did find new endpoints and find issues with them.


The endpoints /tokens and /uptime are new, and Burp seems to have fetched them from the OpenAPI doc. Burp still hasn’t found endpoints like /uptime/:flag, /widget, /users, etc.

The detection phase was better than before. Let’s see if the Burp scanner has found all vulnerabilities.

vAPI’s documentation says that the project has the following vulnerabilities:

  • Insecure transport
  • User enumeration
  • Information disclosure
  • Authentication bypass
  • No input validation
  • SQL injection
  • Weak session token crypto
  • Poor session validation
  • Plaintext Storage of secrets
  • Command injection
  • Regex denial of service
  • Cross-Site Scripting
  • XML XXE and billion laughs (Connextion doesn’t support XML content-type yet)
  • Missing security headers

From the above vulnerabilities, Burp Scanner cannot find the following vulnerability classes (according to Burp Scanner’s Issue Definitions):

Burp Suite Website Scanning System

  • Information Disclosure (unless the information is email addresses, private IPs, SSN, credit card numbers, etc.)
  • Regex denial of service

It’s hard to give a general context of a user/object, roles, & permissions to security scanners. So security scanners, in general, can’t find issues like:

  • User enumeration
  • Plaintext Storage of secrets
  • Authentication Bypass (As SQLi can be used to bypass the requirement of admin token to create user)

However, Burp Scanner found these issues:

  • Insecure transport (Issue: Unencrypted Communications)
  • No input validation (Issue: Input returned in response - reflected)
  • Cross-Site Scripting (Issue: Cross-site scripting - reflected)
  • SQL Injection (Issue: SQL injection)

What am I trying to say?


Let me summarize.

Suppose you want to scan an API server that exposes OpenAPI doc; Burp Scanner parses the OpenAPI doc only when you explicitly specify the file path while starting Active Scan. Even if it parses the OpenAPI doc, it misses out on specific endpoints (for reasons unknown) and required headers. Not supporting additional HTTP headers is a known limitation of Burp Scanner for API testing.

Burp Crawler’s job of crawling API endpoints from OpenAPI doc is not bad, but there’s more to improve. Burp Scanner seems to do an excellent job on scanning independent API endpoints (if found from OpenAPI docs, like search, login, etc.), but not on logically dependent APIs (like delete API works only after create API was successful).

For security engineers:

If you have any current automation to test APIs (like Postman Scripts -> Burp Suite -> Burp Scanner / Custom Extensions), don’t replace the automation with only Burp Suite. Instead, if you are interested, run it alongside your existing automation. Don’t forget to check Burp Suite’s limitations for Scanning APIs. Remember, Burp Scanner can scan for vulnerabilities on independent APIs, not on “logically dependent” APIs.

Burp Suite Website Scanning

For bug bounty hunters:

Burp Suite Website Scanning Service

If you found an endpoint that discloses OpenAPI docs, explicitly “crawl and scan” the endpoint. You might end up finding something juicy. Even though Burp doesn’t crawl and load all APIs, something is always better than nothing. If you want to understand APIs' logic, load the OpenAPI doc in Postman and manually test them.

Comments are closed.