>discover exploit >suggest fixing it with crash >get money!

"You are not browsing it right" - Apple, 2018

There is only one correct answer to this. (Though, please correct me if I'm wrong) According to section 3.2.2, "In order to disambiguate the syntax, we apply the "first-match-wins" algorithm: If host matches the rule for IPv4address, then it should be considered an IPv4 address literal and not a reg-name." Ignoring "scheme", the logic goes as follows: - "Hier-part" is prefixed with "//", so is defined as "authority path-abempty". - "Userinfo" matches only "1.1.1.1&", as it must come first, cannot contain an "@", and should therefore ignore the second one. - "Host" matches "2.2.2.2" as an IPv4address, and should stop there. - "Host" is not followed by ":", meaning port-number is absent, and the "authority" part has ended. - "Authority" is not directly followed by "/", therefore "path-abempty" is empty, and the "hier-part" has ended. - "Hier-part" is not directly followed by "?", resulting in no hit on the optional "query". But the "#" makes a hit on "fragment". - The entire URI is valid, as it is split up in correctly defined and ordered parts, and all are valid in both syntax and semantics. The only correct interpretation should therefore be as follows: Userinfo: 1.1.1.1& Host: 2.2.2.2 Fragment: @3.3.3.3/ We can follow these relevant ABNF syntax rules by the first-match-wins algorithm, in order to recognize these consequences: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / - / - / - authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = - / IPv4address / reg-name port = *DIGIT IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT / %x31-39 DIGIT / "1" 2DIGIT / "2" %x30-34 DIGIT / "25" %x30-35 ; 0-255 reg-name = *( unreserved / pct-encoded / sub-delims ) pchar = unreserved / pct-encoded / sub-delims / ":" / "@" fragment = *( pchar / "/" / "?" ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" Parts of rules not relevant to the case has been changed to a single dash(-) to lessen the info-dump. Appendix A of the standard contains the complete list. Note that any scheme may contain additional restrictions, further reducing the amount of valid URI's for that scheme. And according to section 3.1: "When presented with a URI that violates one or more scheme-specific restrictions, the scheme-specific resolution process should flag the reference as an error rather than ignore the unused parts".

“Award is so high”… 7500$ is not that high for such a critical bug, though it is a lot for a bug found in open source software..

9:08 I love this, "QUICK CRASH CHROME THERE'S AN ATTACK"

Ah, the good old days where the password was right in the url ;-)

As a front-end developer, I must admit that a good amount of this was not something that I am super familiar with. All the same, I feel like I really learned something here and I really appreciate you taking the time to explain things so clearly. In short, great video!

I expected this url to be rick roll

You just overcomplicated my life for no reason at all

Heh, it must've been fun to write code that _has to crash instead of _mustn't.

"What is the correct interpretation of this URL?" My answer: *CRASH* :P

9:50 “why does Chrome have to crash here instead of WebKit fixing it faster”. Even if Apple/WebKit fixed it the next day that would be a new iOS release, so anyone who didn’t update their phone’s OS would still be vulnerable. By updating Chrome it makes the fix available for everyone who doesn’t (or can’t depending on device).

2.2.2.2 is the hostname. Firefox and Chrome loads 2.2.2.2 and it makes sense. The & before the first @ doesn't have significant meaning, however '?' in the same place would since it would then start the query part of the URL. If # comes before @ it starts the fragment part and then the @ can no longer separate the username:password part from the hostname, everything after is the fragment.

"I don't understand Python"

I love your channel so much. Please never stop making videos!!

12:53 - He did it all correctly, Google cares about security of Google Chrome browser as it's brand is on it even if the issues is with non-google owned component, they have implemented a quick fix from their side to get this issue mitigated (alas not perfectly), while Apple will be fixing it from their side.

I'm credited for CVE-2016-5191, a bug that shares many similar characteristics. I only got $500 for it though. 😪

I had barely any idea what you were talking about for the most part (regarding the URL parsing) but I loved it regardless. Shows even small mistakes can have big concequences

I understood like, 20% of the video at most, but it was somehow still interesting

Many Things are are defined way back, like URI/URL, XML and so on. Have many "Features" that are defined to be a security issue in some future. Like XXE, which is a XML Parser just working on Spec. I found so many things where an old RFC definition just design a "feature" which is itself a security issue

Thank you for providing the text subtitle for that guy at the end. I really could not understand him.

So glad i found your video. I've been in web security since 1999 and this is one that i always wanted to learn more about. I don't mess around with web browser security much but I guess I just might from here on out. Very nice. Thanks and subbed.

Only $7500? ON A WORLD WIDE USED BROWSER?! AND APPLE DIDN'T PAY IT?! If that person wasn't a saint they would've gone down in History...

you can't run whatever web engine you want on ios browsers? thanks, didn't know ios/apple was THAT crappy.

The last url is so messy that it should just be regarded as a malformed URL and not lead anywhere.

I appreciate this ranty subject line and introduction, because it got me to watch this video and it was quite interesting.

Wow! I have just started to scratch the surface of computer security and this video just blew my mind! Thank you very much for sharing

The correct action would be throwing an error, since there are two @

per the RFC, the green part should be the host since it's immediately followed by a # making the blue part the fragment and the yellow part the username. While the RFC does not specify an error case anywhere, there are considerations for scheme-specific (HTTP in this case) error handling that could return no URI. tools.ietf.org/html/rfc3986#section-3.1 In this case because there is no forward slash between the host and the #, and there's no ? before the & in the first part, the parser should return a malformed http url error. The authority is always the text between the first // and the first @ since it does not specify anything else.

Just a day before I found this video I was trying to get a Regex to understand a super long URL with weird characters.

username is 1.1.1.1& hostname is 2.2.2.2 fragment is @3.3.3.3/

"Tomasz", assuming it's hungarian, is just pronounced like the german equivalent "Thomas", the corresponding graphemes in german and hunggarian are sch - s and s - sz

You totally rock man, keep them security videos coming! Very good job and interesting content 👍

New RFC is needed to define the unclear case of the URLs I think...

I can understand a URI fine. I just can't comprehend Backus-Naur Form. Give me a dozen examples over a terse BNF any day.

Probably someone mentioned it already, but I want you to know that "Tomasz Bojarski" is pronounced like "Toh-mash Boh-yar-ski". But still really good job. And thanks for the vid, it really shows that even if everything is defined one way it can be interpreted in many ways.

Only 7k? He could've made so much more by exploiting the bug or selling it to NSA 😂🤣

Thanks man ,, keep going ..someone tell me How these people thinking??

correct interpretation realise 2 different libraries interpret it differently, therefore it's ambiguous what is meant, and should return an error :) (I am more a physicist than a programmer anyway :P)

14:13 - My first answer would have been '2.2.2.2', because parsing it top-down, the '#' would delimit a 'fragment', and we get via 'hier-part' into an 'authority' where the '@' delimits a leading 'userinfo'. The spaces throw me off, though. The red rectangles are spaces, right? As far as I can see, these are not legal parts of a URL, so the whole thing should be rejected.

I’m confused as to why this is an XSS attack. XSS requires code injection such that the compromised site will then execute that injected code on behalf of the user, but I see no code injection occurring here. This sounds more like CSRF, where the user can visit a malicious website which will then change the user’s domain to that of the targeted website, thus allowing the malicious site to make valid requests (presumably also sending user cookies) to the targeted site, and now not being blocked by CORS, the request will be processed and authorized by the target server. Can someone explain what I’m missing?

the proper interpitation is ALWAYS the interpitattion that protects the user

That workaround seems like something I might make with no time lmao

I would assume left to right as the correct way to parse. Or we should do a new RFC to specify this.

CHECK(false) lol.. reminds me of my if(true) sometimes

"Ah, URLs, I know some stuff about computers, this should be easy!" My brain then proceeds to stop processing stuff after reaching 0:59. LiveOverflow : "Anyway the video haven't begin yet, those are all common knowledge you probably should already know." Me commit die

This is some quality quality content.. keep it up @LiveOverflow!

VERY INFORMATIVE. I was looking for that one for too long! Thanks a lot

This was soooo far above my head, but I enjoyed it, and it was very informative. Thank you.

Hey, looking at the Chrome Rewards page, it says one of the conditions for recognizing the Chrome bug is: "We'd also love to learn about bugs in third-party components that we ship or use (e.g. PDFium, Adobe Flash, Linux kernel). Bugs may be eligible even if they are part of the base operating system and can manifest through Chrome." www.google.com/about/appsecurity/chrome-rewards/ So really there was precedent before this.

How the heck this things can be such analyzed... I admire you :S

Well, this vid is fantastic! Thank you for such an amazing story of a really rediculous bug. LOL

Thank you for making those awesome explanatory videos! Keep it up!

The RFC only wants a single @ after user and password, the parsing happens from left to right so I would say the green part. RequestS is right in my eyes.

Yep. Thats it. Its official now that i dont understand a thing in this video

„I don’t think chrome can do better than crashing“ made my day 🤣🤣😜

I think the correct response to the URL at the end is to crash the browser :D

Wow, quite decent pronunciation of Polish names : D Most people seeing things like 'Tomasz' get really confused - what the heck is 'sz'? (in fact it's /ʂ/, slightly different, but kinda similar to English /ʃ/) And about 'Bojarski', the only thing you got wrong is 'j'. It's not read as /dʒ/, but rather as /j/ (like in English /jɛs/ - 'yes', not /dʒɛs/ - 'Jess').

One theme in security that pops up over and over: PARSING IS HARD!

I parsed it manually using RFC3986, the correct parse is: uri = "1.1.1.1 &@2.2.2.2# @3.3.3.3/" scheme = "http" hier-part = "//1.1.1.1 &@2.2.2.2" fragment = " @3.3.3.3/" userinfo = "1.1.1.1 &" host = "2.2.2.2"

1 should be the request because it carries the https (forgot the proper vernacular) There should be some sanitizer that checks for that prior to any other processing of the request.

Orange's network security talks are super interesting. I was at HITCON earlier this summer and his talk also involved URLs parsing inconsistency.

Great video, still relevant today!

The sad thing is, I am neither surprised nor shocked. If the world would know what code is out there...

This is why you formally verify your semantics.

Obviously, when the parsers dissagree, access both and hope one is right

great video! there recently was an article about a similar topic on heise, where they pointed out that the way our network stack interprets numbers also can be misleading. for example, who do you expect to reply when executing "ping 2130706433"?

I know this isn't what the video was about but I always wondered why data URIs were called URIs and not URLs and now I know

Apple: You can make a browser for iOS, but only if you use WebKit. Google et al. (chorus): ...But WebKit is full of security bugs...! Apple: We... like it that way! Hey, have you guys seen these six hundred dollar wheels? Oooh, shiny! Google (sotto voce): Wish Bill hadn't bailed them out in the 90s...

Does this kind of attack have anything to do with some attack that happened to some online store? I think it was newegg? Did you ever talk about that or could you? It was a few years back now I think.

If the browser is what prevents cross domain access, what stops a hacker from building their own browser that doesn’t stop it?

Mind blowing insights...

It sounds like a huge thing with this is not using the same URL parsing code within the same project. Even if they want to spool out the function for efficiency's sake, surely the same code should parse the same input.

> We went to lunch afterward, and I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, "We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'" multicians.org/unix.html

1.1.1.1&@2.2.2.2#@3.3.3.3/ "http" is the user, "//1.1.1.1&" would be the password, 2.2.2.2 is the host and # shows the page anchor thingy, after that @ sign would probably be converted to %40 by the parser and 3.3.3.3/ would be treated as the anchor.

Looking at RFC 4234, I cannot really find how ABNF defines the way this is parsed. I think it is an ambiguous grammar. If I would have to propose a decomposition, I would choose the one below, as it is the most intuitive for humans. - userinfo: "1.1.1.1&" - host: "2.2.2.2" - path: "" - query: null - fragment: "@3.3.3.3/" I very much disagree with urllib2 and httplib. The spec is quite clear about it, and 1.1.1.1 can't really be a host. 2.2.2.2 and 3.3.3.3 are both valid.

Why do they think there's an username and password in the URL anyway? Seems very specific

The other day I found Java class java.net.URI from the standard library doesn't meet RFC3986 examples, relative URI resolution to be specific.

loved your channel, Please upload more&more content.

Ive been told that if you open multiple pages in javascript, the first page has inherited access to the subpages. And this may be a reason why one link isnt allowed to open multiple tabs at once in chrome. I wonder if this is true, or just a bunch of bologna, and how it could be exploited. Time for me to do some research.

about "1.1.1.1 &@2.2.2.2 #@3.3.3.3/" "For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace.", so the whitespace should be removed resulting in: "1.1.1.1&@2.2.2.2#@3.3.3.3/" You can find the dissection of this url here: pastebin.com/11nLgsSx

Which is why I'm in favor of standards written in human language being replaced by proper source code ;)

You forgot that rickrole in the beginning ^^

You are an inspiration to watch!

After few minutes it all went over my head

Incredible. Bravo

requests should be correct answer, the first @ is the separator between user stuff and the domain. The RFC mentions that the domain part can contain any number of @ or any pchar really. Also having javascript function to modify history is dumb and web "engineers" deserve all the pain they get. There is no good reason to manipulate stuff outside your app, and reloading the page wouldn't be a problem if your page wasn't tons of javascript to execute this to begin with.

correct interpretation is obviously: make *URI 2.0* - completely not backwards compatible - clear and simple, with no crazy ways to hack anything - I had to work with URI once, it's a complete mess. I hate it. Suggested format: each segment must start with a label; if the label char is in data, it must be escaped; order doesn't matter; some segments can be repeated ( like / and ? ) %xx - escape &protocol$host:port/path/path/path?k1=2?k2=3@user#arbitraryExtraData (always start with % to differentiate from old URIs) - I probably forgot something: it could still be extended with !$^* (oh, and no password segment - duh) now, this is something I came up with in 2 min, so it's probably really bad, but I'm not going to write RFC that nobody is ever going to read. XD - But I wish we started to replace old weird broken standards with incompatible but well defined and safe ones... (like IPv6 - make sure you can recognize the old one and use it if needed, but let slowly everyone migrate to the new, better standard (IPv6 is not the best example, as people are not really migrating to it XD but you get my point))

2.2.2.2, because he # should tell the browser to access the part of the page with that label

awesome video, very well done

It seems Thomas used 100% of his brain :D

Can anyone explain to me why the ..; is important here? If it’s just the username you should be able to replace it with any string.

THANK YOU, SIR, FOR THIS VERY INFORMATIVE VIDEO. APPRECIATE IT !!!!

I used to exploit these types of url parsing bugs at school to bypass the internet content filter.

Based on what you showed, the definition would have the first @ be controlling. That would make the second ip address be the server. However, I would think that a password might contain an @ symbol, so, unless you he password is supposed to be URL-encoded, it would make more sense for the last @ to be controlling. But, really, the URL scheme should require URL-encoding for all reserved characters if they're not used in a standard way. [:@?#] should always be encoded except when performing their URL functions. (I think / can stick around as long as the rest are handled properly, as / is so useful.) Any scheme that has special characters with functions should escape the special characters when used outside that function.

Both, RFC 1738 and RFC 3986, don't allow "@" characters in the userinfo. See tools.ietf.org/html/rfc1738#section-3.1, and tools.ietf.org/html/rfc3986#section-3.2.1. And I think spaces are also not allowed. Therefore, the URL just isn't valid. So, the actual problem is that many URI libraries still try to accept URIs that are not valid?

Just use a xsrf token and validate it server side before all requests. And store it in a secure http only cookie that gets a refreshed token upon every successful request. Remember to sign your token with a strong cryptographic key algorithm.

Very good video, THANKS!

Maybe URL and URI standards can be replaced by something more API-oriented. For example, send JSON data instead of one string that contains everything needed.