CSRF Tool
homakov.blogspot.ru
CSRF Tool
1–10 of 30 posts
Re: CSRF Tool
#2Your mitigation is wrong. You need a one way function around the cookie, otherwise that can be forged too.
Re: CSRF Tool
#3Your mitigation is wrong. You need a one way function around the cookie, otherwise that can be forged too.
If a blind attacker can't predict the token, and the token is reliably checked on form submission, it mitigates CSRF.
Re: CSRF Tool
#4checking referer will work 99% and without cluttering your urls.
Re: CSRF Tool
#5checking referer will work 99% and without cluttering your urls.
>However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check.
https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...
Re: CSRF Tool
#6checking referer will work 99% and without cluttering your urls.
>However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...
Not to mention one can leverage flash to spoof headers or the odd IE bug that splits headers using \t
Re: CSRF Tool
#7Extra points for incorporating a rap video into a technical security blog post.
Re: CSRF Tool
#8Maybe you should do something other than alert() the CSRF exploit, I can't copy it under Windows
Re: CSRF Tool
#9checking referer will work 99% and without cluttering your urls.
Please stop relying on the Referer header. It can be forged and is often enough removed completely for privacy reasons.
Re: CSRF Tool
#10Hmmmm, while I'm a big fan of the OP I don't think this is really a security flaw.
I'm praying to God that Facebook doesn't use CSRF as their only stop gap measure against malicious POST requests, and if that were the case then OP might have a point, but in my opinion CSRF is more of a buffer that helps prevent scale-able automated form submissions.
If I understand it correctly, OP demonstrates that a simple curl can get a CSRF token that can then be used to send malicious POST requests, but isn't that almost the same thing as loading up the webpage and typing in the data in the form yourself? I feel like you're still throttling the requests, as HTTP requests before every POST does not scale. This could also be very easily detected server side and easily blocked.
Am I understanding this correctly?