Scan checks

Cross-site scripting (XSS) allows an attacker to execute arbitrary JavaScript in a victim's browser. This potentially allows the attacker to carry out any actions that their victim is able to perform, and to access their data. XSS is extremely common in the wild - in 2020 it accounted for more bug bounties than any other security vulnerability.

XSS is a potentially critical security vulnerability, often resulting from insufficient sanitization of user-controllable data in a web application. You may be familiar with one traditional method of testing for XSS that involves executing alert() in the browser. Note that alert() serves merely as a proof of concept for JavaScript execution. The actual consequences of XSS can be much more severe - potentially allowing an attacker to access users' personal information (e.g. card details), or to take over their account by stealing cookies.

More information / further reading

Dastardly dynamically scans your application for reflected XSS. Other varieties of XSS that you should be aware of include stored XSS and DOM-based XSS.

• Learn more about XSS in the Web Security Academy.
• See a technical description of reflected XSS.
• See a technical description of stored XSS.
• See a technical description of DOM-based XSS.

HTML5 cross-origin resource sharing (CORS) is a browser mechanism that enables controlled access to resources located outside of a given domain. CORS is a powerful technology, which is easy to configure wrong - and high severity exploits are often relatively easy for an attacker to find.

CORS checks performed by Dastardly

CORS enabled

It's easy to unintentionally enable CORS when building a web application. Some libraries turn CORS on by default, for instance. Or you might wish to have CORS enabled for an API, but accidentally enable it for your whole application.

Dastardly dynamically checks whether CORS is enabled in your application - and notifies you if it is. This serves as a reminder to check your CORS implementation, and to remove any unnecessary domains (e.g. test domains) from your CORS policy before deployment.

CORS: arbitrary origin trusted

If an application is set to trust arbitrary domains (as opposed to using an allow list / "whitelist"), then this effectively disables CORS - granting two-way interaction to any website that requests it. Unless the application's response contains solely unprotected public content, such a policy is likely to constitute a security risk. Despite this, during development, applications are sometimes set to trust arbitrary origins - often for purposes of convenience.

It's imperative to check that an application's CORS implementation is only set to trust arbitrary origins when this is truly necessary. If your application uses CORS, Dastardly dynamically checks to see if it trusts arbitrary domains, and will warn you in your CI/CD pipeline if this configuration is detected.

CORS: all subdomains trusted

If an application's CORS policy is set to allow two-way interaction with all subdomains, then this can significantly increase that application's susceptibility to attack. For example, a cross-site scripting (XSS) vulnerability in any present or future subdomain could potentially compromise the application. This could pose a huge security risk.

Rather than trust all subdomains, it is generally better to include an allow list / "whitelist" of trusted subdomains in an application's CORS implementation. If your application uses CORS, Dastardly dynamically checks to see if it trusts all subdomains, and will warn you in your CI/CD pipeline if this configuration is detected.

More information / further reading

Note that Dastardly does not check your application for a CORS implementation where unencrypted origins are trusted. Full versions of Burp Suite will dynamically check your application for this issue.

• Learn more about CORS in the Web Security Academy.
• See a technical description of CORS.
• See a technical description of CORS: arbitrary origin trusted.
• See a technical description of CORS: all subdomains trusted.
• See a technical description of CORS: unencrypted origin trusted.
• Take a deep dive into CORS vulnerabilities with PortSwigger Research.

It's very popular to use third-party JavaScript libraries and frameworks in modern web development. While they bring power and convenience, if these dependencies are not kept up to date then they can also introduce security vulnerabilities. This is doubly problematic, given that any such vulnerabilities are likely to become common knowledge among attackers.

The cause and impact of a vulnerable JavaScript dependency could range from low to critical, depending on what you are using the dependency for, and what the vulnerability actually entails. Suffice to say that it's a good idea to keep on top of security updates.

Dastardly dynamically cross-checks your front-end JavaScript dependencies against a repository of libraries and frameworks that have known security issues. If it finds anything that needs updating, you'll be notified right in your CI/CD pipeline.

More information / further reading

• See a technical description of vulnerable JavaScript dependency issues.

An HTTP response containing a message body should include a Content-type header correctly and unambiguously stating the MIME type of the content being sent in its body. This enables the receiving browser to process the response in the intended manner.

If an HTTP response does not specify a MIME type, then the receiving browser will usually analyze the response in an attempt to determine what the actual MIME type is. This can have unexpected results. If the content of the response body contains user-controllable input, then this can also lead to cross-site scripting (XSS), or other client-side vulnerabilities.

Dastardly dynamically checks that HTTP responses sent by your application correctly specify a content type for their body. If it finds anywhere where this is not the case, then you will be notified in your CI/CD pipeline. Note that Dastardly also checks your application for reflected XSS.

More information / further reading

• See a technical description of the risks associated with not specifying a content type for an HTTP response.

An HTTP response containing a message body should include a Content-type header correctly describing the MIME type of the content being sent in its body. This enables the receiving browser to process the response in the intended manner.

If an HTTP response specifies multiple incompatible MIME types, then the receiving browser will usually analyze the response in an attempt to determine what the actual MIME type is. This can have unexpected results. If the content of the response body contains user-controllable input, then this can also lead to cross-site scripting (XSS), or other client-side vulnerabilities.

Dastardly dynamically checks that HTTP responses sent by your application correctly specify a content type for their body. If it finds anywhere where this is not the case, then you will be notified in your CI/CD pipeline. Note that Dastardly also checks your application for reflected XSS.

More information / further reading

• See a technical description of the risks associated with specifying multiple content types for an HTTP response.

If an HTTP response states that it includes HTML content in its body, but does not specify a character set, then the receiving browser may analyze the content and attempt to determine which character set it is using. This can have unexpected results.

Most notably, failure to specify a character set in this way can lead to cross-site scripting (XSS) vulnerabilities. Here non-standard encodings (such as UTF-7) can be used to bypass any defensive filters employed by the application.

When a HTTP response sent by your application states that it contains HTML, Dastardly dynamically checks that it specifies a character set. If this is not the case, then you will be notified in your CI/CD pipeline. Note that Dastardly also checks your application for reflected XSS.

More information / further reading

• See a technical description of the risks associated with not specifying a charset for responses containing HTML.

Web applications often include misconfigurations while in development. One common problem is that a response sent by an application unintentionally includes duplicate cookies (e.g. by using multiple Set-Cookie headers). This could creep in by oversight, or because it happened to be convenient at the time of development - but it's important to remediate the problem before your application hits production.

While duplicate cookies alone don't indicate a security vulnerability, this misconfiguration can easily lead to the sort of undefined behavior that attackers look for. The presence of this issue could give a nefarious actor the foothold they need in order to confuse a browser and escalate to a more serious situation.

Dastardly dynamically checks for duplicate cookies in the responses sent by your application. If it finds this, you'll be notified right in your CI/CD pipeline.

More information / further reading

• See a technical description of the duplicate cookie issue.

SQL injection (SQLi) vulnerabilities allow an attacker to insert data into a SQL query to break out of its intended context. This can cause unexpected behavior. In many cases, this could involve an attacker extracting the entire database from an application - including any sensitive data it contains (user data, encrypted passwords, etc.).

To avoid SQLi, caution should be exercised whenever user-controllable data is used as part of a database SQL query. Notably, an application should ensure that tainted data cannot lead to unexpected behavior. The most effective way to do this is to use parameterized queries (prepared statements) for all database access.

Dastardly does not check your application for SQLi. Full versions of Burp Suite can be used to dynamically check for SQLi, and over 160 other issues - using the same groundbreaking crawl engine as Dastardly. Burp Suite will also check for issues such as blind SQLi, by using automated OAST techniques that were first pioneered by its scanner.

More information / further reading

• Learn more about SQLi in the Web Security Academy.
• See a technical description of SQLi.

DOM-based cross-site scripting (DOM-based XSS) arises when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way.

As with other types of XSS (see: reflected XSS, stored XSS), DOM-based XSS allows an attacker to execute arbitrary JavaScript in a victim's browser. This can have serious consequences - potentially allowing an attacker to access users' personal information (e.g. card details), or to take over their account by stealing cookies.

Dastardly does not check your application for DOM-based XSS. Full versions of Burp Suite can be used to dynamically check for DOM-based XSS, and over 160 other issues - using the same groundbreaking crawl engine as Dastardly. Note that Dastardly does check your application for reflected XSS.

More information / further reading

• Learn more about XSS in the Web Security Academy.
• See a technical description of DOM-based XSS.
• See a technical description of reflected XSS.
• See a technical description of stored XSS.

JavaScript objects can inherit features from one another through the prototype chain. Client-side prototype pollution enables an attacker to add arbitrary properties to global prototypes that are then inherited by user-defined objects.

If an application vulnerable to prototype pollution subsequently handles an attacker-controlled property in an unsafe way, then this can potentially be chained with other vulnerabilities - most commonly DOM-based XSS. This can allow an attacker to execute arbitrary JavaScript in a victim's browser - enabling them to access personal information like card details, or to steal cookies (potentially leading to account takeover).

Dastardly does not check your application for client-side prototype pollution. Full versions of Burp Suite can be used to dynamically check for client-side prototype pollution, and over 160 other issues - using the same groundbreaking crawl engine as Dastardly.

More information / further reading

• Learn more about DOM-based XSS in the Web Security Academy.
• See a technical description of client-side prototype pollution.
• See a technical description of DOM-based XSS.
• Learn how to find client-side prototype pollution using Burp Suite, with PortSwigger Research.

HTTP request smuggling is a vulnerability that takes advantage of inconsistencies in the way different web servers parse HTTP. When a website routes HTTP requests through such inconsistent web servers, request smuggling can arise.

The impact of request smuggling is often critical. It can allow attackers to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other website users. HTTP request smuggling was pioneered by the makers of Dastardly.

Static methods of application security testing cannot accurately test for request smuggling vulnerabilities. It is therefore crucial that testing for request smuggling is carried out on an application once in a deployed state, and / or in a replica staging environment prior to deployment, using dynamic testing methods.

Dastardly does not check your website for request smuggling vulnerabilities. Full versions of Burp Suite can be used to dynamically check for request smuggling, and over 160 other issues - using the same groundbreaking crawl engine as Dastardly.

More information / further reading

• Learn more about HTTP request smuggling in the Web Security Academy.
• See a technical description of HTTP request smuggling.
• Learn how HTTP request smuggling was pioneered by the makers of Dastardly.

Dastardly scans your web application for seven security issues of particular relevance to web developers. It's an actionable and effective starting point for building more secure applications from the beginning - greatly cutting down on rework. Based on the groundbreaking Burp Scanner, it can dynamically navigate even complex modern web applications.

To further tighten web application security, full versions of Burp Suite include the full version of Burp Scanner - capable of dynamically checking your application for over 160 total security issues. This includes issues such as those mentioned above - SQL injection, DOM-based cross-site scripting (XSS), and HTTP request smuggling.

More information / further reading

• Learn more about the full range of issues that Burp Scanner can check for.