Hi Susam,
This is a wordy way of saying "validate session tokens properly, or
suffer session fixation attacks". This section needs revising for the
simple reason that it is no longer good enough to rely on the
JSessionID or ASPSESSIONID or similar alone, which is what the
chapter currently says.
Authors need to ensure that they include a strongly pseudo random
page or function token for value transactions, which may include
private pages if you have a large reputation risk.
eg:
POST /foo.php ...
token=7384673674376476367437&action=payanyone&acct=54875847&bsb=545454&a
mount=9999
The token is also kept on the server side in the session object for
the user, and you only process the transaction if client and server
agree that the token are the same.
eg:
if ( session("token") === $_POST['token'] )
{
// invalidate the token for this request to prevent double submissions
session("token") = $sessionHandler->generateNewToken();
// process the payment
if ( processPayAnyOne($_POST['acct'], $_POST['bsb'], $_POST
['amount']) )
{
redirect(succeedURL, 0); // the next page will include the new
token in the POST data
}
else
{
redirect(failURL, 0);
}
}
For example of an attack like this, many forum softwares allow
attackers to set a remote avatar image URL in their profile like this:
http://www.example.com/forum/logout.php
and the software does not validate that the remote avatar URL is
actually an image. Of course, this logs out all users who see that
"avatar". This can be avoided in three ways:
a) include a page / function token and check it in logout.php - this
is the approach UltimaBB takes and is similar to the method
demonstrated above
b) validate that the remote avatar image is an actual image before
every view - this is the approach phpBB with some avatar hacks take
c) take a copy of the remote avatar image (if it is indeed an image)
and store it locally to prevent further tampering - this is the
approach vBulletin now takes
The entire idea is to prevent a worse attack, where the attacker
might be able to force the user to a page, like this:
http://www.examplebank.com/transfer.php?
action=payanyone&acct=54875847&bsb=545454&amount=9999
If a intercepting trojan has your cookie - which includes many
applications *only* session token, using a function / page token can
prevent that attack... but some trojans also keep post and get data,
so you need to validate a few semi-trustworthy headers as well. To
the mix of a truly random page / function token, you should also
check that the client's IP address and User Agent doesn't change -
but don't trust them - use a hash of the values. Any change is likely
to be an attack. But this is only a temporary measure - Bank Phishing
Trojans could easily be adapted to fake these as well if you take and
hash fakeable headers.
The solution to this issue - to be done right now - is disconnected
transaction signing for high value transactions. I would have said
that banks need to do this by 2007, but honestly, with the latest
Banking trojans out and about, places running high value sites over
the internet need to introduce controls like this very soon if not
already. The values the user should enter include into the token
include the value and at least part of the destination or source
account (or whatever works best for the transaction your app is doing).
Connected transaction signing devices, such as USB connected tokens
or smart cards allow the user to go "yep, I agree" whenever they see
a transaction signing request pop up on the screen. This happens
today with MacOS X - when was the last time a MacOS X user clicked
the triangle to see the detail of the requesting application? I don't
do it, and I'm a tinfoil hat paranoid when it comes to security.
thanks,
Andrew
- OWASP Guide Lead
On 18/04/2006, at 2:18 AM, susam_pal@yahoo.co.in wrote:
"If an attacker can guess these id’s, and the supplied values are
not validated to ensure the are authorized for the current user,
the attacker can exercise the access control scheme freely to see
what they can access."
I have never used such ids, indexes or keys when I developed
authentication systems to reference users or roles. What kind of
ids or keys are we talking about? How can an attacker use a guessed
id?
smime.p7s
Description: S/MIME cryptographic signature
