DOM-based vulnerabilities arise 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.

DOM-based cross-site scripting arises when a script writes controllable data into the HTML document in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Users can be induced to visit the attacker's crafted URL in various ways, similar to the usual attack delivery vectors for reflected cross-site scripting vulnerabilities.

Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.

The most effective way to avoid DOM-based cross-site scripting vulnerabilities is not to dynamically write data from any untrusted source into the HTML document. If the desired functionality of the application means that this behavior is unavoidable, then defenses must be implemented within the client-side code to prevent malicious data from introducing script code into the document. In many cases, the relevant data can be validated on a whitelist basis, to allow only content that is known to be safe. In other cases, it will be necessary to sanitize or encode the data. This can be a complex task, and depending on the context that the data is to be inserted may need to involve a combination of JavaScript escaping, HTML encoding, and URL encoding, in the appropriate sequence.

• Cross-site scripting
• DOM-based cross-site scripting

• CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
• CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
• CWE-116: Improper Encoding or Escaping of Output
• CWE-159: Failure to Sanitize Special Element

• /DVWA/vulnerabilities/brute/
• /DVWA/vulnerabilities/captcha/
• /DVWA/vulnerabilities/csrf/

Some applications transmit passwords over unencrypted connections, making them vulnerable to interception. To exploit this vulnerability, an attacker must be suitably positioned to eavesdrop on the victim's network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection such as public Wi-Fi, or a corporate or home network that is shared with a compromised computer. Common defenses such as switched networks are not sufficient to prevent this. An attacker situated in the user's ISP or the application's hosting infrastructure could also perform this attack. Note that an advanced adversary could potentially target any connection made over the Internet's core infrastructure.

Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.

Applications should use transport-level encryption (SSL or TLS) to protect all sensitive communications passing between the client and the server. Communications that should be protected include the login mechanism and related functionality, and any functions where sensitive data can be accessed or privileged actions can be performed. These areas should employ their own session handling mechanism, and the session tokens used should never be transmitted over unencrypted communications. If HTTP cookies are used for transmitting session tokens, then the secure flag should be set to prevent transmission over clear-text HTTP.

• CWE-319: Cleartext Transmission of Sensitive Information

• http://192.168.0.34/DVWA/vulnerabilities/brute/

• password

• http://192.168.0.34/DVWA/vulnerabilities/captcha/

• password_current
• password_new
• password_conf

• http://192.168.0.34/DVWA/vulnerabilities/csrf/

• password_current
• password_new
• password_conf

• /DVWA/vulnerabilities/brute/
• /DVWA/vulnerabilities/csrf/

Some applications use the GET method to submit passwords, which are transmitted within the query string of the requested URL. Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing passwords into the URL increases the risk that they will be captured by an attacker.

Vulnerabilities that result in the disclosure of users' passwords can result in compromises that are extremely difficult to investigate due to obscured audit trails. Even if the application itself only handles non-sensitive information, exposing passwords puts users who have re-used their password elsewhere at risk.

All forms submitting passwords should use the POST method. To achieve this, applications should specify the method attribute of the FORM tag as method="POST". It may also be necessary to modify the corresponding server-side form handler to ensure that submitted passwords are properly retrieved from the message body, rather than the URL.

• CWE-598: Information Exposure Through Query Strings in GET Request

• http://192.168.0.34/DVWA/vulnerabilities/brute/

• password

• http://192.168.0.34/DVWA/vulnerabilities/csrf/

• password_current
• password_new
• password_conf

• /DVWA/vulnerabilities/brute/
• /DVWA/vulnerabilities/captcha/
• /DVWA/vulnerabilities/csp/
• /DVWA/vulnerabilities/csrf/
• /DVWA/vulnerabilities/exec/
• /DVWA/vulnerabilities/fi/
• /DVWA/vulnerabilities/javascript/
• /DVWA/vulnerabilities/sqli/
• /DVWA/vulnerabilities/sqli_blind/
• /DVWA/vulnerabilities/upload/
• /DVWA/vulnerabilities/weak_id/
• /DVWA/vulnerabilities/xss_d/
• /DVWA/vulnerabilities/xss_r/
• /DVWA/vulnerabilities/xss_s/

Path-relative style sheet import vulnerabilities arise when the following conditions hold:

1. A response contains a style sheet import that uses a path-relative URL (for example, the page at "/original-path/file.php" might import "styles/main.css").
2. When handling requests, the application or platform tolerates superfluous path-like data following the original filename in the URL (for example, "/original-path/file.php/extra-junk/"). When superfluous data is added to the original URL, the application's response still contains a path-relative stylesheet import.
3. The response in condition 2 can be made to render in a browser's quirks mode, either because it has a missing or old doctype directive, or because it allows itself to be framed by a page under an attacker's control.
4. When a browser requests the style sheet that is imported in the response from the modified URL (using the URL "/original-path/file.php/extra-junk/styles/main.css"), the application returns something other than the CSS response that was supposed to be imported. Given the behavior described in condition 2, this will typically be the same response that was originally returned in condition 1.
5. An attacker has a means of manipulating some text within the response in condition 4, for example because the application stores and displays some past input, or echoes some text within the current URL.

Given the above conditions, an attacker can execute CSS injection within the browser of the target user. The attacker can construct a URL that causes the victim's browser to import as CSS a different URL than normal, containing text that the attacker can manipulate.

Being able to inject arbitrary CSS into the victim's browser may enable various attacks, including:

• Executing arbitrary JavaScript using IE's expression() function.
• Using CSS selectors to read parts of the HTML source, which may include sensitive data such as anti-CSRF tokens.
• Capturing any sensitive data within the URL query string by making a further style sheet import to a URL on the attacker's domain, and monitoring the incoming Referer header.

The root cause of the vulnerability can be resolved by not using path-relative URLs in style sheet imports. Aside from this, attacks can also be prevented by implementing all of the following defensive measures:

• Setting the HTTP response header "X-Frame-Options: deny" in all responses. One method that an attacker can use to make a page render in quirks mode is to frame it within their own page that is rendered in quirks mode. Setting this header prevents the page from being framed.
• Setting a modern doctype (e.g. "<!doctype html>") in all HTML responses. This prevents the page from being rendered in quirks mode (unless it is being framed, as described above).
• Setting the HTTP response header "X-Content-Type-Options: nosniff" in all responses. This prevents the browser from processing a non-CSS response as CSS, even if another page loads the response via a style sheet import.

• Detecting and exploiting path-relative stylesheet import (PRSSI) vulnerabilities

• CWE-16: Configuration

• http://192.168.0.34/DVWA/vulnerabilities/fi/

• https://en.wikipedia.org/wiki/Remote_File_Inclusion
• https://www.owasp.org/index.php/Top_10_2007-A3

When a web browser makes a request for a resource, it typically adds an HTTP header, called the "Referer" header, indicating the URL of the resource from which the request originated. This occurs in numerous situations, for example when a web page loads an image or script, or when a user clicks on a link or submits a form.

If the resource being requested resides on a different domain, then the Referer header is still generally included in the cross-domain request. If the originating URL contains any sensitive information within its query string, such as a session token, then this information will be transmitted to the other domain. If the other domain is not fully trusted by the application, then this may lead to a security compromise.

You should review the contents of the information being transmitted to other domains, and also determine whether those domains are fully trusted by the originating application.

Today's browsers may withhold the Referer header in some situations (for example, when loading a non-HTTPS resource from a page that was loaded over HTTPS, or when a Refresh directive is issued), but this behavior should not be relied upon to protect the originating URL from disclosure.

Note also that if users can author content within the application then an attacker may be able to inject links referring to a domain they control in order to capture data from URLs used within the application.

Applications should never transmit any sensitive information within the URL query string. In addition to being leaked in the Referer header, such information may be logged in various locations and may be visible on-screen to untrusted parties. If placing sensitive information in the URL is unavoidable, consider using the Referer-Policy HTTP header to reduce the chance of it being disclosed to third parties.

• Referer Policy

• CWE-200: Information Exposure

• https://www.google.com/recaptcha/api.js

When an application includes a script from an external domain, this script is executed by the browser within the security context of the invoking application. The script can therefore do anything that the application's own scripts can do, such as accessing application data and performing actions within the context of the current user.

If you include a script from an external domain, then you are trusting that domain with the data and functionality of your application, and you are trusting the domain's own security to prevent an attacker from modifying the script to perform malicious actions within your application.

Scripts should ideally not be included from untrusted domains. Applications that rely on static third-party scripts should consider using Subresource Integrity to make browsers verify them, or copying the contents of these scripts onto their own domain and including them from there. If that is not possible (e.g. for licensing reasons) then consider reimplementing the script's functionality within application code.

• Subresource Integrity

• CWE-829: Inclusion of Functionality from Untrusted Control Sphere

• http://192.168.0.34/DVWA/vulnerabilities/upload/

File upload functionality is commonly associated with a number of vulnerabilities, including:

• File path traversal
• Persistent cross-site scripting
• Placing of other client-executable code into the domain
• Transmission of viruses and other malware
• Denial of service

You should review file upload functionality to understand its purpose, and establish whether uploaded content is ever returned to other application users, either through their normal usage of the application or by being fed a specific link by an attacker.

Some factors to consider when evaluating the security impact of this functionality include:

• Whether uploaded content can subsequently be downloaded via a URL within the application.
• What Content-type and Content-disposition headers the application returns when the file's content is downloaded.
• Whether it is possible to place executable HTML/JavaScript into the file, which executes when the file's contents are viewed.
• Whether the application performs any filtering on the file extension or MIME type of the uploaded file.
• Whether it is possible to construct a hybrid file containing both executable and non-executable content, to bypass any content filters - for example, a file containing both a GIF image and a Java archive (known as a GIFAR file).
• What location is used to store uploaded content, and whether it is possible to supply a crafted filename to escape from this location.
• Whether archive formats such as ZIP are unpacked by the application.
• How the application handles attempts to upload very large files, or decompression bomb files.

File upload functionality is not straightforward to implement securely. Some recommendations to consider in the design of this functionality include:

• Use a server-generated filename if storing uploaded files on disk.
• Inspect the content of uploaded files, and enforce a whitelist of accepted, non-executable content types. Additionally, enforce a blacklist of common executable formats, to hinder hybrid file attacks.
• Enforce a whitelist of accepted, non-executable file extensions.
• If uploaded files are downloaded by users, supply an accurate non-generic Content-Type header, the X-Content-Type-Options: nosniff header, and also a Content-Disposition header that specifies that browsers should handle the file as an attachment.
• Enforce a size limit on uploaded files (for defense-in-depth, this can be implemented both within application code and in the web server's configuration).
• Reject attempts to upload archive formats such as ZIP.

• Various proof-of-concept files
• An XSS polyglot attack

• CWE-434: Unrestricted Upload of File with Dangerous Type

• /DVWA/vulnerabilities/brute/
• /DVWA/vulnerabilities/captcha/
• /DVWA/vulnerabilities/csrf/
• /DVWA/vulnerabilities/exec/
• /DVWA/vulnerabilities/fi/
• /DVWA/vulnerabilities/sqli/
• /DVWA/vulnerabilities/sqli_blind/
• /DVWA/vulnerabilities/upload/

If a page fails to set an appropriate X-Frame-Options or Content-Security-Policy HTTP header, it might be possible for a page controlled by an attacker to load it within an iframe. This may enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.

Note that some applications attempt to prevent these attacks from within the HTML page itself, using "framebusting" code. However, this type of defense is normally ineffective and can usually be circumvented by a skilled attacker.

You should determine whether any functions accessible within frameable pages can be used by application users to perform any sensitive actions within the application.

To effectively prevent framing attacks, the application should return a response header with the name X-Frame-Options and the value DENY to prevent framing altogether, or the value SAMEORIGIN to allow framing only by pages on the same origin as the response itself. Note that the SAMEORIGIN header can be partially bypassed if the application itself can be made to frame untrusted websites.

• X-Frame-Options

• CWE-693: Protection Mechanism Failure