Thanks for the overview Sandeep. This helps to do more analysis and come up with few more Crossdomain Vulnerabilities.
Flash, Untrusted Emails will be the main areas to be pwned easily. Let's be aware of those. Regards, Srinivas Naik On Wed, Jun 2, 2010 at 8:22 PM, Sandeep Thakur <[email protected]> wrote: > 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]<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.
