Recommendations for redirecting GET requests to login page?

[TastyPi]

When a logged out user tries to access a page that requires being logged in we would like to redirect the user to the log in page automatically. It is not clear to me what would be the best way to achieve this while avoiding https://github.com/omniauth/omniauth/wiki/Resolving-CVE-2015-9284.

Currently we are using the repost gem to simulate a redirect to POST by returning a simple form from the GET request that gets automatically submitted using JavaScript. Is there a better way to do this?

A best practice recommendation for how this situation should be resolved would be appreciated.

[BobbyMcWho]

Follow the rails setup, you create a sessions controller and redirect them to the sessions#new action

https://github.com/omniauth/omniauth#rails-without-devise

[TastyPi]

Ah, this problem is then specific to using omniauth-auth0 as we don't create a sessions#new action for that, Auth0 provides the login page. POST /auth/auth0 redirects to the Auth0 page, but we want to be able to redirect to the Auth0 page from a GET request. Ideally we would be able to reuse the code that generates the appropriate Auth0 URL to accomplish what we want, but that's not trivial according to the omniauth-auth0 maintainers auth0/omniauth-auth0#159.

Is there a way we can get omniauth to generate the Auth0 URL we want without having problems with the CVE?

[BobbyMcWho]

If you don't want to use repost (which using feels like defeating the point), you must redirect to a controller you own, render a form (that says something like "click to continue to auth0", that then posts to /auth/auth0.

Unfortunately that CVE, while complicated to execute, is a real threat if you leave your /auth/:provider route open to GET requests, you want to have manual user intervention to acknowledge they're logging in.

In a perfect storm, where a user is under attack and the user's 3rd party auth session has already been claimed by the attacker (using an account the attacker owns), if you plain GET request (can be triggered by something as simple as an tag), the user's account on your site can be transparently linked to the attacker's OAuth account

[TastyPi]

That clarifies a lot of things for me! I assumed using a GET redirect to go to the 3rd party's login page didn't matter since the "important" stuff happens on their page, but I hadn't considered the situation where an attacker has injected their own 3rd party auth session (maybe I should have researched the CVE more). Using POST provides stronger protection against cross-site forgery, so even if the attacker has compromised the 3rd party auth session they still need to get the user to click a link for the site.

I think we'll stick to repost for now, I'm not convinced making the user click a log in button would make a difference for our site, but I'll definitely consider adding that interstitial form in the future.