Protect your website form cross site scripting (XSS) attacks

There are over 3 billion internet users world wide encountered. More than ever we depend on the internet. Web applications have, in a very short amount of time, become our primary means of shopping, banking, keeping up with the news, and ultimately, communicating. Web-based technologies have taken over the world as the primary way of building software applications. Even mobile applications, often touted as a new trend in software development, are basically web service–based thin client applications that depend on web technology to work effectively.

These days there are lot of cyber threats such as yahoo-breach-billion-users , linked in-data-breach-email-password and latest wanna cry attack that has been hacked different fields in different ways of attacks. Cross Site Scripting is a one of a vast area that cover in the cyber attacks.

In this post I am going to not only explain how to do a cross site scripting attack, but also teach a wide variety of defense techniques to help you
build Java web applications that prevent these attacks from being successful. This post is contained four main stories based on different type of cross site scripting attacks.

Cross-site scripting, or “XSS,” is a form of attack executed by including untrusted data, such as malicious JavaScript code, into the victim’s web browser.

XSS is one of the most common vulnerabilities found across the Web. In our personal experience, 80–90 percent of websites subjected to intensive penetration testing exhibited at least one instance of XSS. XSS vulnerabilities can be exploited to devastating effect by an attacker to capture session cookies and CSRF tokens, modify page contents, change the location where form submissions are sent, or read the browser’s autocomplete history. With JavaScript’s emergence as a fully fledged web programming language, almost anything is possible. Exploits have been demonstrated using JavaScript for reconnaissance of private networks, and to identify vulnerable hardware and update firmware with malware. XSS attacks issue from an unsuspecting user’s browser. Also, given that XSS is executed within the victim’s web browser, the attacker’s code executes at the user’s privilege level.

Types of XSS

  • Reflected XSS, where the malicious string originates from the victim’s request.
Reflected xss

This occurs when an attacker tampers with HTTP requests to
submit malicious JavaScript code. Upon receipt of the request, the website immediately renders the modified content, including the malware script without encoding, back to the victim’s web browser.

  • Stored XSS, where the malicious string originates from the website’s database.
Stored XSS

This occurs when an attacker submits malicious content to your website, and this content is stored in a database and later rendered for other uses on web pages (for example, on blog comments, a web forum, administrator interface, and so on). In this scenario, the victim is likely already authenticated, which could serve to make the attack more effective because the script will execute with the same permissions as the logged-in user. Stored cross-site scripting is the perfect example of why input validation alone is not a sufficient defense.

  • DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code.
DOM-based XSS

DOM-based XSS is best understood by how it must be treated from a defense
point of view. While reflective and stored XSS must be defended via encoding when building UI code server-side, DOM XSS is almost exclusively managed by adding defenses into custom JavaScript code, or by simply using safe JavaScript APIs in custom JavaScript code.

So far I was trying to give an understanding about what is a XSS attack? and what are the types of attacks and finally why should we try to prevent these attacks. From now, I am going to move to the main purpose, how to defend a XSS attack.

Defending XSS

Building a web application that is resistant to cross-site scripting can be challenging. For example, having to remediate an old legacy web application that contains significant XSS, in a language that does not have the right security libraries, without any programmers on staff who have direct experience with the language, can be quite a time-consuming and expensive problem to deal with.

When developing a web application, there are two basic different ways of performing secure input handling.

  • Validation, which filters the user input so that the browser interprets it as code without malicious commands.
  • Contextual Output Encoding, which escapes the user input so that the browser interprets it only as data, not as code.

Input Validation

Good input validation should be the first line of defense for every web application. For example, if your application strips out all <script> tags, an
attacker can submit <scr<script>ipt> to get around the first round of sanitization.
Blacklist-based input validation never works to stop XSS. If you blacklist
the string <script> , an attacker will try to submit an image tag with the same payload:
<img src=”http://example.com/any.jpg" onLoad=”alert(‘hi’)”/>

Contextual Output Encoding

Output encoding, or output escaping, is a technique that converts data to a form that is display-only and will not execute JavaScript or even render HTML tags. For example, if we set a username to august<script>alert(“hi”);</script> then you would see a little w00t pop up every time you visited a page that listed my username, such as My Profile or a forum comment.

However, when HTML entity encoding is applied to that username, the code
will be visible on the page, but not executable! Figure 4–6 illustrates JavaScript XSS tests being rendered safely because they are output encoded with HTML entity encoding.

I have developed a sample web application to try this xss attacks. To try that out you need to get some understanding about the input context of your application.

Input handling contexts

There are many contexts in a web page where user can insert values. You can understand the context easily with the experience of developing web applications. After identifying the context, rules which is specific for each context must be followed so that the user input cannot break out of its context and be interpreted as malicious code. The following most common contexts are targeted in my sample demo application.

1. HTML element content Attack.

<div>userInput</div>

2. HTML attribute value Attack.

<input value=”userInput”>

3. JavaScript value Attack.

js Method(“userInput”)

4. URL query value Attack.

<img src =”userInput”>

<a href=”userInput”>

5. DOM based Attack.

<div>userInput</div>

We will need to include different type of encoding for each different types of context. But we do not need to write these encoding functions from scratch. Even if you skip most validation, good output encoding will save your website from most XSS. But if you have a good input validation, you will still have to face XSS if you skip the output encoding. Better way is t have both.

I mentioned above that we do not need to write the encoding function from scratch. Solution is to use a Java encoder project. I have used OWASP Java Encoder Project in my sample application.

OWASP Java Encoder Project

This is a most widely used encoding library among web developers when developing a secure web application. The OWASP Java Encoder Project includes a large number of encoding methods for every possible context a developer should encounter in the course of building a rich web application.

The encoders encode only the characters that need encoding and nothing else. The encoders remove invalid characters from the text. For example,
some characters are not valid anywhere in XML (and thus XHTML). If the characters are included, the XML parser/browser rejects the document/page as invalid. Encodings are chosen to be as cross-compatible as possible.

Try this sample application (XssLearner). This project is a web application xss(Cross Site Scripting ) security training platform. XssLearner gives the opportunity to try out different type of xss attacks and follow up the necessary actions to prevent from hacking and to make sure your softwares are secure. You can follow this blogpost without using the application. But with the application you can experience what attacker think about your web site and how he/she proceed. That will be a good motivate to you o follow best practices for your web application. Other that that, here I describe each and every step to defend the web application according to each context.

This gives you the opportunity to follow the xss attacks in the above described 5 contexts.

1. HTML element content Attack.

<div>userInput</div>

This place we should do an encoding that is valid to a html content. If user inputs any html tag, encoder should identify the invalid characters from the text and encode those and nothing else.

This is where the user gives the inputs.

This would be the chance to do an attack. Check the following code. You are right. It has <div>userInput</div> this case. So someone can do an attack on this web page. You can try out xss attacks upon this vulnerability with my app.

So what can you do to prevent this. Use the encoder to encode these input, thus invalid scripts are not to be executed. Here you can use Encode.ForHtml() method. Another option that is specific to this place is use textContent instead of getInnerHtml().

document.getElementById('div-id').textContent = dynamicText;

Look following encoded code in my jsp pge. Now there is no attack can be executed in this context. In the XssLearner you can try the encoded page as well. There you would not be able to reproduce the previous xss attack. Note : You need to import the owasp encoder for you web page as follow.

<%@ page import="org.owasp.encoder.Encode" %>

2. HTML attribute value Attack.

<input value=”userInput”>

In this context attacker can input malicious code into the html attribute value. Example vulnerable code is given below. This is where the user gives their inputs to the system.

Input is used in the following way of a web page. That is cause to a vulnerable.

If you look into this carefully, you can find a difference when comparing with the 1st context. Here we can see the value is referring to an input value. This time you can hit with a html attribute value. This can be defended by the Encode.forHtmlAttribute method by owasp java encoder as follows.

Note: When we try to do a xss we always should look the context. In this case it is really mater because here you should have to close the input tag before include a script tag.

eg :- ><script>alert('YouHaveBeenAttacked')</script>

Otherwise attack would not successful.

3. JavaScript value Attack.

js Method(“userInput”)

This is different from the above two since they are about html. Here it is about java script. This context also consists with several types such as javascript block, java script attribute. There you should be able to identify the actual context and the encoder that is valid for that context.

This is where the user inputs are use in my example application.

Thus here we should have to use encoder that is valid for javascript. Here I have use the Encode.forJavaScript method.

There are several contexts of java script encoder. But why I have used forJavaScript method?? You can find the reaso by going through each of the following given javascript specific methods description. OWASP java encoder supports several methods and some are follow,

  • forJavaScript(String) - Encodes for a JavaScript string.
  • forJavaScriptAttribute(String) - This method encodes for JavaScript strings contained within HTML script attributes (such as onclick).
  • forJavaScriptBlock(String) - This method encodes for JavaScript strings contained within HTML script blocks.

Why forJavaScript, but not forHtml?

Actually you might think why are we using several methods. But the thing is in each different method there are severeal set of characters that are encoding. As an example in forHtml it encodes the html syntaxes, but forJavaScript it encodes the javascript syntaxes. Thus, if you’re including user-supplied content in HTML, you can’t use JavaScript syntax to escape it.

4. URL query value Attack.

<img src =”userInput”>

<a href=”userInput”>

Another context is a url component. This is one of the most common attack. Simply look the following code.

img src =”userInput”
a href=”userInput”

I think now you are somewhat familiar with owasp encoder. Moreover you should probably understand why are we using diferent methods for different contexts. Now in the above two code samples there are img src tag and href tag. Since this is represents an url we can use url encoding component for both cases. I have used owasp Encode.forUriComponent method for my sample.

Then attack can be defended.

5. DOM based Attack.

<div>userInput</div>

Final context that is addressed under my sample application is DOM based attack. Actually this is similar to the 1st case in my application, because it just change the DOM(Document Object Model) of the HTML page.

I would like to explain an example to be get into deep about DOM based attack. Look the following code.

<%
String message = request.getParameter( "query" )
%>
<script>
window.onload = function() {
//get values from the URL
var message='<%=message%>';
//write the value to the DOM
document.getElementById("post-container").textContent=message;
}
</script>
<div id="post-container"></div>

When a user hits the page with a URL that contains a script in the query (message) parameter, it will cause that script to be added to the DOM and executed in
the browser.

ex :- http://www.vulnerableSite.com#script>alert('YouHaveBeenAttacked')</script>

XSSLearner Installation

You can use the xssLearner, sample web application to try out the basic xss attacks and preventing mechanism.

You can pull it from github, build war and deploy into tomcat server.

or

I have build a docker image available on Dockerhub. You can just pull that iage and run. Just run following command to pull the image. Please make sure that you have installed docker in your machine.

docker pull nadeeshani/xsslearner

Then run,

docker run --rm -p 8080:8080 nadeeshani/xsslearner

Now access : http://localhost:8080/xsslearner/

Hope you find this blog post useful! You can now identify xss vulnerable context and do the needful to prevent from an attack.

Cheers. :)

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade