4 ms·

Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :). As to XSS, the

Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :). As to XSS, the assertion that's transmitted to a site is scoped to that specific site, and is only valid for, iirc, 2 minutes. So replay attacks are severely constrained. Plus, the only meaningful data they contain is the user's email address, so phishing doesn't get you much of value or put the user at risk.

zaroth 14y ago
So that's a 'yes' this exposes authentication to XSS, albeit the attacker will have to hijack sessions in real-time as the assertions are forwarded to their server. That's a huge step backwards in web security. Why pass the assertion to the RP via the most insecure channel possible, i.e. the client-side javascript? That was just the easiest way you could find so the RP could tie it to client's session id?! Obviously the assertion must be sent from the browser plugin directly to the RP. You could do it by injecting an HttpOnly cookie for the RP's domain with the encoded assertion. Javascript can never see it. In the case of a secondary, the secondary already has an HttpOnly session id with the end user, since they're authenticated in the first place. The secondary would post the assertion back to the RP directly at a well known URL, and the RP returns a URL to the secondary with a nonce built in. The secondary redirects the end-user to that nonce URL so the RP can give them an HttpOnly authenticated session id. I think you can do this in a way such that neither the assertion nor the nonce will be visible to client javascript. Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.

4 ms·

Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :). As to XSS, the

by callahad 14y ago

zaroth 14y ago
So that's a 'yes' this exposes authentication to XSS, albeit the attacker will have to hijack sessions in real-time as the assertions are forwarded to their server. That's a huge step backwards in web security. Why pass the assertion to the RP via the most insecure channel possible, i.e. the client-side javascript? That was just the easiest way you could find so the RP could tie it to client's session id?! Obviously the assertion must be sent from the browser plugin directly to the RP. You could do it by injecting an HttpOnly cookie for the RP's domain with the encoded assertion. Javascript can never see it. In the case of a secondary, the secondary already has an HttpOnly session id with the end user, since they're authenticated in the first place. The secondary would post the assertion back to the RP directly at a well known URL, and the RP returns a URL to the secondary with a nonce built in. The secondary redirects the end-user to that nonce URL so the RP can give them an HttpOnly authenticated session id. I think you can do this in a way such that neither the assertion nor the nonce will be visible to client javascript. Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.