> For the complete documentation index, see [llms.txt](https://cajac.gitbook.io/ctf-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cajac.gitbook.io/ctf-notes/web/web-attacks/cross-site-scripting-xss.md). # Cross-Site Scripting (XSS) Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data. ### What can XSS be used for? An attacker who exploits a cross-site scripting vulnerability is typically able to: * Impersonate or masquerade as the victim user. * Carry out any action that the user is able to perform. * Read any data that the user is able to access. * Capture the user's login credentials. * Perform virtual defacement of the web site. * Inject trojan functionality into the web site. ## What are the types of XSS attacks? There are three main types of XSS attacks. These are: * [Reflected XSS](https://portswigger.net/web-security/cross-site-scripting#reflected-cross-site-scripting), where the malicious script comes from the current HTTP request. * [Stored XSS](https://portswigger.net/web-security/cross-site-scripting#stored-cross-site-scripting), where the malicious script comes from the website's database. * [DOM-based XSS](https://portswigger.net/web-security/cross-site-scripting#dom-based-cross-site-scripting), where the vulnerability exists in client-side code rather than server-side code. ## Find and test for XSS vulnerabilities Manually testing for **reflected** and **stored** XSS normally involves: * submitting some simple unique input (such as a short alphanumeric string) into every entry point in the application, * identifying every location where the submitted input is returned in HTTP responses, and * testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the [context](https://portswigger.net/web-security/cross-site-scripting/contexts) in which the XSS occurs and select a suitable payload to exploit it. Manually testing for **DOM-based** XSS arising from URL parameters involves a similar process: * placing some simple unique input in the parameter, * using the browser's developer tools to search the DOM for this input, and * testing each location to determine whether it is exploitable. However, other types of DOM XSS are harder to detect. To find DOM-based vulnerabilities in non-URL-based input (such as `document.cookie`) or non-HTML-based sinks (like `setTimeout`), there is no substitute for reviewing JavaScript code, which can be extremely time-consuming. ### Example payloads ```html

``` ```html

``` ```html ``` ```html "> ``` ```html "> ``` ```html ``` ```html

``` ### Polyglots ```javascript jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */onerror=alert('THM') )//%0D%0A%0d%0a//\x3csVg/