> For the complete documentation index, see [llms.txt](https://zeyad-abulaban.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zeyad-abulaban.gitbook.io/notes/web-penetration-testing/web-vulns/xss.md).
# Cross Site Scripting
## DOM-Based XSS
Attacks involve manipulating a website’s **existing JavaScript code** to **execute malicious JavaScript**; it can be either **stored** or **reflected**.
* [**jQuery**](#jquery)
* [**AngularJS**](#angularjs)
* [**Eval**](#eval)
* [**Sinks that can lead to DOM-XSS**](#sinks-that-can-lead-to-dom-xss)
To test for DOM XSS in an HTML sink, place a random alphanumeric string into the source (such as `location.search`), then use developer tools to inspect the HTML and find where your string appears. Note that the browser's "View source" option won't work for DOM XSS testing because it doesn't take account of changes that have been performed in the HTML by JavaScript.
* Note that browsers behave differently with regards to URL-encoding, Chrome, Firefox, and Safari will URL-encode `location.search` and `location.hash`, while \*\*IE11 \*\*and **Microsoft Edge (pre-Chromium)** will not URL-encode these sources. If your data gets URL-encoded before being processed, then an XSS attack is unlikely to work.
### jQuery
If a JavaScript library such as jQuery is being used, look out for sinks that can alter DOM elements on the page. For instance, the `attr()` function in jQuery can change attributes on DOM elements. If data is read from a user-controlled source like the URL and then passed to the `attr()` function, then it may be possible to manipulate the value sent to cause XSS. For example, here we have some JavaScript that changes an anchor element's `href` attribute using data from the URL.
```js
$(function(){
$('#backLink').attr("href",(new URLSearchParams(window.location.search)).get('returnUrl'));
});
```
You can exploit this by modifying the URL so that the `location.search` source contains a malicious JavaScript URL. After the page's JavaScript applies this malicious URL to the back link's `href`, clicking on the back link will execute it:
```js
?returnUrl=javascript:alert(document.domain)
```
### AngularJS
If a framework like [**AngularJS**](https://portswigger.net/web-security/cross-site-scripting/contexts/angularjs-sandbox) is used, it may be possible to execute JavaScript without angle brackets or events. When a site uses the `ng-app` attribute on an HTML element, it will be processed by AngularJS. In this case, AngularJS will execute JavaScript inside double curly braces that can occur directly in HTML or inside attributes.
* Example Payload: `{{$on.constructor('alert(1)')()}}`
> **More** [**Payloads**](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/XSS%20in%20Angular.md)
### Eval
Sources aren't limited to data that is directly exposed by browsers - they can also originate from the website. For example, websites often reflect URL parameters in the HTML response from the server. This is commonly associated with normal XSS, but it can also lead to so-called reflected+DOM vulnerabilities.
In a reflected+DOM vulnerability, the server processes data from the request, and echoes the data into the response. The reflected data might be placed into a JavaScript string literal, or a data item within the DOM, such as a form field. A script on the page then processes the reflected data in an unsafe way, ultimately writing it to a dangerous sink.
`eval('var data = "reflected string"');`
* You can always use **arithmetic operators** to separate the expressions when escaping them for example:
```json
\"-alert(1)}//
#This is used to bypass the following JSON query. (btw the Double quotes was being escaped)
`{"searchTerm":"hello", "results":[1,2,3]}`
```
## Sinks that can lead to DOM-XSS
document.write()\
document.writeln()\
document.domain\
element.innerHTML\
element.outerHTML\
element.insertAdjacentHTML\
element.onevent
**The following jQuery functions are also sinks that can lead to DOM-XSS vulnerabilities:**
add()\
after()\
append()\
animate()\
insertAfter()\
insertBefore()\
before()\
html()\
prepend()\
replaceAll()\
replaceWith()\
wrap()\
wrapInner()\
wrapAll()\
has()\
constructor()\
init()\
index()\
jQuery.parseHTML()\
$.parseHTML()
-------------
## Stored XSS
### Input Forms
* **User/Profiles page**: the application allows the user to edit/change profile details such as first name, last name, nickname, avatar, picture, address, etc.
* **Shopping cart**: the application allows the user to store items into the shopping cart which can then be reviewed later
* **File Manager**: application that allows upload of files
* **Application settings/preferences**: application that allows the user to set preferences
* **Forum/Message board**: application that permits exchange of posts among users
* **Blog**: if the blog application permits to users submitting comments
* **Log**: if the application stores some users input into logs
### Steal Passwords from Password-Managers payload
```js
```
### Steal CSRF token then do a POST request
```js
```
> NOTE: Internet Explorer handles TXT files with HTML content as HTML content
***
## Content Security Policy
* CSP is a browser security mechanism that aims to mitigate XSS and some other attacks. It works by restricting the resources (such as scripts and images) that a page can load and restricting whether a page can be framed by other pages.
* To enable CSP, a response needs to include an HTTP response header called `Content-Security-Policy` with a value containing the policy. The policy itself consists of one or more directives, separated by semicolons.
***
## Dangling markup injection
Dangling markup injection is a technique for capturing data cross-domain in situations where a full cross-site scripting attack isn't possible. Suppose an application embeds attacker-controllable data into its responses in an unsafe way: `