How to prevent cross site scripting

Posted March 28, 2015

Today at codingsec we are going to discuss one of the most common coding vulnerabilities that you need to take in consideration when programming. Cross site scripting or XSS is one of the most exploited security vulnerabilities on web applications throughout the Internet today. Top security analysts have discovered this vulnerability in top websites such as Google,Facebook,Amazon and Paypal. To prevent cross-site scripting, browsers also have their own filters, but security experts have the skills to get past them. This vulnerability is generally used to perform cookie stealing, malware spreading, session hijacking, and malicious redirection. In this attack, the attacker injects malicious JavaScript span into the website so that the browser executes the script.

“Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious span, generally in the form of a browser side script, to a different end user.”

Examples of XSS

A few XSS examples:

Example 1

You see a search box on almost all websites. With this search box, you can search to find anything available on the website. This search form looks something like this

<form action=“search.php” method=“get”>
<input type=“text” name=“q” value=“” />
<input type=“submit” value=“send” />
</form>

On the search.php page where it shows search results, it also lists the search keyword in the form of “Search results for Keyword” or “You Searched for Keyword.”

On web pages, it is generally coded like this:

<h3>You Searched for: <!–?php echo($_GET[‘q’]) ?–>

Whatever a person searches for, it will be displayed on the web page along with search results. Now think what happens if an attacker tries to inject malicious script from this side.

Search for

“><script>alert(‘XSS injection’)</script>

If web application has nothing implemented to encode input and filter malicious scripts, it will take input as it is and then print on webpage where it will be called. So, at the keyword place, it will look like this:

<h3> You Searched for: “><script>alert(‘XSS injection’)</script>

It will be executed by the browser and it will display an alert box saying “XSS injection.”

Example 2

Suppose there is a website with a messaging feature. In this website, users can send messages to their contacts. A basic form will look something like this:

<form action=“sendmessage.php” method=“post'”>
<textarea name=“message”> </textarea>
<input type=“submit” value=“send” />
</form>

When this form is submitted, the message will be stored in the database. Another person will see the message when he opens the message from the inbox. Suppose an attacker has sent some cookie-stealing script in the message. This script will be stored on the website as a message. When the other person tries to read the message, the cookie-stealing script is then executed and the users session id is now on the attacker’s side. With a valid session id, the attacker can hijack the other person’s account.

There are three different types of XSS exploits:

Non-Persistent Cross-site scripting attack

Non-persistent XSS is also known as reflected cross-site vulnerability. It is the most common type of XSS. In this, data injected by the hacker is reflected in the response. The first example shown above is a Non-Persistent XSS attack. . A typical non-persistent XSS contains a link with XSS vector.

Persistent Cross-site scripting attack

Persistent cross-site scripting is also known as stored cross-site scripting. It occurs when XSS vectors are stored in the website database and executed when a page is opened by the user. Every time the user opens the browser, the script executes. In the above examples, the second example of messaging a website was a persistent XSS attack. Persistent XSS is more harmful that non-persistent XSS, because the script will automatically execute whenever the user opens the page to see the content. Google’s orkut was vulnerable to persistent XSS that ruined the reputation of the website.

Dom-based Cross-site scripting attack

DOM Based XSS simply means a Cross-site scripting vulnerability that appears in the DOM (Document Object Model) instead of part of the HTML. In reflective and stored Cross-site scripting attacks you can see the vulnerability payload in the response page but in DOM based cross-site scripting, the HTML source span and response of the attack will be identical, i.e. the payload cannot be found in the response. It can only be observed on runtime or if you query the DOM page.

Why does Cross-site Scripting occur?

The primary reason for cross-site script attacks is the trust of developers for users. Developers easily think that users will never try to perform anything wrong, so they create applications without using any extra efforts to filter user input in order to block any malicious activity. Another reason is that this attack has so many variants. Sometimes, an application that properly tries to filter any malicious scripts gets confused and allows a script. In the past few months, we have seen many different kind of XSS vectors that can bypass most of the available XSS filters.

So we can never say that a website is fully protected. But we can do our best to filter most of the things, because extraordinary vectors mostly come from responsible security researchers and they will also help you in patching and making your filter smarter.

How to Create a good XSS Filter to Block Most XSS Vectors

Before we start creating a XSS filter, I want to say one important thing: We can never claim to have a perfect XSS filter. Researchers always find weird ways to bypass filters. But we can try to make a filter that can filter easy and well-known XSS vectors. At least you will be safe from script kiddies.

If you do not have an understanding of XSS, you cannot patch XSS. You should have an idea how attackers inject scripts. You should have knowledge of XSS vectors.

Let us start with basic filters:

There is a simple rule that you need to follow everywhere: Encode every datum that is given by a user. If data is not given by a user but supplied via the GET parameter, encode these data too. Even a POST form can contain XSS vectors. So, every time you are going to use a variable value on the website, try cleaning for XSS.

These are the main data that must be properly sanitized before being used on your website.

The URL
HTTP referrer objects
GET parameters from a form
POST parameters from a form
Window.location
Document.referrer
document.location
document.URL
document.URLUnencoded
cookie data
headers data
database data, if not properly validated on user input

First of all, encode all <, >, ‘ and “. This should be the first step of your XSS filter. See encoding below:

& –> &
< –> <
> –> >
” –> "
‘ –> '
/ –> /

For this, you can use the htmlspecialchars() function in PHP. It encodes all HTML tags and special characters.

$input = htmlspecialchars($input, ENT_QUOTES);

If the $input was= “><script>alert(1)</script>

this function would convert it into "><script>prompt(1)</script>

This line also helps when an encoded value is used somewhere by decoding it:

$input = str_replace(array(‘&’,’<’,’>’), array(‘&amp;’,’&lt;’,’&gt;’), $input);

A vector may use HTML characters, so you should also filter these. Add this rule:

$input= preg_replace(‘/(&#*w+)[x00-x20]+;/u’, ‘$1;’, $data);
$data = preg_replace(‘/(&#x*[0-9A-F]+);*/iu’, ‘$1;’, $input);

But these alone are not going to help you. There are many places where input does not need script tags. An attacker can inject a few event functions to execute scripts. And there are many ways by which an attacker can bypass this filter. So, we need to think about all possibilities and add a few other things to make the filter stronger. And not only JavaScript, you also need to escape from cascading style sheets and XML data to prevent XSS.

Open Source Libraries for Preventing XSS Attacks

PHP AntiXSS

This is a nice PHP library that can help developers add an extra layer of protection from cross-site scripting vulnerabilities. It automatically detects the encoding of the data that must be filtered. Using of the library is easy.

xss_clean.php filter

This is a b XSS filter that cleans various URF encodings and nested exploits. The developer built the function after analyzing the various sources. This coding of the function is available for free from github.

HTML Purifier

HTML Purifier is a standard HTML filtering library written in PHP. It removes all malicious span from the input and protects the website from XSS attack. It is also available as a plug-in for most PHP frameworks.

xssprotect

xssprotect is another nice library that gives developers a way to clean XSS attack vectors. This Library works by creating the HTML tag tree of the webpage. Then it parses the page and matches all tags. After that, it calls the filter interface to filter improper HTML attributes and XSS attacks. This library is written in Java.

XSS HTML Filter

HTML Purifier is a standards-compliant HTML filter library written in PHP. HTML Purifier will not only remove all malicious span (better known as XSS) with a thoroughly audited, secure yetpermissive whitelist, it will also make sure your documents are standards compliant, something only achievable with a comprehensive knowledge of W3C‘s specifications. Tired of using BBCode due to the current landscape of deficient or insecure HTML filters? Have aWYSIWYG editor but never been able to use it? Looking for high-quality, standards-compliant, open-source components for that application you’re building? HTML Purifier is for you!

Using the provided techniques and software available is essential in limiting the vulnerability to XSS exploits. I hope you have enjoyed reading, stay tuned for more content.

Reference

http://codingsec.net/

How to prevent cross site scripting

Leave a Comment Cancel reply

Leave a Comment
Cancel reply