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 HERE

---

Impact

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.

---