Thanks for the report.

If I am understanding this correctly, you are saying that some websites might redirect to attacker-supplied URLs, but blacklist javascript: URLs to prevent cross-site scripting. And inserting invalid characters that get stripped from the target URL would fool a naive blacklist system.

Have you found any examples of sites that are vulnerable in this way? Open redirects exist on the internet, but my understanding is that they restrict to only http:// or https:// URLs, i.e. whitelisting, and so this wouldn't cause a problem for them.

yes. i found on live attack one of the famous site.
but i cannot share the url until they fix the issue.
So i made PoC with same logic 

"\u0008\u0000https:\\" open redirect also can be overridden .
I seen Microsoft Edge preventing this.
But chrome and Firefox not preventing them.So i made report to firebox and chrome 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks, I'm glad you reported the problem to the affected website; that isn't a safe practice.

OWP Security people: It looks like we have tried to manage this sort of problem before in  issue 37383 . Does anyone have any thoughts on this? If not I could probably write a quick fix for this next week.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I hope chromium team will release the fix soon

If I read https://url.spec.whatwg.org/#concept-basic-url-parser correctly, this is just a validation error that does not abort URL parsing, and afaik edge doesn't implement that spec yet...

Sounds like a bug in the website.

We could consider changing the HTML spec to refuse URLs for Location that don't validate, but that's a different issue.

https://url.spec.whatwg.org/#url-parsing

Non-web-browser implementations only need to implement the basic URL parser.
The specification for Non-web-browser.
the website checking native validation whether url start with javascript:
It will effect only in browser

The full url parser invokes the basic parser and ignores validation errors, so not sure what your point is?

They mentioned basic parser only for non web browser.
it is not for web browser like chrome, firebox,edge
chrome not throw any validation error like firebox or edge.
https://url.spec.whatwg.org/#concept-basic-url-parser
"3.Remove any leading and trailing C0 control or space from input."
for example in url Space \u0020 used as code valid url 
it will convert into %20
So basic url parser concept will not work on web browser.

May i know when it will be fixed?

"\u0008\u0000javascript:"=="javascript:" will not be equal and url scheme never start with C0 and/or space .

if web browser is accepting then issue with web browser only.
\u0008=>%08 and \u0000=>%00 so it should go to  "%08%00javascript:" not "javascript:"

So the real location should be https://othertest45.azurewebsites.net/%08%00javascript:alert(document.domain)

but it is executing XSS

Adding some more url/ owners.


After double-checking the spec, my analysis still is that stripping \000c\0000 without throwing an error is work as intended.

Also confirmed that Safari does this.

So I'd vote for WontFix.

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#parse-a-url
1.Let encoding be document's character encoding, if document was given, and environment settings object's API URL character encoding otherwise.

3.Let urlRecord be the result of applying the URL parser to url, with baseURL and encoding.

https://url.spec.whatwg.org/#concept-basic-url-parser
1.If url is not given:

  1.Set url to a new URL.

  2.If input contains any leading or trailing C0 control or space, validation error.

  3.Remove any leading and trailing C0 control or space from input.
So as per user agent the step1 should be consider when url given

*So as per user agent the step1 should not be consider when url given

validation error is ignored by html

validation error it can skip that is not a problem.

https://url.spec.whatwg.org/#urls

Input:"\u0008\u0000javascript:alert(document.domain)"
 
Base: https://othertest45.azurewebsites.net/
 
Valid: ❌
Expected OutPut:https://othertest45.azurewebsites.net/%08%00javascript:alert(document.domain) or Failure

may i know what is your expected output?

palmer or dcheng: Do either of you have any thoughts on this? jochen thinks this behavior is in conformance with spec.

I don't see why we should permit junk characters in a URL, such as by stripping them first before parsing. If the entire input is not valid as a URL, then we should not act on it. (I'm going by https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/.) Perhaps this means the spec should be fixed, too.

That wasn't the question, by whether the behavior in chrome (and Safari and Firefox) is spec compliant

After checking all it looks like spec compliant.
https://url.spec.whatwg.org/#validation-error
By validation error it having invalid schema.
By validation error chrome can return while parsing return statemant as Failure.
But it is up to chromium team decision. because validtion error can be ignored 
I request you chrome better return invalid schema for security reason when schema start with C0 control or space by validation error 

Another issue is forming invaliad url
trimming first and end of the string it is forming invalid url 
new URL('test','https://example.com').href => https://example.com/test"

new URL(' test test ','https://example.com').href => https://example.com/test%20test" 
it should be https://example.com/%20test%20test%20 because it valid url.

while navigation it is allowing , why it is blocking in parsing URL?

Filed https://github.com/whatwg/html/issues/3814 to track this as spec issue, I'd recommend to remove the security label from this bug

even specification having issue.
But chrome can consider as per validation specification https://url.spec.whatwg.org/#validation-error 
By validation error chrome can return while parsing return statemant as Failure.
But it is up to chromium team decision. because validtion error can be ignored 
I request you chrome better return invalid schema for security reason when schema start with C0 control or space by validation error 

I agree with c#22 -- removing security flags since it is currently not actually a bug at present and only some poorly behaved websites would be affected.

It sounds like people broadly agree that a spec change is reasonable.

better keep security flag because  spec change is reasonable for security reason