XSS

This checklist is a guide for testing Cross-site Scripting (XSS) on a website

🔒 Reflected XSS

Definition and Examples:

The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

Suppose a website has a search function which receives the user-supplied search term in a URL parameter:

https://insecure-website.com/search?term=gift

The application echoes the supplied search term in the response to this URL: html

<p>You searched for: gift</p>

Assuming the application doesn't perform any other processing of the data, an attacker can construct an attack like this: html

https://insecure-website.com/search?term=<script>/*+Bad+stuff+here...+*/</script>

This URL results in the following response: html

<p>You searched for: <script>/* Bad stuff here... */</script></p>

If another user of the application requests the attacker's URL, then the script supplied by the attacker will execute in the victim user's browser, in the context of their session with the application.

How to Test

Detect Input Vectors

• For each web page, the tester must determine all the web application’s user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.

Analyze Input Vectors

• Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually. Some example of such input data are the following:

  <script>alert(123)</script>
  

  “><script>alert(document.cookie)</script>
  

Check Impact

• identifies any special characters that were not properly encoded, replaced, or filtered out

Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are:

• > (greater than)
• < (less than)
• & (ampersand)
• ' (apostrophe or single quote)
• " (double quote)

ithin the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include:

• \n (new line)
• \r (carriage return)
• ' (apostrophe or single quote)
• " (double quote)
• \ (backslash)
• \uXXXX (unicode values)

Payloads:

#️⃣	✅Items	⚠️Severity	☠️Vulnerabilities	🔗Sources
1	Verify: Multi-Factor authentication is enabled Reason: Password leak won't have any impact because the second factor is still not compromised	High	Impersonation, Credential Theft	GHD-UA
2	Verify: Enable PassKeys for a passwordless authentication experience Reason: Your device acts as an authenticator and will grant you access to your account. No need to remember passwords. Also satisfies MFA requirement	Medium	Credential Theft	GHD-UA
3	Verify: Periodically rotate SSH keys and Access Tokens Reason: If they leak, an attacker won't have permanent access to your account	Medium	Credential Theft	GHD-UA
4	Verify: Periodically review active sessions of devices logged in to your GitHub account Reason: To ensure that no unwanted device has access to your account	Medium	Impersonation	GHD-S