3 ms·
[related] This year at CCS conference: San-Tsai Sun and Konstantin Beznosov, The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Sy
by ecesena 14y ago
[related] This year at CCS conference:
San-Tsai Sun and Konstantin Beznosov, The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems
http://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf http://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf
- peter_l_downs 14y agoThanks for posting this! Great overview of potential implementation flaws. From the article: In some RPs, access tokens are appended as query parameters to the RP's sign-in endpoint (i.e., the URI that issues the authenticated session cookie), which reveals the tokens in the browser's history and server logs. The official spec only supports including the access token in a URL-encoded body of a POST request, or as part of an Authorization header [0]. This is one of the biggest differences between the official spec and most current (not up to spec) implementations. Also disappointing^H^H^H^H^H^H^H^H^H^H^H^H^H interesting: Surprisingly, our evaluation shows that only 21% of RPs em- ploy SSL to protect SSO sessions, even though about half of tested RPs have protected their traditional login forms with SSL. The relevant part of the specifcation [1]: Always use TLS (https): Clients MUST always use TLS [RFC5246] (https) or equivalent transport security when making requests with bearer tokens. Failing to do so exposes the token to numerous attacks that could give attackers unintended access. [0]: http://tools.ietf.org/html/rfc6750#section-2 http://tools.ietf.org/html/rfc6750#section-2 [1]: http://tools.ietf.org/html/rfc6750#section-5.3 http://tools.ietf.org/html/rfc6750#section-5.3