11–20 of 22 posts
* These are submitted with a form (over POST, hopefully) * I don't think that the author implies that using POST prevents CSRFs but the article seems to imply it. In case anyone thinks it is the case: using POST won't prevent a CSRF. Cross Site Request Forgeries occur when a user opens an "evil" page on site B, while being logged on site A. If site A solely relies on cookies in order to identify logged users, there i…
Perhaps I'm just nieve but if someone has access to the DOM via XSS; isn't CSRF nonces like Django uses pointless?
Perhaps I'm just nieve but if someone has access to the DOM via XSS; isn't CSRF nonces like Django uses pointless?
If you have XSS attack vector on your site, the attacker can do almost anything including cookie access(for all cookies that aren't HttpOnly). Also CSRF protection doesn't protect against clickjacking attacks where the page is iframed set transparent and user is encouraged to click in a specific location(punch the monkey in the face) on the attackers page. Easiest solution is to use javascript to detect if your page…
Perhaps I'm just nieve but if someone has access to the DOM via XSS; isn't CSRF nonces like Django uses pointless?
One way to exploit the Victim via XSS would be to convince them to browse to the compromised section of the site. Sometimes, that's as simple as getting them to click on a malformed URL -- basically, the same vector as getting them to click on your CSRF-ized link, anyway.
Many applications, however, don't have direct URLs to certain areas of the app. It could be hidden by Javascript/AJAX population, or written in a language/framework that doesn't support that kind of direct linking.
Therefore, if some kind of sensitive function is easily owned by CSRF (say, account.php?sendto=Eve), but the XSS is stored someplace obscure that might not be available via public URL (browse to Accounts -> Details -> My Bio, which populates dynamically), the higher threat severity would be the CSRF.
Sorry this turned kind of long, but I deal with a lot of webapp security issues on a day-to-day basis and feel relatively qualified to answer this one in some depth :)
This is a decent article, but it's really just another "use your framework to mitigate CSRF" article. There's probably been hundreds of them in the last five years. Useful for junior devs who haven't seen it before; uninteresting for most everyone else.
One thing that's not covered by a lot of frameworks is protecting against CSRF in AJAX requests. Django has some info on enabling this ( https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax ), but it's easy to overlook.