Change Details

Via HackerOne. See <https://hackerone.com/reports/306414>. All browsers seem to accept `<a href="/\evil.com" ...>` as equivalent to `//evil.com`, i.e. a protocol-relative URI (uses "http" or "https" depending on the protocol for the current page). They're equally accepting fo `<a href="/\/\\\\///\/\evil.com" ...>` and so on, too. I assume this users don't know the difference between slash and backslash, and someone in the 1990's thought this was a reaonable usability affordance and we're stuck with it forever? Note that we've encountered this problem previously in `PhabricatorEnv->isValidLocalURIForLink()`, although the scope and context are a little different there. In that case, we simply reject URIs with backslashes anywhere. The security risk associated with this -- "tabnabbing" -- is fairly low, and amounts to a targeted phishing attack, so I don't plan to take any exceptional security measures here.

Via HackerOne. See <https://hackerone.com/reports/306414>. All browsers seem to accept `<a href="/\evil.com" ...>` as equivalent to `//evil.com`, i.e. a protocol-relative URI (uses "http" or "https" depending on the protocol for the current page). They're equally accepting fo `<a href="/\/\\\\///\/\evil.com" ...>` and so on, too. I assume this is because normal users don't know the difference between slash and backslash, and someone in the 1990's thought this was a reaonable usability affordance and we're stuck with it forever? Note that we've encountered this problem previously in `PhabricatorEnv->isValidLocalURIForLink()`, although the scope and context are a little different there. In that case, we simply reject URIs with backslashes anywhere. The security risk associated with this -- "tabnabbing" -- is fairly low, and amounts to a targeted phishing attack, so I don't plan to take any exceptional security measures here.

Via HackerOne. See <https://hackerone.com/reports/306414>. All browsers seem to accept `<a href="/\evil.com" ...>` as equivalent to `//evil.com`, i.e. a protocol-relative URI (uses "http" or "https" depending on the protocol for the current page). They're equally accepting fo `<a href="/\/\\\\///\/\evil.com" ...>` and so on, too. I assume this is because normal users don't know the difference between slash and backslash, and someone in the 1990's thought this was a reaonable usability affordance and we're stuck with it forever? Note that we've encountered this problem previously in `PhabricatorEnv->isValidLocalURIForLink()`, although the scope and context are a little different there. In that case, we simply reject URIs with backslashes anywhere. The security risk associated with this -- "tabnabbing" -- is fairly low, and amounts to a targeted phishing attack, so I don't plan to take any exceptional security measures here.