Content deleted Content added
Remove outdated information, which is not supported by the referenced sources or by any other reliable source Tags: references removed Visual edit |
GreenC bot (talk | contribs) Rescued 1 archive link. Wayback Medic 2.5 per WP:URLREQ#voices.washingtonpost.com |
||
| (15 intermediate revisions by 14 users not shown) | |||
Line 70:
==Other approaches to CSRF==
Additionally, while typically described as a static type of attack, CSRF can also be dynamically constructed as part of a payload for a [[cross-site scripting]] attack, as demonstrated by the [[Samy (XSS)|Samy]] worm, or constructed on the fly from session information leaked via offsite content and sent to a target as a malicious URL. CSRF tokens could also be sent to a client by an attacker due to [[session fixation]] or other vulnerabilities, or guessed via a brute-force attack, rendered on a malicious page that generates thousands of failed requests. The attack class of "Dynamic CSRF", or using a per-client payload for session-specific forgery, was described<ref>{{cite web|url=http://voices.washingtonpost.com/securityfix/2009/07/weaponizing_web_20.html
|archive-url=https://web.archive.org/web/20120528063619/http://voices.washingtonpost.com/securityfix/2009/07/weaponizing_web_20.html
|url-status=dead
|archive-date=May 28, 2012
|title=Security Fix - Weaponizing Web 2.0}}</ref> in 2009 by Nathan Hamiel and Shawn Moyer at the BlackHat Briefings,<ref>[http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ Dynamic CSRF] {{webarchive|url=https://web.archive.org/web/20100213160456/http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ |date=2010-02-13 }}</ref> though the taxonomy has yet to gain wider adoption.
Line 94 ⟶ 97:
===Synchronizer token pattern===
[[Synchronizer token pattern]] (STP) is a technique where a token, a secret and unique value for each request, is embedded by the web application in all HTML forms and verified on the server side. The token may be generated by any method that ensures unpredictability and uniqueness (e.g. using a [[hash chain]] of random seed). This is called a anti-forgery token in ASP.NET. The attacker is thus unable to place a correct token in their requests to authenticate them.<ref name=Shiflett /><ref name="owasp">{{cite web | url=https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html | title=Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet | publisher=OWASP | access-date=2019-07-19}}</ref><ref name=Valhalla>{{cite web|url=http://halls-of-valhalla.org/beta/articles/cross-site-request-forgery-demystified,47/|title=Valhalla Articles - Cross-Site Request Forgery: Demystified}}</ref>
Example of STP set by [[Django (web framework)|Django]] in a HTML form:
Line 180 ⟶ 183:
{{DEFAULTSORT:Cross-Site Request Forgery}}
[[Category:Web security exploits]]
[[Category:Client-side web security exploits]]
| |||