HOW FRCKN' HARD IS IT TO UNDERSTAND A URL?! - uXSS CVE-2018-6128
ฝัง
- เผยแพร่เมื่อ 2 ต.ค. 2024
- URLs are surprisingly hard to read.
Chrome Bug: bugs.chromium....
Orange Tsai: / orange_8361
A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages! - CODE BLUE: • [CB17] A New Era of SS...
Slides: www.blackhat.c...
=[ 🔴 Stuff I use ]=
→ Microphone:* geni.us/ntg3b
→ Graphics tablet:* geni.us/wacom-...
→ Camera#1 for streaming:* geni.us/sony-c...
→ Lens for streaming:* geni.us/sony-l...
→ Connect Camera#1 to PC:* geni.us/cam-link
→ Keyboard:* geni.us/mech-k...
→ Old Microphone:* geni.us/mic-at...
US Store Front:* www.amazon.com...
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.
#CVE #SecurityResearch
>discover exploit
>suggest fixing it with crash
>get money!
profit ? lol
I mean, it was the best that they could do, especially since the condition would pretty much never occur on regular websites.
@@Skyler827 Well it seems it did, because they deactivated this workaround because of too many false positive crashes.
As far as I know many people make their living from discovering and reporting exploits, and possible fixes
Weird flex but ok
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".
Mate, damn, you are a genius, but I don't feel like you are gonna be appreciated much in this comment section :)
Let me appreciate him though....just made my work easier
wow this is underrated
@@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?*
@@PainSled Its more that you actually put the effort into a comment on youtube like this.
"You are not browsing it right" - Apple, 2018
daab889 such an underrated comment lol
#BrowseDifferent
“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..
It's pretty high for a bug not even caused by the ones who paid up...
It would be higher if Apple would pay for it, but they wont.
Well deserved for sure!
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.
Webkit is still probably as much Google's thing nowadays too..
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!
9:08
I love this, "QUICK CRASH CHROME THERE'S AN ATTACK"
You just overcomplicated my life for no reason at all
Ah, the good old days where the password was right in the url ;-)
its still a thing in some protocols
@@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.
@@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.
@@ShadowriverUB yea but its Not Safe
@@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
I expected this url to be rick roll
Only quality content on this channel!!!1!!1!1!
exCUSE ME are you saying that rick astley isn't quality content
ExCUsE mE :D
th-cam.com/video/PKbxK2JH23Y/w-d-xo.html
@@LiveOverflow how dare u unsubbed even tom scott did it /j
"What is the correct interpretation of this URL?"
My answer: *CRASH* :P
Heh, it must've been fun to write code that _has to crash instead of _mustn't.
The only time, when testing it didn't crash.
the art is in making it crash when you want it to.
It can be hard to make stuff crash on purpose sometimes.
Just divide by zero, the universal and ultimate computer operation! It's their kryptonite!
@@Hati_0x Not a quantum computer... They've surpassed us!
"I don't understand Python"
Yeah, that parrot sketch was "Out There".
OMG AFTER 4y OF BROWSING YT I FOUND YOU, SKY SHAYMIN :D
I understood like, 20% of the video at most, but it was somehow still interesting
Are you an anime fan?
@@Udok1306 Yeah, what about it?
I'm credited for CVE-2016-5191, a bug that shares many similar characteristics. I only got $500 for it though. 😪
Poor you, complaining about getting money.
dont even tell them next time
Can you teach me SSRF?
Report it to the NSA and get more.
exploit it and earn even more
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.
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
Is the space a valid character?
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.
@@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.
@@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
you can't run whatever web engine you want on ios browsers? thanks, didn't know ios/apple was THAT crappy.
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...).
*+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.
Thanks for reminding me why Apple is shit and needs to be removed from this planet.
It gets more uglier. Check th-cam.com/users/rossmanngroup
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.
The last url is so messy that it should just be regarded as a malformed URL and not lead anywhere.
but it might be valid in some cases, eg ip = 1.1.1.1, user = 2.2.2.2, fragment = 3.3.3.3
Only 7k? He could've made so much more by exploiting the bug or selling it to NSA 😂🤣
NSA already has your data and mine. It's a worthless bug for them
Apple Infinite loop It's funny that Google is near the NSA Headquarters, huh?
Doesn't the NSA pay somewhere in the range of a million dollars for serious vulnerabilities like that?
why dont he sell it to nsa then release it after being paid by them
@@rabbitdrink - That's how you end up in prison. At that point you're leaking "national secrets" and can be branded a traitor, the penalty for which can go all the way up to execution.
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.
You totally rock man, keep them security videos coming! Very good job and interesting content 👍
Orange's network security talks are super interesting. I was at HITCON earlier this summer and his talk also involved URLs parsing inconsistency.
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.
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
I love your channel so much. Please never stop making videos!!
How the heck this things can be such analyzed... I admire you :S
"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
Nah mate. His surname is Polish. "Tomash" is the correct pronunciation in Polish.
But yes, if he were Hungarian it would be just like Tomas. :P
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').
Thanks man ,, keep going ..someone tell me How these people thinking??
They just working with it, and so, they know possible weaknesses.
I would assume left to right as the correct way to parse.
Or we should do a new RFC to specify this.
can already see the details:
"order of reading depends on the language the url is written in"
Thank you for making those awesome explanatory videos! Keep it up!
CHECK(false) lol.. reminds me of my if(true) sometimes
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)
Or "con\con" from the good old 95/98 times.
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
@@stewartzayat7526 yeah, possibly redirecting to a browser specific page like about:newtab, or maybe a new one called about:hacks
if (true && !false && true != false && false == false && true == !false)
{
//do stuff
}
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...
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.
The correct action would be throwing an error, since there are two @
@ is part of the fragment
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)
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.
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).
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.
Well, this vid is fantastic! Thank you for such an amazing story of a really rediculous bug. LOL
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))
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?
username is 1.1.1.1&
hostname is 2.2.2.2
fragment is @3.3.3.3/
Yep!
Meanwhile firefox just decides nope not a URL and googles it.
I think the fragment must come past `/`, so it isn't a URL in the first place.
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
Interesting. I had always thought that at least one forward slash was required before any queries or fragments
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.
Yep. Thats it. Its official now that i dont understand a thing in this video
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"
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.
"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
I write code with a non-trivial amount of crashes
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.
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.
Which is why I'm in favor of standards written in human language being replaced by proper source code ;)
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.
2.2.2.2, because he # should tell the browser to access the part of the page with that label
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"?
Mhmm. Yep.
New RFC is needed to define the unclear case of the URLs I think...
Just a day before I found this video I was trying to get a Regex to understand a super long URL with weird characters.
Why do they think there's an username and password in the URL anyway? Seems very specific
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
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.
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
The correct interpretation is the intended non-greedy regular expression for the domain and greedy for the path, query and # fragment. For example google.com/someshit:pass@gmail.com/damn
A greedy interpretation has "google.com/someshit" as the username, "pass" as a password, "gmail.com" as the domain and "/damn" as the path.
A non-greedy interpretation would be "google.com" as the domain and "/someshit:pass@gmail.com/damn" as the path.
Greed priority should be (high to low): # fragment, ? query, / path, protocol : , domain.
Thank you for providing the text subtitle for that guy at the end. I really could not understand him.
Isn't 'hier' pronounce 'higher'? Like in hierarchy?
In German it's pronounced "hee-rarxh-ee", so I suspect that's why he pronounced it the way he did. Also, some abbreviations don't have a unanimously accepted pronunciation. Think about MySQL and how many people pronounce it "ES-QU-EL" vs "Sequel". Not really the best example but it shows there's not always just one correct way of saying it.
why did they invent such messed up syntax at first. thats complexity like 99.999% of webapps will never use.
in my apps i would safeguard urls rather with a simple regex only allowing that format i am actually using myself... so shitting on RFC.
apple should fix that problem or allow webkit for chrome.
I think the correct response to the URL at the end is to crash the browser :D
Why do the new generation thinks demons horns and evil is cool. Unsubscribe
1.1.1.1@&2.2.2.2#@3.3.3.3/
tools.ietf.org/html/rfc3986#section-3.1
SCHEME
> scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
http
is the scheme.
://
> The authority component is preceded by a double slash ("//") and is
terminated by the next slash ("/"), question mark ("?"), or number
sign ("#") character, or by the end of the URI.
// preceded by // YUP
// the first terminal character is the number-sign # so the authority is
1.1.1.1@&2.2.2.2#
// not quite sure from the text if the # is included in the userinfo. it certainly doesnt make sense to start a fragment before th ehost and it doesnt make sense to for a usercrednetials to have a hash.
// the only question is whether the text highlighted by me contains valid characters...(encoded etc)
tools.ietf.org/html/rfc3986#section-3.2.1
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
tools.ietf.org/html/rfc3986#appendix-A // grammar below identical except for removal of line breaks for clarity
> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
> pct-encoded = "%" HEXDIG HEXDIG
> sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
// The text i highlighted as authority definitely contains only characters in the definition of userinfo. There is NO colon in the text so there is no password component. Its just userinfo.
// then we have the at-sign which follows an authority that leaves 3.3.3.3/
// the host is therefore
3.3.3.3
Summary
userinfo=1.1.1.1@&2.2.2.2#
host=3.3.3.3
Advise from Apple:
Important
Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app. Do not use UIWebView or WebView.
developer.apple.com/documentation/webkit/wkwebview
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.
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
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...
That workaround seems like something I might make with no time lmao
I don't know where you're from but I always notice you say "origin" with the emphasis on the "ri", but I believe the emphasis should be on the "o".
If I'm not wrong, He is from germany
Correct interpretation to last weird URL should be error. NO WAY TO PARSE THIS WEIRD SHIT.
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.
The idea of putting credentials in the url in the first place is pretty braindead.
Or more broadly, as is common all over the web technology stack, mixing different sorts of data into the same code stream requiring all sorts of complicated escaping techniques (html, urls etc.). Framing is a whole lot better than escaping and much easier to implement reliably.
I think the main problem of this misinterpretation of URLs is because the fucking standard is very complex and hard to implement and interpret by humans
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.
I see disclaimer that author has limited access to video 🤔
why is this on my recommended
(net.uri:parse-uri "1.1.1.1 &@2.2.2.2# @3.3.3.3/") => error because space is not allowed in the host.
Google should invite FB and Apple for a meeting and then beat them all up. Netizens would be happy.
It reminded me of this email regex comparison (tr;dr - there is no ultimate regex for it): fightingforalostcause.net/content/misc/2006/compare-email-regex.php
If the browser is what prevents cross domain access, what stops a hacker from building their own browser that doesn’t stop it?
Here's the document he used at the beginning of the vid: datatracker.ietf.org/doc/html/rfc3986
I have absolutely no idea what this is about! Why is it recomended to me? Maybe you informatic geeks can solve this one for me! :D
loved your channel, Please upload more&more content.
If the spec was written by smart people it would simply have stuff ordered by precedence. Something like:
1) Everything in front of the first instance of : is the protocol
2) If the protocol is HTTP or HTTPS ignore everything after the first instance of #
3) the first @ separates the username from the domain. If there is an @ in the username it must be escaped as %40
etc
I wonder if their crash/fix could simply be bypassed by doing 𝖑𝖎𝖛𝖊𝖔𝖛𝖊𝖗𝖋𝖑𝖔𝖜.𝚌𝚘𝚖
apple sucks in general. I wouldn't take an iphone even if it were free with no strings attached.
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.
Wow what the fuck. This as just convince to ALL ways do update.
I'm surprised you don't have to pay Apple for each bug you report to them
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.
1999 are u serious ? Please teach me too
Nice video, I suggest to change the title a bit tho
is that SOP (Same Origin Policy?
)
Simple. Just fork Google Ultron and re-write it to ignore cross domain javascript url requests...
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.