CSRF

[elima]

For CSFR, the simplest and most effective solution is to design the server API so that HTTP GET requests are unable to change any state server-side, only retrieve content. Most of the attack surfaces of CSFR can be reduced or completely removed this way.

[wingo]

So yes totes, GET should have no effect. There is still the question whether GET could leak useful information to an attacker on a third-party site; like could you get the dimensions of the image somehow if the attacker did <img src=https://omafano.net/photos/secret-photo> ? Would that allow the attacker to know that you have access to that photo? What are the implications?

However for POST we do need something. Third-party code can POST to your site via JS, so it's definitely an attack surface. I augmented the security doc to mention the solution though: Referer checking. It's nasty but it does work. Perhaps we should do the same for .jpg requests so that <img src> doesn't work. WDYT there? Maybe only for photos not shared with the global cap? Some amount of external image embedding is fine, seems to me...

[wingo]

it's like impossible to spell csrf

[elima]

Since the security document separates the XSS case from the CSRF, I understood that POST requests are not considered as part of the CSRF attack surface. Tricking a browser to submit a non-GET request without scripting is... well, tricky :). So unless we treat CSRF as a sub-problem of XSS, we are left with this kind of attacks (from CSRF Wikipedia page)

    Mallory: Hello Alice! Look here:

       <img src="http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Mallory">

Mallory can send such links via e-mail or IM. Forging a POST request would be more difficult. But yes, I think we should treat XSS and CSRF as part of the same attack vector.

About using the Referer header, I think it is premature to make judgement until the API exposed by Omafano is better defined. We must consider that, even though it will protect against attackers using compliant user-agents, attackers using non-browser clients could bypass the check at exploit the API at will.

At the same time, third-party embedding of images is a desirable feature, as it is probably allowing full featured third-party clients of Omafano in the future.

A priori, using the Referer seems like a weak solution to me. Also, if the only purpose is to protect against XSS attacks coming from good-behaving user-agents, CORS seems like a better solution. CORS requires that the server application cooperates (by returning specific headers) when the origins mismatch.

[elima]

There is also this: Mozilla tweaks “referer headers” in bid to limit website privacy grabs, which could reduce the effectiveness of using the Referer header.