Summary: Via HackerOne. This defuses an attack which allows users to steal OAuth tokens through a clever sequence of steps: - The attacker begins the OAuth workflow and copies the Facebook URL. - The attacker mutates the URL to use the JS/anchor workflow, and to redirect to `/phame/live/X/` instead of `/login/facebook:facebook.com/`, where `X` is the ID of some blog they control. Facebook isn't strict about paths, so this is allowed. - The blog has an external domain set (`blog.evil.com`), and the attacker controls that domain. - The user gets stopped on the "live" controller with credentials in the page anchor (`#access_token=...`) and a message ("This blog has moved...") in a dialog. They click "Continue", which POSTs a CSRF token. - When a user POSTs a `<form />` with no `action` attribute, the browser retains the page anchor. So visiting `/phame/live/8/#anchor` and clicking the "Continue" button POSTs you to a page with `#anchor` intact. - Some browsers (including Firefox and Chrome) retain the anchor after a 302 redirect. - The OAuth credentials are thus preserved when the user reaches `blog.evil.com`, and the attacker's site can read them. This 302'ing after CSRF post is unusual in Phabricator and unique to Phame. It's not necessary -- instead, just use normal links, which drop anchors. I'm going to pursue further steps to mitigate this class of attack more thoroughly: - Ideally, we should render forms with an explicit `action` attribute, but this might be a lot of work. I might render them with `#` if no action is provided. We never expect anchors to survive POST, and it's surprising to me that they do. - I'm going to blacklist OAuth parameters (like `access_token`) from appearing in GET on all pages except whitelisted pages (login pages). Although it's not important here, I think these could be captured from referrers in some cases. See also T4342. Test Plan: Browsed all the affected Phame interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran, arice Differential Revision: https://secure.phabricator.com/D8481
75 lines
1.9 KiB
PHP
75 lines
1.9 KiB
PHP
<?php
|
|
|
|
/**
|
|
* @group phame
|
|
*/
|
|
final class PhameBlogLiveController extends PhameController {
|
|
|
|
private $id;
|
|
private $more;
|
|
|
|
public function shouldAllowPublic() {
|
|
return true;
|
|
}
|
|
|
|
public function willProcessRequest(array $data) {
|
|
$this->id = idx($data, 'id');
|
|
$this->more = idx($data, 'more', '');
|
|
}
|
|
|
|
public function processRequest() {
|
|
$request = $this->getRequest();
|
|
$user = $request->getUser();
|
|
|
|
$blog = id(new PhameBlogQuery())
|
|
->setViewer($user)
|
|
->withIDs(array($this->id))
|
|
->executeOne();
|
|
if (!$blog) {
|
|
return new Aphront404Response();
|
|
}
|
|
|
|
if ($blog->getDomain() && ($request->getHost() != $blog->getDomain())) {
|
|
$base_uri = $blog->getLiveURI();
|
|
|
|
// Don't redirect directly, since the domain is user-controlled and there
|
|
// are a bevy of security issues associated with automatic redirects to
|
|
// external domains.
|
|
|
|
// Previously we CSRF'd this and someone found a way to pass OAuth
|
|
// information through it using anchors. Just make users click a normal
|
|
// link so that this is no more dangerous than any other external link
|
|
// on the site.
|
|
|
|
$dialog = id(new AphrontDialogView())
|
|
->setTitle(pht('Blog Moved'))
|
|
->setUser($user)
|
|
->appendParagraph(pht('This blog is now hosted here:'))
|
|
->appendParagraph(
|
|
phutil_tag(
|
|
'a',
|
|
array(
|
|
'href' => $base_uri,
|
|
),
|
|
$base_uri))
|
|
->addCancelButton('/');
|
|
|
|
return id(new AphrontDialogResponse())->setDialog($dialog);
|
|
}
|
|
|
|
$phame_request = clone $request;
|
|
$phame_request->setPath('/'.ltrim($this->more, '/'));
|
|
|
|
$uri = $blog->getLiveURI();
|
|
|
|
$skin = $blog->getSkinRenderer($phame_request);
|
|
$skin
|
|
->setBlog($blog)
|
|
->setBaseURI($uri);
|
|
|
|
$skin->willProcessRequest(array());
|
|
return $skin->processRequest();
|
|
}
|
|
|
|
}
|