HOW FRCKN' HARD IS IT TO UNDERSTAND A URL?! - uXSS CVE-2018-6128

[@HorochovPL]

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

[@thechargeblade]

profit ? lol

[@Skyler827]

I mean, it was the best that they could do, especially since the condition would pretty much never occur on regular websites.

[@alimmi9]

@@Skyler827 Well it seems it did, because they deactivated this workaround because of too many false positive crashes.

[@JeppeBeier]

As far as I know many people make their living from discovering and reporting exploits, and possible fixes

[@undead2146]

Weird flex but ok

[@PainSled]

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".

[@sajayrrr]

Mate, damn, you are a genius, but I don't feel like you are gonna be appreciated much in this comment section :)

[@allenkay2419]

Let me appreciate him though....just made my work easier

[@brandonstevens6886]

wow this is underrated

[@PainSled]

​@@brandonstevens6886 I have to admit: Coming back and reading through the comments a couple of years later, makes me suspect that it might be rather uncommon to be able to read and properly understand the logical implications of ABNF specifications. *Hey, Google! PM me with a job offer, would'ya?*

[@brandonstevens6886]

@@PainSled Its more that you actually put the effort into a comment on youtube like this.

[@daab889]

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

[@jonny6702]

daab889 such an underrated comment lol

[@kratosgodofwar777]

#BrowseDifferent

[@CalvinBonner]

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!

[@rkan2]

“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..

[@simplylinn]

It's pretty high for a bug not even caused by the ones who paid up...

[@Klblaz]

It would be higher if Apple would pay for it, but they wont.

[@GreenyDe]

Well deserved for sure!

[@gavinkemp7920]

my understanding is major vulnerabilities would pay for atleast an other 0. as some have said they paid for something which wasn't their fault and to be fair the number of cases which could exploite this would be fairly rare.

[@rkan2]

Webkit is still probably as much Google's thing nowadays too..

[@OrangeC7]

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

[@MrNateSPF]

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

[@ShadowriverUB]

its still a thing in some protocols

[@NicolaiSyvertsen]

@@ShadowriverUB Because assuming an encrypted transport protocol (hello TLS!) that isn't really an issue. Which is why "everyone" switched back to basic authentication instead of digest authentication when switching to HTTPS for login pages.

[@chazy123]

​@@NicolaiSyvertsen Still, I think secrets should be hashed in the client, but I gave up a long time ago, can't do shit about it.

[@user-iq7xy8is3f]

@@ShadowriverUB yea but its Not Safe

[@antonidas159]

@@chazy123 By hashing secrets in client, password hash would work just act like real password, Since server does't know its hashed or copyed, its not really any safer for it

[@matrix8934]

I expected this url to be rick roll

[@LiveOverflow]

Only quality content on this channel!!!1!!1!1!

[@OopsieGoopsie]

exCUSE ME are you saying that rick astley isn't quality content

[@ducpham1478]

ExCUsE mE :D

[@Joevim]

kzbin.info/www/bejne/hnzFqX5of61labs

[@tsuki4737]

@@LiveOverflow how dare u unsubbed even tom scott did it /j

[@fuzzydark1395]

You just overcomplicated my life for no reason at all

[@retepaskab]

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

[@kmcat]

The only time, when testing it didn't crash.

[@Captain.Mystic]

the art is in making it crash when you want it to.

[@JeppeBeier]

It can be hard to make stuff crash on purpose sometimes.

[@Hati_0x]

Just divide by zero, the universal and ultimate computer operation! It's their kryptonite!

[@SylasTheGreat]

@@Hati_0x Not a quantum computer... They've surpassed us!

[@iTheoryon]

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).

[@Ben-ds3cm]

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

[@SuperMarkusparkus]

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.

[@SuperMarkusparkus]

One should also note that there is something called protocol-relative URLs: When a url starts with //hostname/ it will link to hostname/ if the URL originates from a web page, but otherwise https if the link is on web page. This can sometimes be used in open redirect vulnerabilities (that can be used to steal tokens and stuff) or just generally bypass filters (like in SSRF). If a website thinks it redirects to a relative URL because it starts with /, add an extra slash so it becomes double slash //hostname so it will take the user to http(s)://evil.com. The naive filter would then check for two slashes in the beginning of the URL to determine that it's a protocol relative / "absolute" URL that should be blocked. Too bad that many browsers will treat or \/hostname.com or /\hostname.com in the same way as //hostname.com or http(s)://hostname.com

[@oisins.6066]

Is the space a valid character?

[@TrancorWD]

I'd figure, while ' ' should become %20, with how cloodgy the network layer seems, it might become %20; in some cases? (I haven't tested anything) The host should be 2.2.2.2, but 3.3.3.3 seems half way logical to me.... I hate to say.

[@ckennedy0323]

@@TrancorWD According to RFC 3986: "In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted....For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace." As for the symbolism portion, + is a sub-delim while space can be formally inferred as %20. So I'm not sure. Maybe Python knows something I didn't find with my surface level research.

[@TrancorWD]

@@ckennedy0323 I'm glad there is formality there. %20 being the rule for interpretation. Thanks for the info! I guess I was figuring along the lines of html interpretation,   > < sort of thing

[@rGunti]

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

[@DJTimeLock]

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

[@Sky_Shaymin]

"I don't understand Python"

[@BoB-Dobbs_leaning-left]

Yeah, that parrot sketch was "Out There".

[@0x19]

OMG AFTER 4y OF BROWSING YT I FOUND YOU, SKY SHAYMIN :D

[@Gastell0]

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.

[@TheSpacecraftX]

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

[@Myx0]

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

[@nyaa]

Poor you, complaining about getting money.

[@mamupelu565]

dont even tell them next time

[@RAGHAVENDRASINGH17]

Can you teach me SSRF?

[@billigerfusel]

Report it to the NSA and get more.

[@tmpEngine]

exploit it and earn even more

[@Serverfrog]

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

[@astrix8812]

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

[@DrakiniteOfficial]

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

[@rysea9855]

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

[@Udok1306]

Are you an anime fan?

[@rysea9855]

@@Udok1306 Yeah, what about it?

[@steve1978ger]

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.

[@nxxxxzn]

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

[@Wazzaps]

Technically you can, but they cannot do JIT compilation because memory pages cannot be RWX. So you have to interpret the javascript which is ridiculously slow (and safari seems fast in comparison...).

[@ExEBoss]

*+David Shlemayev* But that would be against Apple’s Developer TOS and the browser wouldn’t be allowed on the App Store. Also, they might revoke your developer license.

[@dreamyrhodes]

Thanks for reminding me why Apple is shit and needs to be removed from this planet.

[@capkenway]

It gets more uglier. Check kzbin.info

[@alexnezhynsky9707]

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

[@hoola_amigos]

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

[@TheHermitHacker]

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.

[@RAGHAVENDRASINGH17]

1999 are u serious ? Please teach me too

[@misterg3tr3kt11]

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

[@MagicGonads]

@ is part of the fragment

[@Time4Technology]

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

[@singularity1130]

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...

[@Vogul]

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

[@vorea]

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.

[@Webtroter]

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

[@HappyBeezerStudios]

can already see the details: "order of reading depends on the language the url is written in"

[@Almostbakerzero]

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"?

[@doktoracula7017]

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.

[@fritzeyok]

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

[@evgenyaleksandrov1206]

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

[@MasterTop100]

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

[@NicolaiSyvertsen]

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.

[@rogercruz1547]

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.

[@DeusGladiorum]

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?

[@bluebaby30]

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

[@fuuryuuSKK]

"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

[@inseut]

Nah mate. His surname is Polish. "Tomash" is the correct pronunciation in Polish.

[@inseut]

But yes, if he were Hungarian it would be just like Tomas. :P

[@hazemght4654]

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

[@Acid31337]

They just working with it, and so, they know possible weaknesses.

[@meowwei6181]

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

[@kalleguld]

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

[@MaakaSakuranbo]

Yep!

[@TheAkashicTraveller]

Meanwhile firefox just decides nope not a URL and googles it.

[@sznio]

I think the fragment must come past `/`, so it isn't a URL in the first place.

[@kalleguld]

Dawid: I thought so too, but according to the spec at 1:44 the path-abempty isn't needed. There doesn't need to be a slash between the authority and the fragment

[@Dreamagine1]

Interesting. I had always thought that at least one forward slash was required before any queries or fragments

[@akirachisaka9997]

"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

[@kesuskim6072]

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

[@indiansoftwareengineer4899]

loved your channel, Please upload more&more content.

[@gillesottervanger9106]

Great video, still relevant today!

[@ALurkingGrue]

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

[@baganatube]

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.

[@FennecTECH]

the proper interpitation is ALWAYS the interpitattion that protects the user

[@TheGrimravager]

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)

[@MrHatoi]

There's a such thing as bugs. Just because there's a library that interprets it one way it doesn't mean that it's the correct way. To see if it's correct or not you have to read the standard.

[@Hati_0x]

While this could provide a solution, it's not ideal. Running the URIs through several different libraries/parsers means more code operating on edge-case URIs, which increases the chance of bugs and consequently possible exploits. It's a dirty hack-job really and not efficient, imagine having to run several duplicating code for everything you do. I'd stick to KISS (Keep It Simple, Stupid) and use one library, it's less work and more maintainable. Bugs and exploits will be fixed or can be hot-patched (like in the case of Chrome purposely crashing).

[@Shlonzs]

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

[@vypxl]

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

[@JochemKuijpers]

assert(false), or in this case, a similar-looking function, is used in situations of code that *should* be unreachable because certain combinations of values are impossible. It's good practice to have a control flow defined for all possible inputs, even if you cannot continue processing and just terminate or throw an error or whatever. Otherwise you will process data under false assumptions, which cause bugs. (Crashes aren't always caused by bugs)

[@darven]

Or "con\con" from the good old 95/98 times.

[@stewartzayat7526]

But crashing generally isn't a good sign. I believe your program should crash only when there's nothing better it can do, so that would include exceptional situations like your memory being corrupted, running out of memory, ...@@JochemKuijpers

[@Triavanicus]

@@stewartzayat7526 yeah, possibly redirecting to a browser specific page like about:newtab, or maybe a new one called about:hacks

[@LuizDahoraavida]

if (true && !false && true != false && false == false && true == !false) { //do stuff }

[@AliceinEntropy]

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.

[@MAHDEO]

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

[@snowpython]

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.

[@mskiptr]

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').

[@SayanGHD]

You are an inspiration to watch!

[@durchschnittlich]

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

[@dougfresh9574]

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.

[@zerobyter]

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.

[@abdulkabir3960]

[@ZipplyZane]

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.

[@lynski4033]

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.

[@fastexpand]

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

[@De-tp5mq]

After few minutes it all went over my head

[@jmalvares88]

This is my new favorite video

[@arthusu]

in which software do you edit the brother videos? by the way excellent video

[@ane150893]

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

[@PanadeEdu]

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

[@braveshine2579]

@0:21 anyone know what is the link address of this documentation?

[@JayVal90]

This is why you formally verify your semantics.

[@sevret313]

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

[@oscarchampion5842]

but it might be valid in some cases, eg ip = 1.1.1.1, user = 2.2.2.2, fragment = 3.3.3.3

[@payloadartist]

Mind blowing insights...

[@AzakaSekai]

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

[@ygx6]

I understand the basics of URLs, this video taught me more and helped me understand it better! You're a great teacher. (Make a video in German)

[@vnc.t]

15:23 i think this is an invalid url and has no correct answer as it does not follow the url format

[@CyberQuickYT]

Nice video, except the example about the xss is invalid: CORS (which requires the header Access control allow origin) can be easily bypassed by running a simple script like cors-anywhere.

[@JojOatXGME]

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?

[@-morrow]

all in the name of "user experience"

[@TheFrenchMansControl]

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

[@Microscraft]

Thanks for this great video !

[@rhbvkleef]

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.

[@limblamb6554]

awesome video, very well done

[@slinky7355]

@LiveOverflow Are you from Hannover?

[@almightyhydra]

4:00 should this not be serverside check (as well)?

[@LiveOverflow]

you can't check that on the server.

[@Hans5958]

Can someone explain me the last part of the video's answer?

[@humanbeing2730]

You did Comp Sci at TU Berlin, right? I'm currently doing that too :)

[@61Marsh]

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.

[@Cookie_Wookie_7]

You asked what is the correct interpretation of the URL at the end of the video wouldn't the correct interpretation be to throw a malformed URL exception

[@NexusGamingRadical]

It should really be 3.3.3.3 right? Its not really defined for what is right for multiple @ char but it seems right that way.

[@shubham_srt]

is that SOP (Same Origin Policy? )

[@azamrahman9768]

Incredible. Bravo

[@TheMan83554]

It seems to me that the issue at hand is ordering. The hierarchy part of the specification says "host name, @ symbol, username or password" but different parsers are misplacing where the username/password is and where the host is. Specifying host then username then password (and fixing libraries to match) would solve that part, right?

[@sakyb7]

Great explaination.! Learded a lot :-)

[@GreenyDe]

Very good video, THANKS!

[@ankk98]

What if someone forks the browser, modifies it to enable uxss?