2013-06-17 15:12:45 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorAuthUnlinkController
|
|
|
|
extends PhabricatorAuthController {
|
|
|
|
|
|
|
|
private $providerKey;
|
|
|
|
|
2015-08-02 01:49:27 +02:00
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
$this->providerKey = $request->getURIData('pkey');
|
2013-06-17 15:12:45 +02:00
|
|
|
|
|
|
|
list($type, $domain) = explode(':', $this->providerKey, 2);
|
|
|
|
|
|
|
|
// Check that this account link actually exists. We don't require the
|
|
|
|
// provider to exist because we want users to be able to delete links to
|
|
|
|
// dead accounts if they want.
|
|
|
|
$account = id(new PhabricatorExternalAccount())->loadOneWhere(
|
|
|
|
'accountType = %s AND accountDomain = %s AND userPHID = %s',
|
|
|
|
$type,
|
|
|
|
$domain,
|
|
|
|
$viewer->getPHID());
|
|
|
|
if (!$account) {
|
|
|
|
return $this->renderNoAccountErrorDialog();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check that the provider (if it exists) allows accounts to be unlinked.
|
|
|
|
$provider_key = $this->providerKey;
|
|
|
|
$provider = PhabricatorAuthProvider::getEnabledProviderByKey($provider_key);
|
|
|
|
if ($provider) {
|
|
|
|
if (!$provider->shouldAllowAccountUnlink()) {
|
|
|
|
return $this->renderNotUnlinkableErrorDialog($provider);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check that this account isn't the last account which can be used to
|
|
|
|
// login. We prevent you from removing the last account.
|
|
|
|
if ($account->isUsableForLogin()) {
|
|
|
|
$other_accounts = id(new PhabricatorExternalAccount())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$viewer->getPHID());
|
|
|
|
|
|
|
|
$valid_accounts = 0;
|
|
|
|
foreach ($other_accounts as $other_account) {
|
|
|
|
if ($other_account->isUsableForLogin()) {
|
|
|
|
$valid_accounts++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($valid_accounts < 2) {
|
|
|
|
return $this->renderLastUsableAccountErrorDialog();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($request->isDialogFormPost()) {
|
|
|
|
$account->delete();
|
Terminate other sessions on credential changes
Summary:
Fixes T5509. Currently, existing sessions live on even if you change your password.
Over the course of the program, we've recieved a lot of HackerOne reports that sessions do not terminate when users change their passwords. I hold that this isn't a security vulnerability: users can explicitly manage sessions, and this is more general and more powerful than tying session termination to password resets. In particular, many installs do not use a password provider at all (and no researcher has reported this in a general, application-aware way that discusses multiple authentication providers).
That said, dealing with these false positives is vaguely time consuming, and the "expected" behavior isn't bad for users, so just align behavior with researcher expectations: when passwords are changed, providers are removed, or multi-factor authentication is added to an account, terminate all other active login sessions.
Test Plan:
- Using two browsers, established multiple login sessions.
- In one browser, changed account password. Saw session terminate and logout in the second browser.
- In one browser, removed an authentication provider. Saw session terminate and logout in the second browser.
- In one browser, added MFA. Saw session terminate and logout in the second browser.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5509
Differential Revision: https://secure.phabricator.com/D10135
2014-08-04 21:04:35 +02:00
|
|
|
|
|
|
|
id(new PhabricatorAuthSessionEngine())->terminateLoginSessions(
|
|
|
|
$viewer,
|
Upgrade sessions digests to HMAC256, retaining compatibility with old digests
Summary:
Ref T13222. Ref T13225. We store a digest of the session key in the session table (not the session key itself) so that users with access to this table can't easily steal sessions by just setting their cookies to values from the table.
Users with access to the database can //probably// do plenty of other bad stuff (e.g., T13134 mentions digesting Conduit tokens) but there's very little cost to storing digests instead of live tokens.
We currently digest session keys with HMAC-SHA1. This is fine, but HMAC-SHA256 is better. Upgrade:
- Always write new digests.
- We still match sessions with either digest.
- When we read a session with an old digest, upgrade it to a new digest.
In a few months we can throw away the old code. When we do, installs that skip upgrades for a long time may suffer a one-time logout, but I'll note this in the changelog.
We could avoid this by storing `hmac256(hmac1(key))` instead and re-hashing in a migration, but I think the cost of a one-time logout for some tiny subset of users is very low, and worth keeping things simpler in the long run.
Test Plan:
- Hit a page with an old session, got a session upgrade.
- Reviewed sessions in Settings.
- Reviewed user logs.
- Logged out.
- Logged in.
- Terminated other sessions individually.
- Terminated all other sessions.
- Spot checked session table for general sanity.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13225, T13222
Differential Revision: https://secure.phabricator.com/D19883
2018-12-13 19:52:54 +01:00
|
|
|
new PhutilOpaqueEnvelope(
|
|
|
|
$request->getCookie(PhabricatorCookies::COOKIE_SESSION)));
|
Terminate other sessions on credential changes
Summary:
Fixes T5509. Currently, existing sessions live on even if you change your password.
Over the course of the program, we've recieved a lot of HackerOne reports that sessions do not terminate when users change their passwords. I hold that this isn't a security vulnerability: users can explicitly manage sessions, and this is more general and more powerful than tying session termination to password resets. In particular, many installs do not use a password provider at all (and no researcher has reported this in a general, application-aware way that discusses multiple authentication providers).
That said, dealing with these false positives is vaguely time consuming, and the "expected" behavior isn't bad for users, so just align behavior with researcher expectations: when passwords are changed, providers are removed, or multi-factor authentication is added to an account, terminate all other active login sessions.
Test Plan:
- Using two browsers, established multiple login sessions.
- In one browser, changed account password. Saw session terminate and logout in the second browser.
- In one browser, removed an authentication provider. Saw session terminate and logout in the second browser.
- In one browser, added MFA. Saw session terminate and logout in the second browser.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5509
Differential Revision: https://secure.phabricator.com/D10135
2014-08-04 21:04:35 +02:00
|
|
|
|
2013-06-17 15:12:45 +02:00
|
|
|
return id(new AphrontRedirectResponse())->setURI($this->getDoneURI());
|
|
|
|
}
|
|
|
|
|
2017-02-17 11:10:15 +01:00
|
|
|
return $this->renderConfirmDialog();
|
2013-06-17 15:12:45 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
private function getDoneURI() {
|
|
|
|
return '/settings/panel/external/';
|
|
|
|
}
|
|
|
|
|
|
|
|
private function renderNoAccountErrorDialog() {
|
|
|
|
$dialog = id(new AphrontDialogView())
|
|
|
|
->setUser($this->getRequest()->getUser())
|
|
|
|
->setTitle(pht('No Such Account'))
|
|
|
|
->appendChild(
|
|
|
|
pht(
|
2014-06-09 20:36:49 +02:00
|
|
|
'You can not unlink this account because it is not linked.'))
|
2013-06-17 15:12:45 +02:00
|
|
|
->addCancelButton($this->getDoneURI());
|
|
|
|
|
|
|
|
return id(new AphrontDialogResponse())->setDialog($dialog);
|
|
|
|
}
|
|
|
|
|
|
|
|
private function renderNotUnlinkableErrorDialog(
|
|
|
|
PhabricatorAuthProvider $provider) {
|
|
|
|
|
|
|
|
$dialog = id(new AphrontDialogView())
|
|
|
|
->setUser($this->getRequest()->getUser())
|
|
|
|
->setTitle(pht('Permanent Account Link'))
|
|
|
|
->appendChild(
|
|
|
|
pht(
|
2014-06-09 20:36:49 +02:00
|
|
|
'You can not unlink this account because the administrator has '.
|
|
|
|
'configured Phabricator to make links to %s accounts permanent.',
|
2013-06-17 15:12:45 +02:00
|
|
|
$provider->getProviderName()))
|
|
|
|
->addCancelButton($this->getDoneURI());
|
|
|
|
|
|
|
|
return id(new AphrontDialogResponse())->setDialog($dialog);
|
|
|
|
}
|
|
|
|
|
|
|
|
private function renderLastUsableAccountErrorDialog() {
|
|
|
|
$dialog = id(new AphrontDialogView())
|
|
|
|
->setUser($this->getRequest()->getUser())
|
|
|
|
->setTitle(pht('Last Valid Account'))
|
|
|
|
->appendChild(
|
|
|
|
pht(
|
2014-06-09 20:36:49 +02:00
|
|
|
'You can not unlink this account because you have no other '.
|
|
|
|
'valid login accounts. If you removed it, you would be unable '.
|
2017-08-02 21:26:40 +02:00
|
|
|
'to log in. Add another authentication method before removing '.
|
2014-06-09 20:36:49 +02:00
|
|
|
'this one.'))
|
2013-06-17 15:12:45 +02:00
|
|
|
->addCancelButton($this->getDoneURI());
|
|
|
|
|
|
|
|
return id(new AphrontDialogResponse())->setDialog($dialog);
|
|
|
|
}
|
|
|
|
|
|
|
|
private function renderConfirmDialog() {
|
|
|
|
$provider_key = $this->providerKey;
|
|
|
|
$provider = PhabricatorAuthProvider::getEnabledProviderByKey($provider_key);
|
|
|
|
|
|
|
|
if ($provider) {
|
|
|
|
$title = pht('Unlink "%s" Account?', $provider->getProviderName());
|
|
|
|
$body = pht(
|
|
|
|
'You will no longer be able to use your %s account to '.
|
|
|
|
'log in to Phabricator.',
|
|
|
|
$provider->getProviderName());
|
|
|
|
} else {
|
|
|
|
$title = pht('Unlink Account?');
|
|
|
|
$body = pht(
|
|
|
|
'You will no longer be able to use this account to log in '.
|
|
|
|
'to Phabricator.');
|
|
|
|
}
|
|
|
|
|
|
|
|
$dialog = id(new AphrontDialogView())
|
|
|
|
->setUser($this->getRequest()->getUser())
|
|
|
|
->setTitle($title)
|
Terminate other sessions on credential changes
Summary:
Fixes T5509. Currently, existing sessions live on even if you change your password.
Over the course of the program, we've recieved a lot of HackerOne reports that sessions do not terminate when users change their passwords. I hold that this isn't a security vulnerability: users can explicitly manage sessions, and this is more general and more powerful than tying session termination to password resets. In particular, many installs do not use a password provider at all (and no researcher has reported this in a general, application-aware way that discusses multiple authentication providers).
That said, dealing with these false positives is vaguely time consuming, and the "expected" behavior isn't bad for users, so just align behavior with researcher expectations: when passwords are changed, providers are removed, or multi-factor authentication is added to an account, terminate all other active login sessions.
Test Plan:
- Using two browsers, established multiple login sessions.
- In one browser, changed account password. Saw session terminate and logout in the second browser.
- In one browser, removed an authentication provider. Saw session terminate and logout in the second browser.
- In one browser, added MFA. Saw session terminate and logout in the second browser.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5509
Differential Revision: https://secure.phabricator.com/D10135
2014-08-04 21:04:35 +02:00
|
|
|
->appendParagraph($body)
|
|
|
|
->appendParagraph(
|
|
|
|
pht(
|
|
|
|
'Note: Unlinking an authentication provider will terminate any '.
|
|
|
|
'other active login sessions.'))
|
2013-06-17 15:12:45 +02:00
|
|
|
->addSubmitButton(pht('Unlink Account'))
|
|
|
|
->addCancelButton($this->getDoneURI());
|
|
|
|
|
|
|
|
return id(new AphrontDialogResponse())->setDialog($dialog);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|