[Full-Disclosure] Application validation on defensivethinking.com

From: jamie fisher (contact_jamie_fisher_at_yahoo.co.uk)
Date: 07/27/04

  • Next message: The Central Scroutinizer: "[Full-Disclosure] Damb Beagles"
    To: full-disclosure@lists.netsys.com
    Date: Tue, 27 Jul 2004 19:48:48 +0100 (BST)
    
    

    I've noticed some issues with respect to the way some of defensivethinking's web pages handle and validate (or rather not validate) scripts.

    Link: http://defensivethinking.com/contact/submit.php

    Parameter: strFirstName=admin -> strFirstName=>"'><script>alert('Look mummy I'm on Big Kev's web site')</script>
    Parameter: strFirstName=admin -> strFirstName=>"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;This%26%23x20;-%26%23x20;web%26%23x20;site%26%23x20;is%26%23x20;XSS%26%23x20;vulnerable%26quot;)>
    Parameter: strFirstName=admin -> strFirstName=>%22%27><img%20src%3d%22javascript:alert(%27This%20-%20web%20site%20is%20XSS%20vulnerable%27)%22>

     

    Impact:
    Customer session and cookies are compromised. The attacker may be able to pose as a legitimate user to view and alter user records, and perform transactions as that user.

    Test Description:
    There are three parties involved in this attack:
    (A) - is an attacker. He/she may know the identity of "B", and the structure of site "C".
    (B) - is the victim user (of web-site "C").
    (C) - is the vulnerable web-site.

    The attack is basically a privacy violation. The attacker (A) gains the victim user (B)'s credentials at the vulnerable site (C). When the site involved is vulnerable, it is possible to steal credentials from its users. It is not possible to gain information regarding other sites, so (C)'s vulnerability affects only (C)'s customers.

    The attack hinges on the fact that the web-site (C) has a script that returns user input (usually a parameter value, but variants are discussed below) in an HTML page without first sanitizing the input. This allows an input consisting of JavaScript code to be executed by the browser when the script returns this input in the response page. As a result it is possible to form links to the site (C) where one of the parameters consists of malicious JavaScript code. This code will be executed (by (B)'s browser) in (C) site context, granting it access to cookies (B) has for site (C), and other windows in site (C) at browser (B).
    The attack proceeds as following: The attacker (A) lures the legitimate user (B) to click on a link that was produced by the attacker. When the user clicks on the link, this generates a request to the web-site (C) containing a parameter value with malicious JavaScript code. If the web-site (C) embeds this parameter value into the response HTML page (this is the essence of the site vulnerability), the malicious code will run in the user's browser (B).

    Possible actions that can be performed by the script are:
    [1] Sending the attacker the user cookies for the legitimate site
    [2] Sending the attacker the current URLs of the legitimate site in which the user has an open window
    This information is sent to the attacker (A), and thus the victim user "C"'s security (privacy) is compromised.

    Some notes:
    [1] Although the attacked web-site (C) is involved, it is not in itself compromised (in the narrow sense). It is only used as a jump station for the malicious script (sent by the attacker) to return to the victim's browser (B) as if it is legitimate. However, since the privacy of the victim (B) is breached in the context of site (C), and since site (C) is directly responsible, it is considered a security flaw in site (C) (much like a weak session token would have been).
    [2] The malicious link can be provided by (A) by via a web-site link (if (A) maintains a site that is visited by (B)), or via email (if (A) knows (B)'s email address, and if (B)'s email client uses the browser to render the HTML message).
    [3] While user input is most commonly found in form field values (i.e. URL parameters), there are known attacks where the malicious code is embedded in the path, or in the HTTP Referer headers, and even in cookies.

    Fix Recommendation
    Sanitise user input and filter JavaScript code. Filter the following characters: < > " ' % ; ) ( & +

    Response from defensivethinking.com and Kevin Mitnick:

    No response received.

    I don't think Kevin and I are friends any more.

    Hi to the Vodalads - except Lee Power who couldn't secure a personality.

    References And Relevant Links
    CERT Advisory CA-2000-02
         http://www.cert.org/advisories/CA-2000-02.html

    Microsoft HOWTO: Prevent Cross-Site Scripting Security Issues (Q252985)
         http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

    Microsoft Technet "Cross-site Scripting Overview"
         http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/csoverv.asp

                    
    ---------------------------------
     ALL-NEW Yahoo! Messenger - all new features - even more fun!

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: The Central Scroutinizer: "[Full-Disclosure] Damb Beagles"

    Relevant Pages

    • RE: [Full-disclosure] SPIDynamics WebInspect Cross-ApplicationScripting (XAS)
      ... Usually when I have a bug report it is a full set of instructions ... > there are remote cross-application scripting attack in SPIDynamics ... > WebInspect and domain level cross-application attack with potential ... >Attacker should create specially crafted site with vulnerability to be ...
      (Bugtraq)
    • RE: [Full-disclosure] SPIDynamics WebInspect Cross-ApplicationScripting (XAS)
      ... Usually when I have a bug report it is a full set of instructions ... > there are remote cross-application scripting attack in SPIDynamics ... > WebInspect and domain level cross-application attack with potential ... >Attacker should create specially crafted site with vulnerability to be ...
      (Full-Disclosure)
    • [NT] Cookie Data in IE Can Be Exposed or Altered Through Script Injection
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Many web sites use cookies as a way to store information on a user's local ... customers can protect their systems by disabling active scripting. ... are not affected by the HTML mail exploit of this vulnerability because ...
      (Securiteam)
    • SPIDynamics WebInspect Cross-Application Scripting (XAS)
      ... Scripting" oded by QQLan@yandex.ru) ... WebInspect and domain level cross-application attack with potential ... Below is original anonymous report for cross application scripting in ... Attacker should create specially crafted site with vulnerability to be displayed in report. ...
      (Bugtraq)
    • [Full-disclosure] SPIDynamics WebInspect Cross-Application Scripting (XAS)
      ... Scripting" oded by QQLan@yandex.ru) ... WebInspect and domain level cross-application attack with potential ... Below is original anonymous report for cross application scripting in ... Attacker should create specially crafted site with vulnerability to be displayed in report. ...
      (Full-Disclosure)