Talk:Cross-site request forgery
From Wikipedia, the free encyclopedia
 |
This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions. |
| Stub | rated as Stub-Class on the assessment scale |
| High | rated as High-importance on the assessment scale |
 |
This article is within the scope of WikiProject Internet, an attempt to better organise information in articles related to the Internet. For more information, visit the project page. |
| Stub | This article has been rated as Stub-class on the class scale. |
| High | This article has been rated as High-importance on the importance scale. |
 |
This article is part of WikiProject Malware, an attempt to better organise information in articles related to Malware. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion. |
Contents |
[edit] GET vs POST
"Also, making the server accept POST requests only instead of GET requests will make such attacks harder."
Back in the days of Mosaic and Netsape 1, yes. Since Netscape 2, no. It is trivial to call JavaScript's form.submit() on a POST form in a hidden (i)frame. Removing this enduring myth.
NeilFraser 23:27, 5 April 2006 (UTC)
POST does make it somewhat harder to exploit this. For example, you wouldnt't be able to do the image-trick mentioned above in the article on sites which scrubs javascript from user intput if you required POST requests. I.e., by preventing XSS and requiring POST, you will block that particular XSRF attack vector. So while I agree that POST is not the solution, it will make it less trivial to exploit XSRF issues on most sites where people contribute content.
Olekasper 08:10, 10 August 2006 (UTC)
I think this page should clarify something a little: If your site is susceptible to XSS (Cross-Site Scripting) then neither requiring POST requests or performing transient authentication (described in 1st paragraph) will protect you. Using JavaScript you can execute a POST request to circumvent the POST requirement. To circumvent transient authentication you can use JavaScript to download a page, look for the secret token to send along with your malicious request and send the malicious request along with the secret token.
If you close the XSS hole on your site then either one of the above methods will close the XSRF hole.
Some more detail on why requiring POST is secure: If the user clicks a link or views an image on another site then it will issue a GET request which will be ignored. On another site JavaScript cannot be used to execute a POST request because of SOP (Same-Origin Policy). This means that if the JavaScript executed on site1.example.com then it cannot make a POST request to site2.example.com.
I'm sure that this needs to be cited in some source somewhere. Anybody know of one?
Please correct me if I'm wrong.
Sjbotha (talk) 19:10, 27 November 2007 (UTC)
[edit] CAPTCHAs
CAPTCHAs create major usability issues and depending on the implementation, may still be vulnerable to CSRF attacks using iframes. CAPTCHAs are better at solving other problems, like bots and spam. Hidden form fields are the standard CSRF defense, and very effective assuming the browser is free of vulnerabilities and the site is free of cross-site scripting vulnerabilities. (These assumptions are reasonable because if they were not true, the attacker is unlikely to bother with CSRF as there are much easier attacks.)
Rulesdoc 20:57, 18 October 2006 (UTC)
"A common approach is to include a secret, user-specific token in forms that is verified in addition to the cookie. This approach doesn't save you against the most malicious of attackers, as the attacker can use XMLHttpRequest to grab the one-time token in the background and then stuff it into the POST."
- As written, this is misleading. XHR is subject to the same-domain security model, therefore this particular scenario is only possible in combination with XSS.
[edit] Gmail exploit
Is the Gmail exploit from 1 January 2007 an accurate example of a cross-site request forgery? It doesn't match the description of CSRF from this article (there are no side effects of showing contacts list, the user is not authorizing an action). It doesn't fit neatly into the XSS category either. I'm removing the reference for now but please add it back if I'm mistaken. Rulesdoc 07:14, 2 January 2007 (UTC)
I think it is CSRF, because it's clearly not XSS, and surely theft of a contact list is a side effect. You are right that it doesn't change server state, but I think that like XSS, CSRF has a number of different twists and turns. I've added back in the later paragraphs which had nothing to do with GMail and where about an alternate protection method (double-submit-cookies). Should I add the GMail stuff back in again? JoeWalker 22:48, 2 January 2007 (UTC)
Sorry about reverting away your other edits. I'd like to get some more opinions on the name for the Gmail exploit. It seems like this is an example of exploiting an inadequate JSON authentication scheme, neither CSRF or XSS. Normally in CSRF, you don't have access to the response (and don't need access to it), it's the request that matters -- but for the Gmail exploit, the response is really important. If the contacts list data were in XML instead of JSON, there would be no attack. Rulesdoc 08:19, 5 January 2007 (UTC)
[edit] HTTPS
66.8.130.129, while it's true that HTTPS is a useful tool for web applications, the problems that it solves are orthogonal to CSRF attacks. HTTPS is unnecessary or impossible for many applications (e.g. router web administration tools), yet these are often the apps most vulnerable to CSRF and easily protected by the techniques described in this article. Discussion of HTTPS would be better suited for an article on general best practices for web security. Rulesdoc 21:44, 5 January 2007 (UTC)
[edit] Name Fragmentation / Dilution
I would like to remove the reference to reverse cross-site request, because it's yet another attempt to rename CSRF, and it's based on a fundamental misunderstanding of what CSRF is. If you read the description, the name RCSR is being used to describe the use of a XSS vulnerability to launch a standard CSRF attack. This exact technique has been used for years to exploit XSS vulnerabilities in order to silently steal cookies. (With JavaScript, create an image with a source URL that includes document.cookie in the query string.) It would be nice to remove all alternative names (XSRF, session riding, etc.), because the redirect pages are bad enough (http://simonwillison.net/2005/Jun/6/wikipedia/).
(Update: This change has been made.)
[edit] Prevention by validating referrers?
Couldn't this issue be prevented by validating that the rerrer is from the same site? (i know the referrer can be faked, but you would have to get your victim to do this...)
or what have i misunderstood? —The preceding unsigned comment was added by 217.227.34.233 (talk) 18:57, 23 March 2007 (UTC).
- Forging a victim's headers is possible with Flash: http://webappsec.org/lists/websecurity/archive/2006-07/msg00069.html —The preceding unsigned comment was added by Shiflett (talk • contribs) 13:09, 17 April 2007 (UTC).
In response to the above comment by 217.227.34.233: HTTP_REFERER is a purely optional header, so requiring it to be present by a web application is going to result in false positives for some legitimate users. For example it is sometimes blocked by firewalls as part of a privacy protection policy. --Andrew.urquhart 19:00, 28 June 2007 (UTC)
Referrers get suppressed for all sorts of legitimate reasons (e.g. connections over HTTPS). Why use referrers when hidden fields are known to work reliably? Rulesdoc 00:21, 30 July 2007 (UTC)
[edit] Alice vs. Eve
Isn't the name of the attacker usually Eve and not Alice, like it appears to be in the first couple of paragraphs? Wppds 16:29, 3 April 2007 (UTC)
- See Alice and Bob for standard security archetypes. You are right in that Alice is usually the victim, not attacker. However Eve is typically a passive attacker (observing only). So in this case a different player such as Mallory or Dave may be more appropriate. - Dmeranda 18:43, 3 April 2007 (UTC)
[edit] Browsers restricting content to same IP/Domain
From the article:
It is also suggested that browsers should isolate content on a page to other content from the same IP, or at least the same domain, by default. This would break very little of the web and solve the problem.
I take this comment to task, specifically the "break very little of the web" part: many sites use advertisements served from other IPs and domains. If browsers disabled this, these sites would have to go back to using frames to include ads from an ad server.
I am not saying whether advertisements are good or bad, just that many sites use them and browsers that "isolate content on a page to other content from the same IP or...the same domain" would break more than "very little of the web".
Also, many sites such as blogs don't host blogger provided images...they force the users to use image hosting sites such as Photo Bucket and include an img tag pointing to the outside site.
A better solution (than blocking content from outside sites) would be for the browser to not include cookies on requests to other domains (or IP addresses) while collecting content to display on this page. This stops the sending of the user's identity/authentication to the outside site, without stopping the site the user is visiting from including content from an outside site. Sorry, I don't have a Wikipedia account - Corey 01:14, 3 July 2007 (UTC)
This is starting to sound like original research (see WP:NOR). Wikipedia is not the right place for new ideas about browser redesign to make their initial debut. I've taken the discussion of browser changes out of the main article until there is a citable source for this proposal. Rulesdoc 03:21, 30 July 2007 (UTC)
hihihihi —Preceding unsigned comment added by 210.7.75.133 (talk) 12:39, 18 January 2008 (UTC)
[edit] Semiprotection
See [1]:
We don't need to use TOR we use the IP address of each and every surfer that visit our testpage. You know stumbleupon? good, they just sent me 100K. All I need to do is redirect those stumblers to an iframe embedded form and Wikipedia will be littered with fake edits...
<eleland/talkedits> 18:12, 12 February 2008 (UTC)
[edit] Ajax only?
Article: "An alternate method is to "double submit" cookies. This method only works with Ajax based requests"
Why should that be an Ajax-only feature? The method seems pretty universal. EBusiness (talk) 20:14, 26 May 2008 (UTC)
[edit] Help citing
Hi. Cross-site scripting was tagged "refimprove" in February and recently cited top to bottom and needs only a couple more refs. This article looks easier to do if only because it is shorter. I am not an expert on the topic but unless there are objections am going to try, and if anyone would like to help the more the merrier. I think it is worthwhile and both articles are sources for a W3C Working Group Note which in turn is a reference for this note and work in progress. Apologies in advance if this one also turns into a long series of tiny edits by the way (XSS took about two weeks, twice what I estimated). —SusanLesch (talk) 07:45, 11 June 2008 (UTC)
