Cross-Site Scripting - DOM-XSS
General DOM XSS Report Requirements
Payloads should show access to the DOM when possible using document.domain or similar.
Screenshots should include successful XSS execution.
HTTP requests where payloads are sent are required.
If authentication is required, please include credentials in your first step.
The vulnerable client-side code must be included. SRT should make the best effort to show where the flaw resides in the code.
Please see the this article for more information regarding DOM-XSS
Template Contents
Title
DOM Based XSS on [SITE]
Description
Cross-Site Scripting (XSS) attacks involve the execution of untrusted user input in the context of an application. Unique from most other variants, generally, the issue here lies with client side code rather than the server reflecting any untrusted input in an unsafe manner. The following report will describe the DOM-XSS findings.
Vulnerable Code:
INSERT VULNERABLE CLIENT SIDE CODE HEREImpact
XSS results in unauthorized code being executed/rendered by a user's browser. As a result the following may occur:
Cookies can be stolen, leading to account takeover
Untrusted code can modify the DOM environment and retrieve/modify various values
Malicious execution of input can lead to a variety of other impacts
Recommended Fix
Tips from OWASP:
Untrusted data should only be treated as displayable text
Always JavaScript encode and delimit untrusted data as quoted strings entering the application when building templated JavaScript
Use document.createElement("..."), element.setAttribute("...","value"), element.appendChild(...) and similar to build dynamic interfaces
Avoid sending untrusted data into HTML rendering methods
Avoid the numerous methods which implicitly eval() data passed to it
For more detailed information on these tips, visit the OWASP XSS Prevention cheat sheet HERE.
Last updated