News for hackers. Stuff that matters.
Re:Show HN: This up votes itself by olalonde on Thursday March 22, 2012 @08:51PM (#3742955)
Someone in the other thread pointed out it at least checked the referrer header.
Re:Show HN: This up votes itself by simonw on Thursday March 22, 2012 @08:59PM (#3742983)
That's not a good enough solution - there are decent reasons that a referrer header might be missing (some PC antivirus software strips out referrer headers for example). The only safe way to handle this is with a POST request protected by a CSRF token tied to a cookie.
Re:Show HN: This up votes itself by hashbo on Thursday March 22, 2012 @09:22PM (#3743090)
+1 You can’t trust the Referer header.
Re:Show HN: This up votes itself by jpablo on Thursday March 22, 2012 @09:56PM (#3743222)
GET with randomized ids and checking referrer should be good enough to keeps things simple.
Re:Show HN: This up votes itself by ben0x539 on Thursday March 22, 2012 @09:27PM (#3743100)
Really? I block the referer header so I guess all my upvotes haven't been counted. :(
Re:Show HN: This up votes itself by danielrm26 on Thursday March 22, 2012 @10:08PM (#3743253)
The referer header is also controlled by the client. Anything controlled by the client should be considered tainted.
Re:Show HN: This up votes itself by jbri on Thursday March 22, 2012 @10:26PM (#3743299)
This doesn't really apply when you are trying to verify whether the client actually performed some action.

In a CSRF scenario, the client itself can presumably be "trusted" - A client behaving maliciously can only hurt itself, not any one else. The important thing is to not trust anything that may have been provided by a third party.