Multiple Browser Cookie Injection Vulnerabilities
Results 1 to 2 of 2

Thread: Multiple Browser Cookie Injection Vulnerabilities

  1. #1
    King Arana: Super Moderator
    Join Date
    Oct 2002

    Multiple Browser Cookie Injection Vulnerabilities


    Westpoint Security Advisory
    Title: Multiple Browser Cookie Injection Vulnerabilities
    Risk Rating: Low
    Software: Multiple Web Browsers
    Platforms: Unix and Windows
    Author: Paul Johnston <>
    assisted by Richard Moore <>
    Date: 15 September 2004
    Advisory ID#: wp-04-0001
    CVE: Multiple assigned, see main text


    A design goal for cookies is to "prevent the sharing of session
    information between hosts that are in different domains." It appears
    current implementations are successful at allowing a domain to keep its
    cookies private. However, multiple mechanisms have been discovered for one
    domain to inject cookies into another. These could be used to perform
    session fixation attacks against web applications.

    * Affected browsers be patched for these vulnerabilities.
    * Web applications implement application layer mitigations for session
    fixation attacks, as described in [2].

    Internet Explorer 6.0 for Windows 2000, all patches
    Konqueror 3.1.4 for SuSE 9.0
    Mozilla Firefox 0.9.2 for Windows 2000
    Opera 7.51 for Windows 2000

    Cross-Domain Cookie Injection
    Konqueror CAN-2004-0746
    Internet Explorer CAN-2004-0866
    Mozilla CAN-2004-0867
    Not vulnerable:

    By default, cookies are only sent to the host that issued them. There is
    an optional "domain" attribute that overrides this behaviour. For example, could set a cookie with This would
    then be sent to any host in the domain.

    There is potential for abuse here, consider the case where
    sets a cookie with In principle this would be sent to any
    host in the .com domain. However [1] requires browsers to reject cookies

    "The value for the Domain attribute contains no embedded dots"

    This prevents a cookie being set with However, this does not
    extend to country domains that are split into two parts. For example, could set a cookie with and this will be
    sent to all hosts in the domain. Mozilla follows the RFC exactly
    and is vulnerable to this. Konqueror and Internet Explorer have some
    further protection, preventing domains of the following forms:

    * Where the 2nd level domain is two or fewer characters, i.e. xx.yy or
    * Domains of the form (com|net|mil|org|gov|edu|int).yy

    This does prevent cross domain cookie injection but does not
    protect all domains. For example, the following .uk domains are

    When testing with Opera, it appeared that browser always correctly
    detected the domain. It is not immediately clear how Opera does this

    Example exploitation:
    1) is identified for attack. It uses the "sid"
    cookie to hold the session ID.
    2) Attacker obtains domain
    3) User is enticed to click link to
    4) This site sets the "sid" cookie with
    5) When user logs into, they are using a sesion ID known
    to the attacker.
    6) Attacker now has a logged-in session ID and has compromised the
    user's account.

    Exploitation is dependent on the user clicking an untrusted link. However,
    it is fundamental to the use of the web that we do sometimes click
    untrusted links. This attack can happen regardless of the use of SSL.

    Cross Security Boundary Cookie Injection
    Internet Explorer CAN-2004-0869
    Konqueror CAN-2004-0870
    Mozilla CAN-2004-0871
    Opera CAN-2004-0872

    By default cookies are sent to all ports on the host that issued them,
    regardless of whether SSL is in use. There is an optional "secure"
    attribute that restricts sending to secure channels. This prevents secure
    cookies leaking out over insecure channels. However, there is no
    protection to prevent cookies set over a non-secure channel being
    presented on a secure channel. In general to maintain proper boundaries
    between security levels, it is necessary to defend against both attacks -
    protecting both confidentiality and integrity.

    Example exploitation:
    1) identified for attack, which uses "sid" cookie
    as session ID.
    2) User is enticed to click link to
    3) By some mechanism the attacker intercepts this request and sets the
    "sid" cookie
    4) When user logs into they are using a sesion ID
    known to the attacker.
    5) Attacker now has a logged-in session ID and has compromised the
    user's account.

    In addition to the user clicking an untrusted link, exploitation is
    dependent on the attacker tampering with non-SSL network traffic. This is
    a reasonable assumption as the purpose of SSL is to provide security over
    an insecure network.


    [1] RFC2965 - HTTP State Management Mechanism

    [2] Session Fixation Vulnerability in Web-based Applications

    [3] Persistent Client State - HTTP Cookies

    [4] Cookies and Cookie Handling in Opera 7 Explained

    Space For Rent.. =]

  2. #2
    Senior Member
    Join Date
    Jan 2002
    I'm pretty sure I read about this a long time ago.

    Hey - I'm even pretty sure my browser has had some of these cookies in the past - although my current Firefox 1.0PR seems to be free of them.

    Specifically, I think shops based on Microsoft Commerce Server have been sending these cookies with a domain.

    Anyway it's quite unlikely (IMHO) that a etc site would want to try to attack another (in the same second level domain).

    Additionally hardly anyone uses, and such like. All UK companies pretty much use domains (or .com even).


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts