XSS

Impact: Bypasses Same-Origin policy that protects should the interactions a user has with different sites. By visiting the vulnerable application, attacker can perform actions on users behalf like interacting with other domains that bypasses the SOP. Allows attacker to impersonate the victim user and make actions on their behalf. As the JS code being presented, will have access to the DOM and cookies of the vulnerable site domain (here SOP is impacted), allowing for the same. This is in other words, means complete control over the application.

How: XSS allows attackers to present arbitrary JavaScript to users' browser (session), that gets executed as any intended JavaScript code by the browser. This is with full control over the application.

XSS POC: When looking for XSS, we verify that we can run arbitrary JS, by testing a XSS payload. Usually alert() payload is sent, if xss exists alert() gets inserted as JS and a popup is triggered on the victims browser. Offlate, alert() does not work in all cases a XSS vulnerability exists, like in the case of cross-origin iframes are prevented in latest versions of chrome (92 onwards). In such cases, other advanced methods or print() method can be used.

Types of XSS attacks:

1. Reflected XSS: malicious script comes from current HTTP request (e.g data from a get parameter that gets reflect onto the return page)

2. Stored XSS: malicious script comes from websites' database ( e.g script passed into user name, gets stored as username, on welcome page script gets triggered)

3. DOM- based XSS : vulnerability in clident-side code. ( client side JS takes in user data and passes them into a javascipt without any filtering, this allows to input malicious javascript code instead of what data developers intended to be passes, the same is then executed).

1. Reflected XSS:

Data received by an application in HTTP request gets unsafely included in the response. This allows attacker to send script that gets returned by the application, triggering the same. The users session with the application is compromised as the malicious script will have access to its components. This may include retrieving sensitive CSRF like data from other pages on the application,etc.

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

Here the data in message parameter gets reflected in the <p> tag after "Status :"

As the data is inserted into "<p>", this won't be executing any JS, so "<Script>" tag would need to be included, as only then our code will be considered as JS and executed. However in somecases our parameter could be inserted into the returned client-side script also, so keep an eye out for that.

Attacker can be prevented from inserting <script> tags, but this is not properly filtered and the malicious script can be inserted into the returned html page.

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>

On visiting this response, our script will be executed.

2. Stored XSS (persistent, second-order XSS):

When application received data from untrusted source and includes it later in HTTP response in an unsafe manner. This could be displaying data received from a third party, for instance displaying data received from a social media platform posts, webmail displaying email data from SMTP, network monitoring app displaying packet data from network traffic. The data's origin is considered stored as it is not instantaneously passed to the app when http request is sent, on the contrary is fetched from a database, that has it stored somewhere.

Example: Message from board to employees is displayed as:

<p>Hello, this is my message!</p>

If attacker can modify the message to contain malicious script, it will be inserted into <p> tags, allowing for execution as below:

<p><script>/* Bad stuff here... */</script></p>

3. DOM-based XSS:

When client-side JavaScript processes data from untrusted sources in an unsafe manner, ususally writing it back to the DOM.

Consider the following example:

<h1 id="search"><img src=1 onerror='/* Bad stuff here... */'></h1>
<h2>The getElementById() Method</h2>
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

Here the search element is defined by the "search" id value, that gets taken from the DOM (html document), and is inserted into the "results" element of the DOM.

The following string is inserted to the results id on the DOM, and triggers JavaScript code or our malicious payload.

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

The example above takes "search" element, and inserts into DOM, but where is the entrypoint for this attack. It depends on from where the "search" element gets defined. If is from user query string parameter submitted by the user in a HTTP request, then it becomes relected-DOM-based XSS. If search is defined from somewhere is was previously stored, the is rendered a stored-DOM-based XSS.

XSS uses: It allows attacker to load arbitrary Javascript onto the clients session. Any priviledges JS enjoyes, XSS allows to achieve, namely:

• 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.

Namely impacts:

• In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.

• In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.

• If the compromised user has elevated privileges within the application, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

Detection Flow:

1. Submit inputs (look for parameter requests).

2. Identify locations where these inputs are returned in HTTP responses.

3. Test each location to determine whether it is exploitable (that filtering can be bypasses, script execuable for that loacation0.

4. For Dom-XSS review JavaScript code, for non-URL-based input or non-HTML-based sinks exploitation.

XSS based on target functionality:

1. Content Security Policy: Restricts loading of resources and if page can be framed.

2. Dangling marku injection: Capture sensitive information visible to user. If full XSS not possible due to filters/defenses, used to capture data cross-domain.

Prevention:

• Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input. (e.g filter <> tags, so no <script> tags can be reflected in response).

• Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.(Even if input <script> is unfiltered, it wont' be rendered in such a way that it is executed).

• Use appropriate response headers. To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend. (Through this the response will be treated executable a JavaScript code, hence, won't be considered as one by the browser)

• Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur. (Protects potential endpoints that will be tragetted by the XSS payload)