why forbid javascript: and some other thing that you know know, if you know for sure you only want http or https?
always allow what you know for sure how to handle instead of denying what you think you know that you don't want.
why forbid javascript: and some other thing that you know know, if you know for sure you only want http or https?
always allow what you know for sure how to handle instead of denying what you think you know that you don't want.
My guess would be that the URL is being validated with code which relies on null-terminated strings, and it's being processed/executed with code that uses a separate length value.
The empty string "" will pass a same-origin check as it refers to the current page. "\0javascript:alert()" looks like the empty string to validation code expecting null-terminated strings. However, it's a valid URL and is executed as JavaScript by code that knows the true length.
One easy way this could happen is if the same-origin check happens in C++ (eg. WebKit) and the URL fetch happens in Java.
The same problem can happen in reverse and has before. Java had a file path vulnerability where Java code would see the full path and the OS calls Java passed to would only process up to the first null. This opened up bypasses in application logic designed to validate paths.
I doubt "\0javascript" is a valid URI scheme since they must begin with a letter, and any code that uses 0-terminated strings would just see it as an empty string. The fact that the \0 somehow seems to be ignored completely is most disturbing.
Edit: I double-checked the spec ( http://www.w3.org/TR/html5/browsers.html#dom-open ) just to make sure there's no weird "skip nulls" behaviour, and there isn't.
It really depends on the browser. Here are a few test cases to consider. http://jsfiddle.net/8e525ne9/
Leading nulls used to work in common browsers. Most recent browsers don't support it. However, most do continue to support fun things like newlines and tabs in the middle of URL schemes.