csrfmiddlewaretoken confuses Launchpad

Bug #608920 reported by Benji York
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical SSO provider
Fix Released
Medium
David Owen

Bug Description

The production OpenID provider appears to have the Django cross site
request forgery (XSRF) protection middleware enabled which interacts
poorly with Launchpad's OpenID client.

The middleware generates a token (csrfmiddlewaretoken) used to prevent
XSRF attacks and inserts it into every form. Unfortunately that
includes the form that is generated when the OpenID return_to URL is
longer than some browsers can handle (e.g., when attempting to long in
from this page:
https://bugs.edge.launchpad.net/firefox/+bugs?field.searchtext=foo&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.importance%3Alist=UNKNOWN&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&field.importance%3Alist=LOW&field.importance%3Alist=UNDECIDED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on).

Since the Launchpad OpenID client verifies that no form values have been
injected as a security precaution, the behavior prevents logging-in in
on pages with very long URLs (see bug 597324).

As a short-term work-around, Launchpad is ignoring the
csrfmiddlewaretoken field when verifying the OpenID response.

The XSRF protection can be disabled on a per-page basis using the
@csrf_exempt decorator (see http://docs.djangoproject.com/en/1.2/ref/contrib/csrf/#exceptions
for details).

Related branches

Revision history for this message
David Owen (dsowen) wrote :

Thanks for the report!

The view is overloaded, so a decorator won't work. We'll have to set the property on the response directly. server.py:508, where we set content-type for openid post responses, looks like the right place.

Because the view is overloaded, we'll need to add some additional automated tests to make sure we don't lose CSRF protection on the other aspects.

Changed in canonical-identity-provider:
milestone: none → 2.8.0
Julien Funk (jaboing)
Changed in canonical-isd-qa:
milestone: none → canonical-identity-provider+2.8.0
Changed in canonical-identity-provider:
importance: Undecided → Medium
status: New → Triaged
Julien Funk (jaboing)
Changed in canonical-isd-qa:
importance: Undecided → Medium
David Owen (dsowen)
Changed in canonical-identity-provider:
assignee: nobody → David Owen (dsowen)
status: Triaged → In Progress
David Owen (dsowen)
Changed in canonical-identity-provider:
status: In Progress → Fix Committed
Revision history for this message
David Owen (dsowen) wrote :

To test, use Firefox with FireBug installed.

1. Disabled JavaScript
2. Make sure to log out of SSO
3. Go to the test consumer
4. Click "Begin"

You should stop at a page with a single button and no styling.

5. Using FireBug, locate the hidden parameter named "openid.return_to", and add the text "&aaaaaaaa..." (thousands of As) to the end of its value.
6. Click "Continue"
7. Sign in to SSO

If you added enough As in step 5, you will be at another form, "Continue to 3rd-party site" styled in SSO's fashion.

Correct behavior is that this form will not have the CSRF token in it. You may verify this by manually inspecting the form to ensure its absence.

Also, you may submit the form. Because SSO assumes this submits to a 3rd-party site, but the testconsumer is actually local and expects CSRF protection, you will receive a stale page error if the CSRF token is correctly missing.

Dave Morley (davmor2)
Changed in canonical-isd-qa:
status: New → Fix Committed
status: Fix Committed → Confirmed
assignee: nobody → Dave Morley (davmor2)
Revision history for this message
Julien Funk (jaboing) wrote :

Pass in Staging.

Changed in canonical-isd-qa:
status: Confirmed → Fix Committed
Revision history for this message
Dave Morley (davmor2) wrote :

Is there a way to test this for real on production

Changed in canonical-isd-qa:
status: Fix Committed → Incomplete
Revision history for this message
Dave Morley (davmor2) wrote :

Following the link from the top of the bug I have an issue in that I go to the LP bug page, I click on Login, I run through the LP SSO login process and am then given the option to be redirected back to the 3rd party site.

The 3rd party site is the LP Bug page I just left, this isn't a 3rd party site at all to a user it's the same site. This may cause them to not click on continue as what is this mythical 3rd party site they are being redirected to?

From a chat on IRC:
<davmor2> stuartm: I got an issue now with https://bugs.launchpad.net/canonical-identity-provider/+bug/608920 I'm logging into LP from LP SSO so how is LP a 3rd-party site? I think it might make users unsure if they should click on the Continue button.

<davmor2> it does at least work the way it's meant too

<stuartm> davmor2: hmm. we could probably be a bit less specific about that. in fact we could have a plain page and use js to submit the form (that's done elsewhere in openid)

Revision history for this message
Dave Morley (davmor2) wrote :

The issue above is now forwarded to bug 632536. I am leaving the QA as incomplete as there needs to be a QA trail to the new bug created.

The developer status can be set to fix released.

David Owen (dsowen)
Changed in canonical-identity-provider:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.