How To Prevent Cross-Site Scripting (XSS) Security Issues?
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.
<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.
<img> tag
Some browsers will execute JavaScript when found in the <img>.
<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.
<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.
<link> tag
The <link> tag, which is often used to link to external style sheets could contain a script.
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:
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:
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.