revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-10 08:52:39 +01:00
Code Issues Releases Wiki Activity

Remove the developer-specific CSRF help in phabricator_form()

Browse source 
Summary:
Fixes T4802. For context, see T1921.

Originally (in T1921), a developer ran into an issue where rendering `phabricator_form()` with an absolute URI confusingly dropped CSRF tokens, and it wasn't obvious why. This is a security measure, but at the time it wasn't very clear how all the pieces fit together. To make it more clear, we:

  # expanded the exception text in developer mode to include a description of this issue; and
  # added an exception in developer mode when rendering a form like this.

However, (2) causes some undesirable interactions for file downloads. In particular, if:

  - developer mode is on; and
  - there's no alternate file domain configured; and
  - you try to download a file...

...we produce CDN URIs that are fully-qualified, and you get the exception from (2) above.

This is kind of a mess, and producing fully-qualified CDN URIs in all cases is simple and clear and desirable. To resolve this, just revert (2). We still have the clarification from (1) above and this hasn't caused further issues, so I think that's sufficient. This is a rare issue anyway and not particularly serious or error prone (at worst, a bit confusing and annoying, but hopefully easy to understand and resolve after the changes in (1)).

Test Plan: With develper mode and no alternate file domain, downloaded files from Files.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4802

Differential Revision: https://secure.phabricator.com/D8776
This commit is contained in:
epriestley 2014-04-15 10:18:41 -07:00
parent cb545856a9
commit 04c07a7a7b
1 changed files with 19 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
src/infrastructure/javelin/markup.php
View file

@ -49,25 +49,26 @@ function phabricator_form(PhabricatorUser $user, $attributes, $content) {
$is_absolute_uri = preg_match('#^(https?:|//)#', $http_action);
if ($is_post) {
if ($is_absolute_uri) {
$is_dev = PhabricatorEnv::getEnvConfig('phabricator.developer-mode');
if ($is_dev) {
$form_domain = id(new PhutilURI($http_action))
->getDomain();
$host_domain = id(new PhutilURI(PhabricatorEnv::getURI('/')))
->getDomain();
if (strtolower($form_domain) == strtolower($host_domain)) {
throw new Exception(
pht(
"You are building a <form /> that submits to Phabricator, but ".
"has an absolute URI in its 'action' attribute ('%s'). To avoid ".
"leaking CSRF tokens, Phabricator does not add CSRF information ".
"to forms with absolute URIs. Instead, use a relative URI.",
$http_action));
}
}
} else {
// NOTE: We only include CSRF tokens if a URI is a local URI on the same
// domain. This is an important security feature and prevents forms which
// submit to foreign sites from leaking CSRF tokens.
// In some cases, we may construct a fully-qualified local URI. For example,
// we can construct these for download links, depending on configuration.
// These forms do not receive CSRF tokens, even though they safely could.
// This can be confusing, if you're developing for Phabricator and
// manage to construct a local form with a fully-qualified URI, since it
// won't get CSRF tokens and you'll get an exception at the other end of
// the request which is a bit disconnected from the actual root cause.
// However, this is rare, and there are reasonable cases where this
// construction occurs legitimately, and the simplest fix is to omit CSRF
// tokens for these URIs in all cases. The error message you receive also
// gives you some hints as to this potential source of error.
if (!$is_absolute_uri) {
$body[] = phutil_tag(
'input',
array(