Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for out-of-band xsrf tokens #1506

Closed
wants to merge 1 commit into from
Closed

Conversation

whardier
Copy link

There have become several situations where control for something that will inevitably come back as a callback (via POST) will not include the proper CSRF token... however the callback URI can (and should) be adorned with one.

Examples are using oneall's social login service which requires a callback for extra processing. Decorating the CSRF requirements away does not help protect against unmanageable situations.

An unmanagable situation would be where we all assume a service will be using security reasoning when developing a project. Oneall.com uses pseudo random UUIDs when passing an important bit of information back to a callback. If they ever switch to incremental or predictable hashes (due to a mistake on their end or perhaps a bad decision) an exploit can occur that requiring the csrf token could help mitigate. In this case the token would have to be passed via GET parameters.

This can be extended to OAUTH behaviors as well.

There are a lot of other services.. including mail outs.. that use callbacks for send notifications that could be adorned with a token as well.

There have become several situations where control for something that will inevitably come back as a callback (via POST) will not include the proper CSRF token... however the callback URI can (and should) be adorned with one.

Examples are using oneall's social login service which requires a callback for extra processing.  Decorating the CSRF requirements away does not help protect against unmanageable situations.

An unmanagable situation would be where we all assume a service will be using security reasoning when developing a project.  Oneall.com uses pseudo random UUIDs when passing an important bit of information back to a callback.  If they ever switch to incremental or predictable hashes (due to a mistake on their end or perhaps a bad decision) an exploit can occur that requiring the csrf token could help mitigate.  In this case the token would have to be passed via GET parameters.

This can be extended to OAUTH behaviors as well.

There are a lot of other services.. including mail outs.. that use callbacks for send notifications that could be adorned with a token as well.
@timgraham
Copy link
Member

I'm not a security expert to make a decision on this, but this will need an accepted Trac ticket as well as a test in order to be committed, thanks.

@whardier
Copy link
Author

I've no need to push it other than trying to spread the good word of making
this available.

On Thu, Aug 22, 2013 at 10:24 AM, Tim Graham notifications@github.comwrote:

I'm not a security expert to make a decision on this, but this will need
an accepted Trac ticket as well as a test in order to be committed, thanks.


Reply to this email directly or view it on GitHubhttps://github.com//pull/1506#issuecomment-23113760
.

@apollo13 apollo13 closed this Aug 24, 2013
@apollo13
Copy link
Member

As tim said, no ticket no joy…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants