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

[@daab889]

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

[@jonny6702]

daab889 such an underrated comment lol

[@kratosgodofwar777]

#BrowseDifferent

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

[@OrangeC7]

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

[@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!

[@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

[@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

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

[@fuzzydark1395]

You just overcomplicated my life for no reason at all

[@Ben-ds3cm]

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

[@rGunti]

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

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

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

[@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

[@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

[@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

[@TheSpacecraftX]

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

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

[@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

[@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?

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

[@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

[@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

[@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

[@hoola_amigos]

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

[@alexnezhynsky9707]

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

[@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

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

[@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?

[@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!

[@MasterTop100]

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

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

[@misterg3tr3kt11]

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

[@MagicGonads]

@ is part of the fragment

[@evgenyaleksandrov1206]

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

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

[@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"

[@kesuskim6072]

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

[@meowwei6181]

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

[@fritzeyok]

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

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

[@indiansoftwareengineer4899]

loved your channel, Please upload more&more content.

[@payloadartist]

Mind blowing insights...

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

[@braveshine2579]

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

[@FennecTECH]

the proper interpitation is ALWAYS the interpitattion that protects the user

[@limblamb6554]

awesome video, very well done

[@hazemght4654]

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

[@Acid31337]

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

[@MAHDEO]

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

[@bluebaby30]

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

[@abdulkabir3960]

[@azamrahman9768]

Incredible. Bravo

[@SayanGHD]

You are an inspiration to watch!

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

[@JayVal90]

This is why you formally verify your semantics.

[@gillesottervanger9106]

Great video, still relevant today!

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

[@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 }

[@Microscraft]

Thanks for this great video !

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

[@jmalvares88]

This is my new favorite video

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

[@GreenyDe]

Very good video, THANKS!

[@vnc.t]

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

[@TheFrenchMansControl]

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

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

[@De-tp5mq]

After few minutes it all went over my head

[@ane150893]

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

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

[@ALurkingGrue]

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

[@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

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

[@moth.monster]

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

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

[@almightyhydra]

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

[@LiveOverflow]

you can't check that on the server.

[@durchschnittlich]

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

[@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)

[@smorrow]

> 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

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

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

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

[@vypxl]

You forgot that rickrole in the beginning ^^

[@PanadeEdu]

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

[@unbanshee2985]

Don't think it matters which address is used in the example as long as everything your using is handling that address in the same way. that said using the first address e.g. 1.1.1.1 would probably be best IMO

[@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

[@dhananjaygarg9868]

Great video thanks

[@Shlonzs]

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

[@romeoaleem5763]

I love your videos ❤️

[@arthusu]

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

[@sakyb7]

Great explaination.! Learded a lot :-)

[@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"

[@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?

[@DarlanUllmann]

Ok, but a question that I have, and I had it in my mind in different cenarios as well, is -> What happens if I develop my own web browser? Even if it's a very simple web browser, what prevents me from using XSS all day? Also, can't I just change Chromium to not check for XSS exploits, compile it, and use?

[@Fayti1703]

Yes, but it wouldn't affect other people unless they used your web browser.

[@Hans5958]

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

[@msthalamus2172]

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

[@anselmschueler]

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"

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