RFC-5849: CSRF and UI Redress

[TheRook]

1)Cross-Site Request Forgery:
In "RFC-5849 4.13. Cross-Site Request Forgery (CSRF)" (http://tools.ietf.org/html/rfc5849#section-4.13) it states that a Cross-Site Request Forgery cannot be used to initiate an OAuth negotiation.

This attack could be triggered an a hidden iframe which triggers the following GET request:

<iframe src=http://engineauth.scotchmedia.com/auth/google />

If the google oauth user account has already been used to authenticate then the browser will automatically authenticate with engineauth.scotchmedia.com. At this point an attacker could deliver an XSS, CSRF or Clickjacking exploit to an authenticated website.

To mitigate this issue a synchronization token should be present within the OAuth login request.

More Information on preventing CSRF:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

2. UI Redress:
   The example application running at engineauth.scotchmedia.com is vulnerable to UI Redress. In "RFC-5849 section 4.14. - User Interface Redress" it stats that the buttons used to initiate the OAuth negotiation need to be protected against Clickjacking attacks.

This vulnerability can be mitigated by setting the "x-frame-options: sameorigin" HTTP header.

More Information on preventing clickjacking:
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

[TheRook]

Currently the state variable is a static string: state=http%3A%2F%2Flocalhost%3A8080%2Fauth%2Fgoogle

https://accounts.google.com/o/oauth2/auth?state=http%3A%2F%2Flocalhost%3A8080%2Fauth%2Fgoogle&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fauth%2Fgoogle%2Fcallback&response_type=code&client_id=673072897993.apps.googleusercontent.com&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fplus.me&access_type=offline

This variable should be (or contain) a CSRF token:
https://developers.google.com/accounts/docs/OAuth2Login#createxsrftoken