Page MenuHomePhabricator

Implement a 'signing OAuth Proxy' for PAWS
Open, HighPublic

Description

Have a proxy that'll contain the consumer_secret that pywikibot (and others) can contact to actually sign the access request. This allows people to use OAuth without requiring them to know the consumer_secret.

Event Timeline

yuvipanda raised the priority of this task from to Needs Triage.
yuvipanda updated the task description. (Show Details)
yuvipanda added a project: PAWS.
yuvipanda added subscribers: yuvipanda, csteipp.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 4 2015, 11:41 PM
yuvipanda triaged this task as High priority.Dec 6 2015, 4:47 AM
yuvipanda set Security to None.
Tgr added a subscriber: Tgr.Aug 29 2016, 7:13 AM
Tgr added a comment.Aug 29 2016, 7:50 AM

See this article (section 2) for the threat model. In short,

  1. a hostile user can send requests (in their own name) which fool the wiki server into thinking they were made with PAWS. Probably not that significant given that PAWS already allows you to make any kind of request so seeing a PAWS tag on an edit does not give any kind of guarantee about its content.
  2. more problematically, a hostile application might be able to impersonate PAWS towards the user, send it to the authorization dialog, get the access secret and then do arbitrary actions in the user's name. This would require some kind of breach of network integrity as the consumer URL prefix would guarantee that information can only be sent to PAWS; but MITM-ing the user-PAWS connection is probably a lot easier than MITM-ing the user-Wikipedia connection.

After thinking about it a bit, I think the reasonable way to do this is to have an internal API (internal to PAWS but not the container) to which Pywikibot can hand off a request (or a request head, in case of huge POST requests) and get back a signature (or a signed request/head, if that's more convenient). The client would be in full control of the HTTPS connection; access to the API basically means the client can make preimage attacks against the signing process, and a SHA1 HMAC should be safe against that.

PokestarFan raised the priority of this task from High to Unbreak Now!.Sep 22 2017, 7:23 PM
PokestarFan added a subscriber: PokestarFan.

This is a problem

Restricted Application added subscribers: Liuxinyu970226, Jay8g, TerraCodes. · View Herald TranscriptSep 22 2017, 7:24 PM
Multichill lowered the priority of this task from Unbreak Now! to High.Sep 22 2017, 7:49 PM
Multichill added a subscriber: Multichill.