Comply with OAuth v1.0 (the RFC, not the original 1.0)
Bug #1502354 reported by
Corentin Noël
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
Using the URLs from this page: https:/
Changed in launchpad: | |
importance: | Undecided → Low |
status: | New → Triaged |
summary: |
- Comply with OAuth v1.0 + Comply with OAuth v1.0 (the RFC, not the original 1.0) |
To post a comment you must log in.
Launchpad's OAuth implementation predates the RFC; the version 1.0 that we implement is the original "OAuth Core 1.0" from http:// oauth.net/ core/1. 0/. That real 1.0 doesn't include oauth_callback_ confirmed; it was added in 1.0a. RFC 5849 defines a second version 1.0 (yes, seriously), which is a variant of 1.0a.
Launchpad hasn't upgraded to OAuth Core 1.0a, as the session fixation attack in the original 1.0 isn't relevant to our implementation. OAuth 1.0 was primarily designed for trusted relationships between web services, but in Launchpad it is used for a relationship between a desktop application or script and Launchpad.
For this reason, Launchpad can't trust a particular consumer, as everyone running an application or script possesses the consumer's secret. Since consumer identities aren't trustworthy, an upgrade to 1.0a just complicates the workflow for no benefit -- the attacker could just pretend to be an honest consumer, send a callback URL that points to themselves, and proceed as normal.