Tenuto conto di questo:
codice:
1. The attacker must target either a site that doesn't check the referrer header (which is common) or a victim with a browser or plugin bug that allows referrer spoofing (which is rare).
2. The attacker must find a form submission at the target site, or a URL that has side effects, that does something (e.g., transfers money, or changes the victim's e-mail address or password).
3. The attacker must determine the right values for all the form's or URL's inputs; if any of them are required to be secret authentication values or IDs that the attacker can't guess, the attack will fail.
4. The attacker must lure the victim to a Web page with malicious code while the victim is logged in to the target site.
e di questo
codice:
* Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions
* Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc)
* Limiting the lifetime of session cookies
* Checking the HTTP Referer header
* Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls
* Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies
* Verifying that the request's header contains a X-Requested-With. Used by Ruby on Rails (before v2.0) and Django (before v1.2.5). This protection has been proven unsecure under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allow a forged requests.
direi che verificare il referer e limitare la vita dei cookie possa bastare, soprattutto per siti amatoriali o quasi.
Permessi di invio
Rispondi quotando