https://bugzilla.wikimedia.org/show_bug.cgi?id=22108
Summary: Restricting OpenID using $wgOpenIDConsumerAllow can be
bypassed
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: Normal
Component: OpenID
AssignedTo: [email protected]
ReportedBy: [email protected]
Picture this situation:
LocalSettings.php:
# Deny all OpenIDs except the ones we allow:
$wgOpenIDConsumerDenyByDefault = true;
$wgOpenIDConsumerAllow = array("@^(http://)?mydomain.com@");
Someone enters in http://mydomain.com/ - validation passes - all is good.
Then, then take the URL that their browser is redirected to (I used Firefox's
Live HTTP Headers plugin to see this), copy the OpenID parameters off it, and
then suffix them onto a server which they have an account on (say,
https://login.launchpad.net/+openid).
Voila, I am logged into this supposedly-restricted wiki with an OpenID that
fails the consumer allow test.
Two things come to mind here:
- Aren't OpenID requests meant to be signed, so they can't be tampered with
in this way?
- You should validate after the OpenID is returned, not (just) before.
For example, I have solved this by adding to SpecialOpenIDFinish.body.php
case Auth_OpenID_SUCCESS:
// This means the authentication succeeded.
$openid = $response->getDisplayIdentifier();
// Check we have been given an identifier we
accept.
if (!$this->canLogin($openid_url)) {
$wgOut->showErrorPage('openidpermission', 'openidpermissiontext');
return;
}
However, I don't think this will stop a OP that is prepared to issue an ID in
any name - only signing will fix that.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
