Hi all,
- 10 Security considerations....
- 10.10 Session fixation...
Breno does not feel that session fixation is properly described nor
dealt with.
Breno is right. The threat that shall be prevented here is described
in the security threat document
(http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.4.1.7, enhanced description in https://github.com/tlodderstedt/oauth2/raw/master/draft-lodderstedt-oauth-security.html). Here the attacker obtains a victim's authorization code by redirecting the flow to its own faked website. It then injects this code into his authorization process with the same service provider. This is obviously _not_ the classical session fixation where an attacker sets up a session and tricks the victim in upgrading/enhancing/personalizing this session in order to abuse the victim's privileges. I suggest to change the name of the attack/section to something like "authorization code theft ..." and to add a section about session
fixation.
Igor is providing reference links to session fixation description
(mail to the list).
TODO: [email protected] is working on new draft language.
- 10.13. XSRF/CSRF Prevention
TODO: Breno and Bill M. working on new draft text.
Isn't the countermeasure for both session fixation and XSRF the same
(state)? In my opionion, the difference is:
session fixation: get access to a victim's data in service A using the
attackers account at service B.
XSRF: get access to to a victim's data at a service A using the
attacker's identity with an identity provider
Please not: Mark McGloin is already working on text regarding XSRF.
- 9. Native applications
Objections that this recommends against things that are extant
implementations.
Would you please give examples?
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
