A Real Solution

The best defense against CSRF attacks is unpredictable tokens, a piece
of data the server can use to validate the
request which an attacker can’t guess. For example, an “important”
request could contain a digest of the user’s session
credential, which is different for every user. And, for a little extra
security, add a timestamp to the token to limit the
window of opportunity as specified in the POST body ofUnless the
attacker can obtain the user’s session credential, which they should
never be able to do, they can’t
manufacture a valid request even if they knew the scheme. This method
can also be applied to either GET or POST
requests.


include POST http://webbank/transfer_funds.cgi HTTP/1.1
Host: webbank
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;)
Firefox/1.4.1
Cookie: JSPSESSIONID=3D 4353DD35694D47990BCDF36271740A0C
from=3D314159265&to=3D011235813&amount=3D5000&date=3D11072006&token=3D4e0fc=
1a82c3ca3b9d2a146
2570f6c674&timestamp=3D1184001456


There are two other solutions worth mentioning: The first is limiting
the time in which a user’s session credential is valid.
By enforcing inactivity timeouts, you limit the window of opportunity
for a successful CSRF attack. (This is independent of
whether the user decides to logout or not.)
The second method is password re-verification, in which the user must
type in their password when requesting a
particularly critical function.


On May 21, 12:50 pm, Srinivas Naik <[email protected]> wrote:
> Hi,
>
> Hope XSS has got sufficient information in the mailing list. So, going
> further lets have some focus on Advanced XSS specially named as CSRF (Cross
> Site Reference Forgery).
>
> *Intro:*
> Cross Site Request Forgery (also known as XSRF, CSRF, and Cross Site
> Reference Forgery) works by exploiting the trust that a site has for the
> user.
> If a user is logged into the site and an attacker tricks their browser into
> making a request to one of task urls (same Site), then the task is
> performed.
> *
> How to Achieve CSRF:*
> Typically an attacker will embed malicious HTML or JavaScript code into an
> email or website to request a specific 'task url' which executes without the
> users knowledge, either directly or by utilizing a Cross-site Scripting(XSS)
> Flaw.
>
> *Severity of the Attack*: The attack severity cannot be guessed unlike other
> attacks. Its may be very dangerous.
>
> Regards,
> 0xN41K
>
> --
> You received this message because you are subscribed to the Google Groups 
> "nforceit" group.
> To post to this group, send an email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/nforceit?hl=en-GB.

-- 
You received this message because you are subscribed to the Google Groups 
"nforceit" group.
To post to this group, send an email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nforceit?hl=en-GB.

Reply via email to