XSS (Cross-Site Scripting) - Overview and Contexts

[Former Member]

XSS - Cross-Site Scripting is no more new in the world of IT Security in fact one of the most popular and common vulnerabilities. There are many blogs, clean sheets, security tips/tricks, advices and other resources available in the web. This blog is a share of my learning which I am currently doing for the last few months with my colleague and friend Dr. Ashar Javed ( A well known Security Researcher, Speaker of Black Hat, DeepSec, OWASP.... an XSSer .. an Ethical Hacker). Well to be frank I am not all from security background (SAP Consultant/Developer) but my learning make me much aware over security now and I can also say that I am also responsible for security. Let's begin..

I believe we heard the definition of  XSS, at least in this SCN Space, we have seen some common definitions from the web:

as per Wikipedia "XSS enables attackers to inject client-side script into web pages viewed by other users".

as per  OWASP (the free and open software security community) "Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites."

There are many more, one such is candidate definition and for me it is the Developer's Definition: "An XSS attack occurs when a script from an untrusted source is executed in rendering a page"  These questions come  to our mind when we follow this definition and are quite valid.

• Script. JavaScript, any web-enabled script language, or any character sequence that sort of executes in the browser?
• Untrusted. What does trusting and not trusting a script mean? Who expresses this trust or distrust?
• Source. Is it a domain, a server, a legal entity such as Google, or the attacker multiple steps away in the request chain?
• Executed. Relates to "Script" above. Does it mean running on the JavaScript engine, invoke a browser event, invoke an http request, or what?
• Rendering. Does rendering have to happen for an attack to be categorized as XSS?
• Page. Is a page a prerequisite for XSS? Can XSS happen without a page existing?

Rendering also involves communicating to Server specially when there is input option in client side.

So what is XSS or more precisely what can an Attacker do with XSS? Let me show you a basic diagram on this, may be too much "basic" for you but it's the truth.

XSS is nothing but a security bug that can affect web applications. It can allow an attacker to add their own malicious code (through JavaScript, VBScript, Flash, HTML, JSON, ActiveX etc.) onto the HTML pages displayed to your users. And once executed by the victim's browser, this code could then perform actions such as completely changing the behaviour or appearance of the application, stealing private data, execute commands/malicious scripts or performing actions on behalf of the user.

Ex. Attacker steal the session cookie of the Admin and login as admin and can change everything. Others typical possibilities are port scanning, phishing, keylogging etc. And it become more dangerous when its get saved to the Databases as it shown in the diagram, also known as Stored XSS or Persistent XSS which requires server side interpretation of the query and data storing.

But why XSS? There are also other vulnerabilities. Le's see some facts

According to latest White-hat Security report, 47% of web applications have XSS vulnerability:

According to Google Vulnerability Reward Program's Statistics, XSS is the most reported issue:

According to "Open Sourced Vulnerability Database"  XSS is at #1:

Believe me there are lot of these facts which state XSS is currently the popular one.

And its is clear now a days that XSS vulnerabilities most often happen when user input is incorporated into a web server's response (i.e., an HTML page) without proper escaping or validation. I think what we all are interested to know is how we can fixed them or stop the attackers. Before we come to any conclusion let's see some important aspects of understanding XSS

Injection Points: These are the user input available in web applications through which the Attacker can enter or injects scripts

• Insert /Edit Text
• Insert/Edit Image
• Insert/Edit URL
• Set Attributes
• Insert/Upload File
• Insert/Upload Video

Context is an environment where user-supplied input or input from other application(s) eventually ends-up or starts living.

“Context Is King for All Areas of IT Security”  At simple it means attackers use these Injection points to send their scripts and whatever they input in web app ends up somewhere and where it ends up called as context. Actually all the attacks and bypasses are based on these contexts. So let's first understand the contexts briefly:

(All examples are based on PHP and standard HTML)

HTML Context:

In this context the user inputs ends up or will be reflecting back in html tag.To understand it let's see an example.

Let's say we are searching a string "xyz" in the following web http://www.ea.com/search?q=“xyz

From the source code of the result we can see that here the user input (searched string) is reflect back into a <span> tag and <title> tag or more speciously in a HTML tag

Attribute Context:

In this context the user inputs ends up or will be reflecting back as a part of attribute value.To understand it let's see an example.

Here we search a string "JUNK" in the web http://www.ea.com/search?q=“JUNK  and when we see the source code we found that the input reflected back in the value of an attribute like "title" or "href" of Anchor tag <a>

Script Context:

In this context the user inputs ends up or will be reflecting back as a part of variable in script tag.To understand it let's see an example.

Here we search the string "xxxxxxxxx" in the web  http://search.health.com/results.html?Ntt=xxxxxxxxxx and when we see the source code we find that the input reflected back as part of variable declaration searchString and searchTerms

In both example quotes are different, it may be single quote or double quote.

URL Context:

In this context the user inputs ends up or will be reflecting back as a value of href of anchor tag. Even it can be iframe tag and source attribute. All Content Management System support url context.

Now a days it is a common feature specially in an wysiwyg editor "What You See Is What You Get" to insert a link and in this way user supply URL directly.

Style Context:

In this context the user inputs ends up or will be reflecting back as part of the style attributes or style tags. So in this below example we can see a developer guide from ebay where user can input a style. And it provide option to attacker to input style to bypass.

Let's summarize all the contexts so normally when an user provide any input to the Injection points in an web application, it goes to the the server and from there it reflect back to the user's page with different contexts. It can be one of contacts mentioned above.

Not only Contexts we also need to know over the Attack Methodology as well, all these would help us to understand the XSS very deeply.. which I will publish in my next blog.

I also come across with some nice series of blogs by alexander.polyakov on Securing SAP Systems from XSS vulnerabilities. It is always good to know over different aspects of those things which you are interested to learn.

(Most of these details, screenshots and explanation has been shared from Ashar's Talks) If you want to know more over the XSS I would definitely recommend to visit the slides from the Ashar's Talks (Presentations by Ashar Javed)  and the blogs(on XSS) where he nicely explains over his works, findings and his bypasses.