[REVS] DOM Based Cross Site Scripting

From: SecuriTeam (support_at_securiteam.com)
Date: 08/02/05

  • Next message: SecuriTeam: "[EXPL] Baby Web Server Command Validation (Exploit)"
    To: list@securiteam.com
    Date: 2 Aug 2005 18:16:11 +0200
    
    

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      DOM Based Cross Site Scripting
    ------------------------------------------------------------------------

    SUMMARY

    We all know what Cross Site Scripting (XSS) is, right? It's that
    vulnerability wherein one sends malicious data (typically HTML stuff with
    Javascript code in it) that is echoed back later by the application in an
    HTML context of some sort, and the Javascript code gets executed.

    Well, wrong. There is a kind of XSS that does not match this description,
    at least not in some of its fundamental properties. The XSS attacks
    described above are either non-persistent / reflected (i.e. the malicious
    data is embedded in the page that is returned to the browser immediately
    following the request) or persistent / stored (in which case the malicious
    data is returned at some later time).

    But there s also a third kind of XSS attacks - the ones that do not rely
    on sending the malicious data to the server in the first place! While this
    seems almost contradictory to the definition or to common sense, there
    are, in fact, two well described examples for such attacks.

    This technical note discusses the third kind of XSS, dubbed "DOM Based
    XSS". No claim is made to novelty in the attacks themselves, of course,
    but rather, the innovation in this write-up is about noticing that these
    belong to a different flavor, and that flavor is interesting and
    important.

    DETAILS

    Application developers and owners need to understand DOM Based XSS, as it
    represents a threat to the web application, which has different
    preconditions than standard XSS. As such, there are many web applications
    on the Internet that are vulnerable to DOM Based XSS, yet when tested for
    (standard) XSS, are demonstrated to be "not vulnerable". Developers and
    site maintainers (and auditors) need to familiarize themselves with
    techniques to detect DOM Based XSS vulnerabilities, as well as with
    techniques to defend against them, both there which are different than the
    ones applicable for standard XSS.

    The reader is assumed to possess basic knowledge of XSS ([1], [2], [3],
    [4], [8]). XSS is typically categorized into "non-persistent" and
    "persistent" ([3], "reflected" and "stored" accordingly, as defined in
    [4]). "Non-persistent" means that the malicious (Javascript) payload is
    echoed by the server in an immediate response to an HTTP request from the
    victim.

    "Persistent" means that the payload is stored by the system, and may later
    be embedded by the vulnerable system in an HTML page provided to a victim.
    As mentioned in the summary, this categorization assumes that a
    fundamental property of XSS is having the malicious payload move from the
    browser to the server and back to the same (in non-persistent XSS) or any
    (in persistent XSS) browser. This paper points out that this is a
    misconception. While there are not many counterexamples in the wild, the
    mere existence of XSS attacks which do not rely on the payload embedded by
    the server in some response page, is of importance as it has a significant
    impact on detection and protection methods. This is discussed in the
    document.

    To read more about the subject please visit:
    <http://www.webappsec.org/projects/articles/071105.shtml>
    http://www.webappsec.org/projects/articles/071105.shtml

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:contact@webappsec.org>
    Robert Auger.
    The article has been written by Amit Klein
    The original article can be found at:
    <http://www.webappsec.org/projects/articles/071105.shtml>
    http://www.webappsec.org/projects/articles/071105.shtml

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.


  • Next message: SecuriTeam: "[EXPL] Baby Web Server Command Validation (Exploit)"

    Relevant Pages

    • [NEWS] Google.com UTF-7 XSS Vulnerabilities
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Google.com UTF-7 XSS Vulnerabilities ... The server response lacks charset encoding enforcement, ...
      (Securiteam)
    • [UNIX] TTT-C Multiple Cross-Site Scripting
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... "The World's Most Advanced Free C Traffic Trading Script. ... Some examples of XSS bugs in the 'Links' panel are provided: ... An example analysis of the IP Logs panel reveals that the IP address can ...
      (Securiteam)
    • [UNIX] B-net Software Multiple XSS
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... B-net Software Multiple XSS ...
      (Securiteam)
    • Re: [Full-disclosure] on xss and its technical merit
      ... detailed technical knowledge of all things xss. ... other's attacks since then. ... "Saying XSS isn't a vulnerability is like like saying a binary that ... (javascript is ONE scripting language and therefore NOT a requirement)). ...
      (Full-Disclosure)
    • Re: [Full-disclosure] on xss and its technical merit
      ... "Saying XSS isn't a vulnerability is like like saying a binary that has a ... "XSS needs javascript, binary needs its own malcode as well." ... (javascript is ONE scripting language and therefore NOT a requirement)). ...
      (Full-Disclosure)