Closed fmarier closed 1 month ago
It should be enough to test for the host
be the same, to block wrong redirects here
PASSED
usingBrave | 1.70.54 Chromium: 127.0.6533.100 (Official Build) nightly (x86_64)
-- | --
Revision | 30140ea3aefda98e32ddd4daa2309ca5eb273f64
OS | macOS Version 11.7.10 (Build 20G1427)
1.70.54
Developer Tools
https://go.redirectingat.com/?url=http%3A%2F%2Fevil.com%5C%5C%40apps.apple.com
https://www.apple.com/app-store/
loaded instead of evil.com
example | example |
---|---|
Verification PASSED on
Brave | 1.70.100 Chromium: 128.0.6613.120 (Official Build) beta (64-bit)
-- | --
Revision | c30694e8a60583be9d1784e4d42b4a0b94c70ab5
OS | Windows 10 Version 22H2 (Build 19045.4780)
Verified the test plan from https://github.com/brave/brave-core/pull/24964
Confirmed that https://go.redirectingat.com/?url=http%3A%2F%2Fevil.com%5C%5C%40apps.apple.com
redirects to https://www.apple.com/app-store/
instead of evil.com
Description
When checking that the destination URL is valid, we currently use the Chromium URL parser. We should use both the Chromium parser (following the WHATWG spec) and a URL parser which follows the RFC spec.
If the resulting URL has a different hostname depending on the parser, then we can reject the URL.
Steps to reproduce
See https://hackerone.com/reports/2610290 for a sample test case.
Actual result
See above.
Expected result
Edge cases should not be debounced.
Reproduces how often
Easily reproduced
Desktop Brave version (brave://version info)
Android device
(not tested)
Channel information
Reproducibility
Miscellaneous information
No response