Internet Application Security
– Cross Site Scripting –
The purpose of this document is to highlight that basic security issues must be considered when developing applications for the Internet. This document assumes the use of a normal HTML web browser and does discuss attacks when using other users agents i.e. WAP phones. Computer security is a broad subject that cannot be covered in full by this document alone therefore, this document will focus on the area of malicious HTML.
Everybody is at risk! With the rapid growth of the Internet and the explosion of e-commerce, a vast majority of computer users are exposed to potential attack from unscrupulous parties. It is usually up to the application vendor to implement the security solutions.
The topics covered in this document are:
? Identifying the risk
? Identifying the consequences
? Protecting the assets
Security breaches include unauthorized access, intrusion of viruses, theft of data or destruction of infrastructure. An important point to note from the outset is that not all attacks are from outside parties.
A web site that dynamically generates pages may inadvertently include malicious HTML tags or script based on input from untrustworthy sources. This occurs when a web application does not adequately encode the pages to prevent unexpected scripts execution, or when it does not validate the input to prevent the submission of malicious HTML.
Web Based E-mail and Bulletin Boards
This style of attack involves the attacker including malicious code in the message, hoping the client browser will interpret the text as code to execute instead of rendering it as part of the message e.g.
I would like to say that this message <script>malicious code</script> will do something bad before you finish reading it. Ha Ha!
Simple, but effective. Any service that takes input and uses it to construct an output is prone to attack. Some of the HTML tags that can be exploited are: <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.
HTTP Post using HTML Forms
The above example is one way that HTML forms can be used to introduce malicious code. An attacker can further manipulate a form taking control of the destination to which data is posted. As a web server only knows the client who posted the form and not the original server that generated the form, this is another route for exploitation. Reversing this idea slightly leads to a serious security hole in which a malicious form tag can cause data to be submitted to the attacker?s server.
HTTP GET using URLs
In this type of attack, the URL?s query string is exploited to introduce malicious code. A common example of where data in a query string appears on a dynamic page is when using a search engine. It is common to see a URL such as:
It is not uncommon for the search criteria to be included in the resulting output. Now consider the following URL introduced on a page by an attacker:
If the input is not validated, the attacker?s script could easily execute when the site is visited.
The results of a cross-site scripting attack can range from attackers showing their presence by inserting annoying messages, up to the very criminal activity of capturing credit card numbers and user details. Other variations of serious criminal activity are the capturing and possible altering of sensitive information from behind an organisations firewall.
The script written by an attacker will execute in the context of the connection to the original site. This means many of the in built security checks will not detect any breaches, as the content will be trusted, having all come from the trusted server.
An attacker who is able to introduce malicious script into a web page can ultimately do anything a legitimate developer can do. Note: some scripting languages and associated technologies are very security conscious, giving little potential for damage however, others are less secure exposing many elements of a system to abuse.
The following are some of the common concerns relating to malicious scripts.
The structure of SSL is such that and attacker cannot tap into a connection and cause mischief. SSL encrypts data so that if an attacker does tap the connection, they will be faced with a stream of cipher text that is practically impossible to decode. Unfortunately, this is not immune to malicious HTML. The core function of SSL is to maintain a secure channel to transmit data and it does this very well. What SSL does not do, is verify that the data being sent is of a secure nature. An attacker will usually be able to introduce malicious script before a secure session is instantiated. This script will then execute in the context of the current connection and will not be identified as bad. One of biggest risks here is exposing sensitive information such as credit card details. A client?s browser will usually warn if data is about to be directed away from a secure site however, an attacker can bypass this by running their own secure server.
If an attacker can introduce script into an organisations public site that is also used internally, intranet information may be exposed without the attacker ever having to break through the firewall.
This main consequence to forms is that the attacker can expose all of the forms data, change validation rules and even direct the posted information to their own web server.
Web-site developers must recognize that the pages they produce will be exposed to everyone connected to the Internet and that not all of the users can be trusted. An area where awareness of this problem is most understood is on discussion groups. Developers understand that content submitted by a user, may be viewed by many other users. Filters and validation routines are applied to prevent the insertion of malicious script, and in the case of any script that should be displayed, all input is properly translated to make sure that the content is rendered and not executed.
Organizations with web sites should analyze those with dynamic content driven by end users. Sites that rely on cookies should also be looked at. Any sites considered to be at risk should immediately be updated to filter and validate the input streams. Developers must remember that any data requested from their sites is sent in the context of originating from their site. If untrusted content is to be sent from a trusted server, filtering and validation of the output stream must be a mandatory requirement of the application.
Simple filtering can yield effective prevention of most cross-site scripting attacks. In the crudest fashion, a developer can remove certain characters from the input or output stream before further processing. Common examples of these characters are <, > and %, which can all be used to insert client and server side script.
Users cannot completely protect themselves as it is up to the web designers to build sites that are secure from cross-site scripting attacks. The main solutions available to users tend to add a level of inconvenience because they reduce browser functionality. The user solutions can prevent malicious scripting but cannot prevent malicious HTML.
The first option available to a user is to disable the execution of scripting languages, Java Applets and ActiveX controls. Cookies should also be disabled and all cached information cleared at the end of each browsing session. It is clear that although this provides a good level of protection, the usability of legitimate sites will suffer greatly.
The second option involves the user being careful about which sites they visit and which links they follow. Users should be more careful about accepting downloads they have not explicitly requested and also be wary of automatic site redirection. This solution is more risky but retains all of the browser?s functionality.
Ultimately, the only solution to this security problem is to design the site correctly.