Timeline for Do browsers allows pages loaded on one tab to access/intercept/inject data in other tabs?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 25, 2016 at 22:37 | vote | accept | jairo | ||
| Jul 11, 2012 at 16:42 | comment | added | D.W. | @jairo, To answer your question: Yes, that is right. Preventing CSRF is up to the bank website, not up to the browser. (Darth Android's answer is incorrect. The browser cannot stop CSRF. The same-origin policy does not stop CSRF attacks. This is not browser-dependent.) However, CSRF is well-known and I would fully expect that your bank will almost certainly have implemented techniques to prevent CSRF attacks. (While vulnerabilities are always possible, it would be pretty appalling to find a bank that had not applied any defense against CSRF.) | |
| Jul 7, 2012 at 16:08 | comment | added | p____h | Browsers have nothing to do here, 'cos HTTP POST and HTTP GET haven't got SOP restrictions. CSRF depends on WebApps' implementations (pretty common protections are: tokens, checking referrers and so on). | |
| Jul 6, 2012 at 21:40 | comment | added | Darth Android | @jairo No, it depends on the browser. I believe Chrome / Firefox will block such a request because it detects that "mybank.hackersite.com" is trying to send a XmlHTTPRequest to "mybank.com", which is a different domain name (see the "same origin policy" stuff). | |
| Jul 6, 2012 at 19:38 | comment | added | jairo | I've never heard of CSRF before and it sounds like an awfully dangerous vulnerability. Does mitigating CSRF-based attacks depend largely on the implementation of the sessioning system of the website rather than on the user? | |
| Jul 6, 2012 at 16:51 | history | answered | p____h | CC BY-SA 3.0 |