Consider mentioning CSRF validation steps on the server-side about persona

[lloyd]

Why do you need csrf protection here? An audience is embedded in the assertion that is already short lived. What's the exploit here? (apologies in advance for being dense)

[toolness]

I was actually wondering the same thing, but I figured that I just didn't understand the protocol well enough. It does sorta run circles around my head, but that's why I figured a definitive answer should be somewhere in the developer guide (or an FAQ or somesuch).

[lloyd]

@benadida plz hop in and comment here.

If resolution is that there is nO real benefit to csrf here, I'm ok with docing, but would like to tuck it away in a FAQ and the sample code.... In the interest of keeping tutorial tight.

[benadida]

There is actually an attack, specifically a login CSRF attack. Attacker forces victim (in invisible iframe) to log in as the attacker. Victim doesn't notice, enters secret information in web site, attacker can now see the data entered. Details here:

http://seclab.stanford.edu/websec/csrf/csrf.pdf

So in fact I think we do we need to urge CSRF protection at the moment of passing the assertion back to the server. This is non-trivial to describe. Lloyd, you've been writing excellent dev docs, do you want to try here, or should I?

[lloyd]

thanks for that link, @benadida. I'm a tad more sparse now. (OT: It seems like referrer validation should be sufficient to harden our internal wsapi, a hole that's been bothering me, and now seems very simple to plug)

As far as documenting best practices for how the RP should get assertions up, where do you think we ought to doc that? I feel like we need to flesh out myfavoritebeer.org and perhaps have a more thorough manual that describes how to build great browserid support using myfavoritebeer as an example?

(General caution though, we should be graceful as we use browserid as a vector to raise awareness of web security. Like in this specific attack, the user must not realizing who they're logged in as. If you're building a comment system on your blog and using browserid, it might be fine to just show gravatars as the user is putting in comments, and rely on this visual cue to mitigate the attack which has no real bite in this case anyway, your comments appears as if they were mine, muhahahha..)

[benadida]

referrer checking might be sufficient for us because we're only over SSL, but I would still be more comfortable with more systematic CSRF protection in our forms.

As for where we document it, how about we create an advanced security page on browserid.org where we list the various issues, and we point to this one in a single line on developers.html?

[benadida]

added:

https://github.com/mozilla/browserid/wiki/Security-Considerations-when-Implementing-BrowserID

[jbonacci]

Catching up on older, closed issues with the Verified label.