As we understand that every individual web users can do relatively little
less to combat with CSRF. The best known steps to me includes:
1) Logging out of sites and avoiding "remember me"
2) not displaying external images or not clicking links in "spam" or
untrusted e-mails may also help.
Though many web sites have various CSRF countermeasures as given below:
- Requiring authentication in GET and POST parameters, not only cookies,
- Checking the HTTP Referer header,
- Ensuring there's no crossdomain.xml file granting unintended access to
Flash movies,
- Limiting the lifetime of authentication cookies,
- When processing a POST, disregard URL parameters if you know they
should come from a form,
- Requiring a secret, user-specific token in all form submissions and
side-effect URLs prevents CSRF; the attacker's site can't put the right
token in its submissions.
A variation on this approach is to "double submit" cookies for users who use
JavaScript. If an authentication cookie is read using JavaScript before the
post is made, JavaScript's stricter (and more correct) *cross-domain
rules*will be applied. If the server requires requests to contain the
value of the
authentication cookie in the *body* of POST requests or the URL of dangerous
GET requests, then the request must have come from a trusted domain, since
other domains are unable to read cookies from the trusting domain.
Checking the HTTP Referer header to see if the request is coming from an
authorized page can work, but a request that omits the Referer header must
be treated as unauthorized because an attacker can suppress the
Refererheader by issuing requests from FTP or HTTPS URLs. This strict
Referer validation may cause issues with browsers or proxies that omit the
Referer header for privacy reasons. Also, old versions of Flash (before
9.0.18) allow malicious Flash movies to generate GET or POST requests to
arbitrary domains with legitimate cookies and forged Referer headers.
To prevent forgery of login requests, sites can use these CSRF
countermeasures in the login process, even before the user is logged in.
Sites with especially strict security needs, like banks, often log users off
after (for example) 15 minutes of inactivity.
Using the HTTP specified usage for GET and POST, in which GET requests never
have a permanent effect, is good practice but is not sufficient to prevent
CSRF. Attackers can write JavaScript or ActionScript that invisibly submits
a POST form to the target domain. However, filtering out unexpected GETs
prevents some particular attacks, such as cross-site attacks using malicious
image URLs or link addresses and cross-site information leakage through
<script> elements ("JavaScript hijacking"); it also prevents
(non-security-related) problems with aggressive Web crawlers and link
prefetching.
I hope this helps! Thanks!!!!!!
Regards
Sandeep Thakur
On Sat, May 22, 2010 at 11:20 AM, nitin gupta <[email protected]>wrote:
> 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×tamp=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]<nforceit%[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]<nforceit%[email protected]>
> .
> For more options, visit this group at
> http://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.
