Authentication licenses are per FQDN and you can add as many authentications to one target as you wish.*

Jump to the section of interest:

Methods of authentication

Scan scope

Minimising risk

SPAs

APIs

Configuring the scanner

Vulnerabilities

Results


Methods of authentication

My application requires multiple forms of authentication (e.g. reCAPTCHA)

At this time (v1.0) we cannot scan an application which requires multiple forms of authentication or prove-your-humanity checks – you can only choose one of the four methods listed in the AWAS User Guide. A possible workaround, if you need one, would be to allow Intruder scanner IP range to bypass one form of authentication.

Authentication is handled by a different domain

For example:

Target: test.com

Entrypoint: test.com

Login request URL: blue.com/login

Currently (v1.0) the scanner will only authenticate to URLs which are within the scope to be scanned. For example, if the entry point is test.com/app, the logout URL would need to be something like test.com/app/logout. If you use a separate authentication domain you can potentially workaround this constraint by setting a long-lived session token (~24 hours) on your target application and using the session-based authentication method.

After authenticating, there is a login redirect.

For example:
Target: test.com

Entrypoint: test.com

Login request: test.com/login➡️ Redirect: blue.com/dashboard

The scanner can't handle this, so the solution would be to add blue.com as the target and set blue.com as the Entrypoint and you'll need a session token, because you aren't authenticating via test.com/login.

Can I configure MFA bypass on your scanner?

No. Currently (v1.0) it is not possible for our scanner to bypass multi-factor authentication checks. You will need to authorise our Intruder scanner IP range or the user account that you specify in your Authentication to bypass the checks. An alternative workaround is to use a long-lived session token (~24 hours) and use the session-based authentication method.

Can the scanner authenticate using SSO?

No, currently (v1.0) our scanner will not be able to follow specific SSO authentication workflows (including AWS Cognito/SSO, Google Identity, Microsoft AzureAD, Okta, OneLogin, Auth0, JumpCloud etc). Instead, you will need to implement one of the following so that the scanner can bypass SSO:

Authentication uses a JSON-based form

Unfortunately we don’t support applications that have a JSON-formatted login request. Instead, we would recommend using one of the following, if possible:


Scan scope

Can you scan/crawl multiple domains associated with a single application?

No. At this time (v1.0) our scans are scoped to the target on which you add your authentication. That means that if you add an authentication to portal.intruder.io the scan will not crawl to pages on internal-api.intruder.io. This can cause issues for some single-page applications which use multiple endpoints; a possible workaround would be adding an authentication to each domain/hostname that you wish to be scanned.

Can I provide a list of URLs to include from authenticated scanning?

No. Our Authenticated scans will crawl/spider pages within an application, and will follow any link it discovers. However, the scanner will only include URLs which are on the target to which Authentication is assigned. So, if you try and scan portal.intruder.io and the scanner identifies a link to internal-api.intruder.io it will not include that link, as it points to a different target. If both portal.intruder.io and internal-api.intruder.io have Authentication Licenses assigned to them, they will be scanned separately.

Can I provide a list of URLs to exclude from authenticated scanning?

At this point (v1.0) the scanner will only exclude the URL of the logout path that you specify within your authentication. All other URLs associated with the target that your Authentication is on will be included in the scan.

That said, your entrypoint URL determines where the scan starts. For example, https://vulnerablesite.intrude.es/login would mean that the scan starts at the login page, which would restrict the scanner from looking at the frontend. If that's what you want, then perfect, if not, it might make sense to set https://vulnerablesite.intrude.es/login as the login URL and https://vulnerablesite.intrude.es as the entrypoint.

Can I scan a subset of my application?

*Yes, you can specify an Entrypoint when you configure your Authentication.
If your Entrypoint includes a path such as http://portal.intruder.io/users/ then the scan will only include pages and directories under /users/.

Can I disable authentications so that they are not included in a scan?

Currently (v1.0) you cannot disable authentications. When you start a scan against a target with authentications assigned to it, all authentications will be included in the scan.


Minimising risk

Staging vs. Production

In short, the scanner can run safely on many production websites, but it's usually best to stick to staging to reduce the chance of damage.

Admin

We'd advise against adding admin credentials, as explained in this article.


SPAs

Can the scanner handle Single Page Applications (SPAs)?

The scanner can handle simple SPAs, but the more complex or abnormal the behaviour, the more likely it is that the coverage will be compromised.

To understand the correlation between complexity and coverage, it might help to understand how the scanner handles SPAs. It starts by fetching the application and running it within a headless browser; it then it manipulates the Document Object Model (DOM) and attempts to follow links it finds, recording a list of paths and parameters for further analysis as it goes. For more information, head to our SPA help article.

Can you handle JWT's (JSON Web Token)?

Yes, we do handle JWT's. To set this up, you'll will need to login to your application, record the JWT and then set the JWT as the authentication (usually this is as header-based authentication using the Authorisation: Bearer <token> header). We'll then receive authenticated responses from the backend API.

It's important that the token lasts slightly longer than it takes for the scan to complete. We typically recommend 24 hours, though we'd expect most scans to complete much sooner than this.

However, we do not currently (v1.0) support the configuration of Local Storage within our headless browser which means we may not be able to crawl SPAs which use Local Storage to present an authenticated page.


APIs

Can you scan an API?

Yes, but currently we don't allow users to upload a list of endpoints/paths or API schemas. As such, we can only identify endpoints/paths to scan based on what we discover in web applications. So, if your API supports a web application we will be able to scan it by crawling/spidering the web application. However, we cannot yet (v1.0) support full coverage of APIs.

If your OpenAPI/Swagger schema is accessible within the scope of the scan our scanner will parse the schema and use it to build a list of endpoints which will be included in testing – as long as those endpoints are within the scope of the scan.

Can you scan GraphQL endpoints?

Yes, but currently (v1.0) the same rules apply to those in the section above, your GraphQL definition must be reachable from the entrypoint specified within your Authentication configuration.


Configuring the scanner

Can I configure X for my authenticated web application scan?

Currently, configurations are limited to what is outlined in the AWAS user guide. If you don't see what you're looking for, it's always worth dropping our support team a message – understanding your motivations and expectations helps us build the tool that fulfils your needs.

Can I rate-limit the number of requests that are sent to my application?

Currently (v1.0) you cannot limit the number of requests per second that our scanner sends to your application.

Can I run concurrent authentication scans on the same target?

Whilst it is possible, we wouldn't necessarily recommend it. Instead, we'd recommend disabling all but one, so you're only scanning one authentication at a time.

To do this, head to your target's detail page:

Scroll down to 'Authentications', click ... and hit 'Disable':


Vulnerabilities

Can you detect out-of-band vulnerabilities?

Owing to a technical limitation (which we are working to resolve) we currently (v1.0) cannot detect out-of-band callbacks.


Results

How do I know if my scan authenticated correctly?

The best way to check would be to have a look through any logs on your servers. There isn't one standard response to look for (as it really depends on what you log) but hopefully one of the following will help:

  • If you log user authentication, then you could look for successful authentication for the user you added in the Authentication Configuration.

  • If you log the IP address instead of the user account for the authentication, then the IP address to look out for will be in the 203.12.218.0/24 range.

  • If you don't log successful authentications, but do log access to pages, then you could look at what pages are being accessed from IPs in the 203.12.218.0/24 range. If one of those pages is only accessible to authenticated users, then this can be used to determine that the authentication was a success.

Can I see which pages your scanner visited?

Yes! if you click on the relevant scan from the Scans Page, and click the "Scanned Authenticated URLs" tab, you can view a list of URLs that the Authenticated Web-App Scanner has been able to crawl.

  • If a URL only accessible behind a login page features on this list then this would indicate that the authentication has succeeded.

  • If this list only includes non-authenticated URLs (i.e. those not behind the login page), then it might be worth checking the authentication configuration and re-running a scan.

Did this answer your question?