Talk:Cross-site request forgery

message: Hey guys. In 2008 I published a technical report describing CSRF vulnerabilities in four popular sites (ING Direct, YouTube, The NYTimes and Metafilter). The ING Direct attack was particularly interesting because it allowed money to be transferred out of a bank account using a pure CSRF attack (which is the first such attack of which I'm aware). This CSRF article is strong as-is, but might be stronger if the main example (which uses a bank) were a real example and not a toy example. Regardless, I felt uncomfortable changing the text of the article to include content I've written, so I've decided to simply point to the paper and blog post here--use it as you wish. 
- Bill Zeller  —Preceding unsigned comment added by 24.215.164.121 (talk) 03:11, 25 May 2010 (UTC)
thread_title:  High-Impact CSRF Examples 

message: "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)
replies: text: "On another site JavaScript cannot be used to execute a POST request because of SOP (Same-Origin Policy)."  That statement is wrong.  Javascript can be used to submit a form which POSTs to another site and it is trivial to do so.  It can even be done without Javascript, by tricking the user into clicking on something.  This is not what the same origin policy covers. See also NeilFraser's comment above.  210.84.45.67 (talk) 03:02, 15 November 2008 (UTC)
thread_title:  GET vs POST 

message: 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)
thread_title:  Gmail exploit 

message: 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)
thread_title:  HTTPS 

message: 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)
replies: text: 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)

text: I'd like to question this statement as well. Referer checking is a terrible defense at best unless you're going to block requests with no referer as well which would break a very significant number of legitimate clients. The only practical and meaningful answer is to actually fix it on your side with a secret token or re-prompt for credentials for every meaningful action. Anyone object to removing this limitation line?  — Preceding unsigned comment added by 199.106.103.249 (talk) 23:00, 1 July 2011 (UTC)

text: If this statement is kept, it should be modified to clarify whether it's common for the attacker to target a site or for a site to not check the "Referrer" header. Same goes for clarifying what is rare in the second part of the sentence. Rdfiasco (talk) 20:06, 22 May 2013 (UTC)
thread_title:  Prevention by validating referrers? 

message: 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)
replies: text: 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)
thread_title:  Alice vs. Eve 

message: 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)
thread_title:  Browsers restricting content to same IP/Domain 

message: See :
<Blockquote>
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...
</Blockquote>
<eleland/talkedits> 18:12, 12 February 2008 (UTC)
thread_title:  Semiprotection 

message: 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)
replies: text: It's not Ajax-only; there are other ways to implement it. It's just most often used for Ajax, since the synchronizer token pattern doesn't really work for Ajax requests. I've set up a server-side filter before that would generate a token, setting it in a response cookie and inserting it into the page HTML. Carl.antuar (talk) 02:01, 3 March 2016 (UTC)
thread_title:  Ajax only? 

message: 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)
thread_title:  Help citing 

message: Hi. In case anyone needs them here's the list of external links.  OK from my point of view to restore them. —SusanLesch (talk) 19:26, 3 July 2008 (UTC)
thread_title:  External links 

message: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/X1GdZ11zk78/article.pl
Might be worth a read. Shinobu (talk) 12:12, 30 September 2008 (UTC)
thread_title:  Today on Slashdot 

message: The footnote for the phrase "known and in some cases exploited since the 1990s" mentions no attacks prior to 2005. The phrase was coined in 2001 (http://www.tux.org/~peterw/csrf.txt. http://seclists.org/bugtraq/2001/Jun/0217.html, etc.), so I don't see how that footnote supports the contention that CSRF was known and exploited since the 1990s. Sure, the problem has been around since the 1990s, but I'm not aware of anyone recognizing it before 2001.  —Preceding unsigned comment added by 206.112.178.116 (talk) 13:45, 30 September 2008 (UTC)
thread_title:  "known ... since the 1990s"? 

message: It is said, that including a secret in every form is a method that PREVENTS the attack. I'm not sure about that. The method is perfectly clear to me. Foreign pages generate the malicious request, which sends the cookie in the request header, but they don't have access to the secret. The secret string method uses the assumption that only the original pages generated by the server have access to the secret. BUT, it is enough, that there is a single page accessible without a secret, leading to the action being protected, for the security to be breached. Provided JavaScript is enabled, an attacker can load the page to an iframe and then submit consequential forms, all having the secret in them, which would lead the attacker to the action being protected.
Example:
1. Attacker loads www.server.com/page1.php to a hidden iframe. [with the GET method]
2. The page contains a form WITH THE SECRET, that can be submitted to the server.
Step 2 can be reiterated to go through all the secret-protected forms.
I'd appreciate a correction if I am mistaken. If I'm not, however, it might be a good idea to indicate this behavior on the page.
Wadim.grasza (talk) 17:45, 21 October 2008 (UTC)
replies: text: I think the attacker can load the form into a hidden iframe, but cannot do anything to submit the form.  Javascript on the attacker's page can't access any content inside the iframe because it was sourced from a different domain, so it can't read anything in that iframe, or take any action on form controls in that iframe, due to same origin policy.  The attacker would be limited to loading it in an iframe and hoping that the victim accidentally clicks in the iframe himself.  210.84.45.67 (talk) 03:14, 15 November 2008 (UTC)

text: As I understand it, the attacker would be able to submit the form in the IFRAME, but would not be able to populate it first; it would be blank. So if there is proper form validation, then there shouldn't be any issue.Carl.antuar (talk) 02:38, 27 July 2015 (UTC)
thread_title:  What about this? 

message: I have been trying to grok CSRF for a while now; the first time I tried to learn it from this page, I failed. Somebody just explained it to me, so I went back to check whether his explanation agrees with this article. It does, but the article is too brief. It suffers from the "we omit the subscript when it's clear" problem, for me. I hope to elaborate the Example and Prevention sections to be clear about which parties with which motivations take which actions.
See also How to evaluate Web Applications security designs? written in preparation for a meeting next week. DanConnolly (talk) 16:36, 5 December 2008 (UTC)
thread_title:  Example and Prevention merit elaboration 

message: I use Firefox bundled with NoScript and CookieSafe to do general browsing and Galeon to do my banking - note that Galeon is configured to go through a proxy (Squid) that allows only a limited number of trusted sites to be accessed (allow list) - when I'm done banking I close the browser. Since CSRF risk is high and there is little we can do right now, I prefer this approach just to be on the safe side.  —Preceding unsigned comment added by 154.5.47.33 (talk) 16:18, 30 June 2009 (UTC)
thread_title:  Use different browsers 

message: For platform websites that allow user-submitted content (including javascript) to be embedded on the page (such as user-submitted comments), a request forgery may be intra-site.  Many of the techniques discussed under "Prevention" rely on cross-domain browser security, so those prevention techniques arent sufficient for platform sites.
For platform sites, the "secret user-specific token" has to stay secret from the browser. So the value that is sent to the browser needs to be hashed with a value unique to the form (for instance, the target url of the form).  Allowing user-submitted javascript on the same page as a sensitive form will potentially expose that form to attack... but using this technique vastly limits the platform's exposure.  —Preceding unsigned comment added by 216.16.251.150 (talk) 17:44, 23 April 2010 (UTC)
thread_title:  Intra-site request forgery 

message: This is now called XSSI. See Talk:JavaScript#.22Javascript_hijacking.22  — Preceding unsigned comment added by Tychay (talk • contribs) 21:56, 16 May 2012 (UTC)
thread_title:  "Javascript hijacking" 

message: In the "Background" section, the following is used as an example of a CSRF:
"Customers of a bank in Mexico were attacked in early 2008 with an image tag in email. The link in the image tag changed the DNS entry for the bank in their ADSL router to point to a malicious website impersonating the bank."
This is in fact not a CSRF attack, but a DNS cache poisoning attack. I didn't want to outright delete a cited "example," but this should probably be taken out and replaced with a correct and more detailed example.
Alternatively, it's possible that the malicious website which was injected into the DNS cache may have used a CSRF attack by forwarding users' credentials to the real site when they "log in" on the fake one, then submitting a malicious request once users were known to be logged in for real. If this is the case, this aspect of the attack should be made more clear. Right now the entry is confusing and unrelated to the topic.  — Preceding unsigned comment added by 184.74.161.61 (talk) 14:43, 21 June 2012 (UTC)
thread_title:  Incorrect Example 

message: On 11 September 2012‎, Hydrox has changed
"Verifying that the request's header contains a X-Requested-With […] has been proven unsecure"
to
"Verifying that the request's header contains a X-Requested-With or checking the HTTP Referer header and/or HTTP Origin […] has been proven unsecure"
But i don't see in the 2 links provided where the Origin header is mentioned. And other good sites on security like https://code.google.com/p/browsersec/wiki/Part3#Origin_headers and https://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity doesn't say anything about a Origin header spoofing.
Is there a real source to substantiate this claim ? Or is it infered from the sentence of the django blog "can allow an attacker to provide custom HTTP headers on a request to any website". Is this case, it depends how you define "custom". Is it "you can customize all http headers" or "you can add a custom http header", meaning headers not handled by the browsers like all the X-... (X-Requested-With).
Both interpretations make sense to me.  — Preceding unsigned comment added by Acoudeyras (talk • contribs) 15:42, 2 October 2013 (UTC)
thread_title:  Origin header safety 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Cross-site request forgery. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20141222202044/http://jfoulds.com/blog/passive-monitoring-login-request-forgery/ to http://www.jfoulds.com/blog/passive-monitoring-login-request-forgery/
*Added archive https://web.archive.org/web/20100213160456/http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ to http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 20:44, 14 August 2017 (UTC)
thread_title:  External links modified 

message: I'm not clear, from reading this article, if CSRF is an issue with a non-browser based RESTful service. With a browser, a _csrf token can be submitted in a web form, but with a RESTful service, there's no browser. It's not clear if this means a _csrf token won't help, or if it won't be necessary. Is CSRF still a problem with a non-browser based service? The article should address this issue. —MiguelMunoz (talk) 17:28, 7 January 2021 (UTC)
thread_title:  CSRF and REST without a browser 

message: SOK NA SAD 36.37.142.102 (talk) 20:44, 22 January 2024 (UTC)
thread_title:  ស្តេច សេដ