http://simpleportal.net/index.php?topic=14115
No idea how to fix it but it's *bad*, give it a try, please. :-X
By the way, it can be placed anywhere - in sigs etc. It should be addressed as quickly as possible because if some malicious users start to spam it, then they can lead any other user with Chrome-based browsers to instantly crash while browsing the forum.
That's a really big bug.
Yeah I dared to use to exclamation icon, too ;D
Thats awesome, I love it. (just hover that link in chrome and it bombs)
http://a/%%30%30
We should probably do some additional sanitation of the image / link strings in 1.1 ... the reality is that chrome will be fixed and pushed faster than the server side of things though.
LOL
Well, is that a valid url or has some invalid element?
I don't think its valid as it would say the FQDN is "a"
Sigh, and they don't want to fix it on SMF. Undecided whether to laugh or cry.
Though... it's a valid host unless I read the specification wrong.
But what is the part that crashes chrome? Really the "a" or the fancy symbols in there?
Well, provided I'm not sure
what there is to fix, I'm not really that fond in fixing an issue about the crash of a browser that will be fixed in a week, while in the best case, considering for something like this I wouldn't change the release plan and our next would be in December, I guess by the time we release the fix, nobody will even remember there was such a bug in Chrome. ;)
Please don't be like Kindred, add sanitization of the URL. Once you told me the same, your turn now.
If there is something to sanitize.
ETA: and anyway, please, go lobbying the fix for chrome as well, because it's chrome that is "reacting" quite a bit overkilling for a malformed url. ;)
I'm not sure what crashes chrome specifically, but I did not think a single character FQDN was valid, go figure. I would have thought it would need at least a \.[a-z]{2,} but I have not checked the spec.
I'm not sure I used the correct specs, but:
let's see:
http://a/%%30%30
http://www.elkarte.net/%%30%30
http://a/something/%%30%30
http://a/%%30%29
http://a/%%30
http://a/%30%30
http://a/%30
Only the first one crashes here. (Off to dinner, will log back in a lot later though).
Only the first three (yeah, I added some on the way :P)crash chrome, so the problem is not the FQDN, but exactly this particular sequence of URL-encoded entities.
That said, that particular sequence is likely to be invalid, because %%30%30 => %00 => null char.
But, I think (and I may very well be wrong) detect this specific null char in an URL is gonna be rather tricky.
Yeah it's the null char
Is that the only way you can get that? If so, you could brutally use a preg_replace...
It's fixed in the last release but... Anybody? :/
Well, that's all good, the internet is not going to explode! :D
Jokes apart, this is really a browser specific issue that can be addressed and is meaningful only if addressed by the browser itself.
It doesn't crash on a null char in a URL, it crashes on a double-encoded null char in an URL. It's an internal problem, fix it "externally" would be more or less meaningless.
When I get home, I'm going to make it a change in my parser that will have a comment to remove it in a future version when the risk of people using this version of chrome is less.
Don't forget to make the PR of the parser to 1.1 O:-) Its awesome!