Page MenuHomePhabricator

Harbormaster does not ignore additional whitespace in HTTP URLs, making invalid HTTP requests
Open, LowPublic

Description

I have created a Harbormaster build plan based on a “Make HTTP request” build step to trigger a build in Jenkins. It is a simple GET request for a Jenkins URL looking like http://buildserver/jenkins/buildByToken/...etc. However, when copy/pasting the URL, I have left an additional single space character at the end of the URL. Phabricator kept the additional space and included it verbatim in the HTTP request line, which caused Jenkins (or rather its Jetty server, I guess) to reject the request with “400 Bad Request”. And indeed, per RFC 7230 (chapter 3.1.1), only “single space” is allowed in the request line.

Steps to reproduce:

  • Create a new build plan (Harbormaster, Manage Build Plans, Create Build Plan)
  • Add a build step into the plan of the type Make HTTP Request. Enter any testable URL, but add a space after the URL (e.g. http://server/some/test ). Choose GET method and save the step.
  • Run the plan manually (on any buildable entity).

Actual result:

  • Phabricator makes an HTTP request having a request line of GET /some/test HTTP/1.0 (note two spaces between the request-target and HTTP-version).

Expected results:

  • The additional whitespace at the end of the URL is either trimmed at save time (or prevented with a validator during edit), or ignored when making the HTTP request, so that Phabricator makes a valid HTTP request.

Running up-to-date Phabricator on stable, currently at:

Event Timeline

epriestley triaged this task as Low priority.EditedMay 12 2017, 5:49 PM
epriestley added a project: Security.
epriestley added a subscriber: epriestley.

T11632 is vaguely related.

There are some general adjacent issues here too:

  • Validation, period, is tricky because Harbormaster build steps do some weird spec-based stuff with CustomFields. These should move to become EditField-based, and possibly even use Modular Transactions, although that might be a step too far.
  • These should also be validated against the remote address whitelist.

The second issue is security-related, but you need to have access to create and run builds to potentially be able to do any damage, plus unsecured HTTP endpoints which obviously no one would have (except, every AWS host has them).