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

Redirect to referer during most CSRF errors #1866

Merged
merged 1 commit into from
Dec 13, 2017

Conversation

monfresh
Copy link
Contributor

@monfresh monfresh commented Dec 12, 2017

Why: Signing the user out and redirecting them to the sign in
page is not helpful when they encounter a CSRF error. For example,
if they get a CSRF error while creating their password for the first
time during account creation, they might not know what they should
do to get back to the password creation screen.

Instead, we should try to redirect back to where they were so they can
try again. One exception is on the personal key screen. Due to the way
the feature works, we can't take the user back to the personal key
screen without modifying the session and regenerating a new key for
them. We don't want to make any state changes as a result of a CSRF
error for security reasons. Instead, we sign them out and redirect
to the sign in screen.

Users::SessionsController also has its own way of rescuing the
CSRF error because the only way I could get the flash message to
appear was to call sign_out, and we don't want to call sign_out
in ApplicationController. Also, in order to preserve the request_id
(so that users can go back to the SP), we need to use redirect_back,
whereas in the Personal Keys controllers, we don't want to redirect
back.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

  • For DB changes, check for missing indexes, check to see if the changes
    affect other apps (such as the dashboard), make sure the DB columns in the
    various environments are properly populated, coordinate with devops, plan
    migrations in separate steps.

  • For route changes, make sure GET requests don't change state or result in
    destructive behavior. GET requests should only result in information being
    read, not written.

  • For encryption changes, make sure it is compatible with data that was
    encrypted with the old code.

  • Do not disable Rubocop or Reek offenses unless you are absolutely sure
    they are false positives. If you're not sure how to fix the offense, please
    ask a teammate.

  • When reading data, write tests for nil values, empty strings,
    and invalid formats.

  • When calling redirect_to in a controller, use _url, not _path.

  • When adding user data to the session, use the user_session helper
    instead of the session helper so the data does not persist beyond the user's
    session.

@monfresh
Copy link
Contributor Author

Using the table in the CSRF documentation I wrote, I verified this works as expected for all LOA1 screens.

Copy link
Contributor

@tbaxter-18f tbaxter-18f left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A second set of eyes wouldn't hurt, but LGTM

@monfresh monfresh force-pushed the mb-preserve-request-id-after-csrf-error branch from 535d066 to d399e7f Compare December 13, 2017 02:51
**Why**: Signing the user out and redirecting them to the sign in
page is not helpful when they encounter a CSRF error. For example,
if they get a CSRF error while creating their password for the first
time during account creation, they might not know what they should
do to get back to the password creation screen.

Instead, we should try to redirect back to where they were so they can
try again. One exception is on the personal key screen. Due to the way
the feature works, we can't take the user back to the personal key
screen without modifying the session and regenerating a new key for
them. We don't want to make any state changes as a result of a CSRF
error for security reasons. Instead, we sign them out and redirect
to the sign in screen.

`Users::SessionsController` also has its own way of rescuing the
CSRF error because the only way I could get the flash message to
appear was to call `sign_out`, and we don't want to call `sign_out`
in `ApplicationController`. Also, in order to preserve the `request_id`
(so that users can go back to the SP), we need to use `redirect_back`,
whereas in the Personal Keys controllers, we don't want to redirect
back.

This PR also enables the Devise `unauthenticated` error message in
the scenario where a user tries to access a page that requires
authentication while the user is signed out. We capture that flash
message in analytics in order to see whether most people are getting
CSRF errors while signed in or if they try to submit a form after
their session has timed out or somehow got dropped by the browser.
@monfresh monfresh force-pushed the mb-preserve-request-id-after-csrf-error branch from d399e7f to 0546d55 Compare December 13, 2017 03:24
@monfresh monfresh merged commit a4c3426 into master Dec 13, 2017
@monfresh monfresh deleted the mb-preserve-request-id-after-csrf-error branch December 13, 2017 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants