OAuth IP restrictions only apply to Special:OAuth/initiate, not to general API requests
Closed, ResolvedPublic

Description

OAuth consumers are able to set IP restrictions, for example consumer 571d07e4e3a8209ee5e83f603e8c4f61 has the WMF IPs {"IPAddresses":["208.80.152.0/22","198.35.26.0/23","10.0.0.0/8"]} as usage restriction.

These IP restrictions only seem to work when negotiating a new client token over Special:OAuth/initiate. When I locally make an API request with an already existing client/access token I get a valid response and no error.

I stumbled upon this due to the tools outage.

Maniphest changed the visibility from "Public (No Login Required)" to "Custom Policy".Jun 18 2015, 10:04 PM
Maniphest changed the edit policy from "All Users" to "Custom Policy".
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 18 2015, 10:04 PM
Sitic created this task.Jun 18 2015, 10:04 PM
Sitic updated the task description. (Show Details)
Sitic changed Security from None to Software security bug.
Sitic edited subscribers, added: Sitic; removed: Aklapper.
csteipp claimed this task.Jun 18 2015, 11:00 PM
csteipp added subscribers: Anomie, csteipp.

Confirmed

@Anomie, I think that will cover the API calls and the call to /identify, but it would be great if you could sanity check it.

csteipp triaged this task as High priority.Jun 18 2015, 11:01 PM
csteipp added a project: Security-Team.
csteipp moved this task from Backlog to In Progress on the Security-Team board.

Confirmed

@Anomie, I think that will cover the API calls and the call to /identify, but it would be great if you could sanity check it.

Looks sane, and I confirm that it looks like both the API code path and /identify call verify_request(). This also seems like the sensible place to put the check.

Haven't tested though.

@Sitic, do you have a local OAuth instance that you can test this patch and verify that it fixes the issue?

@Sitic, do you have a local OAuth instance that you can test this patch and verify that it fixes the issue?

Tested locally, fixes the issue (getting The authorization headers in your request are not valid: <bad-source-ip> error now).

@mmodell, can you deploy

and confirm when it's on production?

csteipp closed this task as Resolved.Jul 8 2015, 8:58 PM

20:56 csteipp: deployed patches for T103022 & T103023

csteipp moved this task from In Progress to Done on the Security-Team board.Oct 13 2015, 11:56 PM
demon changed the visibility from "Custom Policy" to "Public (No Login Required)".Oct 16 2015, 10:34 PM
demon changed the edit policy from "Custom Policy" to "All Users".
demon changed Security from Software security bug to None.

Assigned CVE-2015-8008