Google is constantly changing, so errors can always pop-up. But that's also why Google invests a lot of money into bug-bounty, so researchers like Masato get paid for it ;)
He made a video explaining XSS (using an XSS bug in a twitter client as an example because it was recent at the time) and in it claimed that google is trustworthy as a company that is safe and wouldn't allow XSS. That inspired people to try and get XSS working on google
Unbelievable that Google had an XSS like that. Really interesting attack and great explanation, was really easy to understand. I hope Masato got a big bug bounty.
@M. de k. But to be honest, for 3000$ I'd have kept it a secret and used it to rickroll as manny people as possible. The faces of my coworkers would have been priceless.
M. de k. Hi, i am curious, who does he get the bounty? Google see his tweet and verify it is a bug then give him money? Or he needs to report it to google?
Amazing vulnerability! Loosely parsing html always seems silly to me. If browsers started being strict about displaying html, people would start being strict when writing it.
@@JochemKuijpers or adding textnodes instead of using innerhtml in the first place. there was probably some reason they needed a limited set of tags though.
I actually do that a lot for webscrapers. It is faster than an actual XML/HTML parser and it doesn't make much of a difference when it doesn't have to be hundred percent accurate. Although, if one of my download tool gets outside input, I should abstain from these methods, because someone could inject something. Although the worst case scenario in that case is that wrong data gets downloaded.
I think they are using it too. Most language parsers somehow use regex. 😁 BTW I think regex is one of the perfect examples on how amazing things were created in the old days, when they had no clue how important it will be, and they cared to do these algorithms the best possible way.
I think this is honestly, one of the best channels on TH-cam. The time you put in to explain and share what you learn with us is GOLDEN! thanks dude. I'll support.
Feature toggles are there to fix it in the future, you will be able to remove the old browser features that you don't use to prevent potential vulnerabilities.
I think it's been on the OWASP top 10 for years. All of the bugs I've found through hackerone, or what have you have been XSS vulnerbilities. Some found within 30 minutes. More like there will be a few XSS vulns discovered every day. (perhaps not on Google, though).
@@tf2excession I know, some Intel cpus even have a "god mode" instruction that can execute any instruction, and it wasn't even in the manual, it was probably there for debug purposes and they forgot to remove it.
We should at least have the option of only parsing correct HTML. I wouldn't mind having an experimental flag in my browser for it which I could turn on whenever I see fit.
Yeah, it really doesnt make sense to even handle html at that point. But the vulnerability was only possible on the querystring tho, if I understood correctly, there must be a reason for accepting html there.
With the second example with the invalid code, the browser was correct. tags are CDATA, meaning that the contents will never be interpreted as HTML. It also means they cannot be self closing. It is not because of parsers. With both examples, the browser is not being "weird". It is following the W3C spec, which states that scripts are CDATA, and that browsers must auto-close tags. BTW, great video!!!
Browsers should phase-out HTML correction. If a website requires inserting HTML tags, it should inform the user with some yellow bars at the top like the "prevented to open a window" message. There should be a config option to this like "notify", "ask", "reject", making the notify the default now, then after a year or two, making the "ask" the default, which should be as hard to click through as an invalid TLS cert. window. Really, pages without matching open/close tags and with syntactically bad javascripts are a major thing, errors should really be show up to the users, which will motivate companies to fix their annoying websites, then after a time it should not be allowed to work like nothing happened. No need to be as strict as certain required attribute missing or something semantically wrong trigger it, but if the structural syntax is broken, missing closing tag, closing braket, closing quote or so happens, it should not be rendered to the user at all.
Nah it will just make users angry at the browser. They don't understand this and they don't have to. Opening up some old forums page from 2005 (which is way more likely to have these issues than sites that are actually still maintained well enough to fix it) is no hazard (unless you download stuff) and yet you wanna show the users all kinds of warnings? Worst idea I've ever heard. On the web, "breaking" stuff is a bad idea. Even just making https the default with warnings for http sites was a major discussion, and that's much less obtrusive than what you propose.
If they do that a lot of websites won't work. Just run any HTML validator on almost any website and you will get dozens of errors. One of the pains of these web architectures is that they should be backwards compatible and cross-browser.
@@karlkastor yeah, that's why versioning was invented at some point. Just put some "strict" flag, tell non-strict is deprecated and support will be dropped by browsers starting from 2030, don't add new features in permissive mode, and you just improved the web by 999%.
@@karlkastor Yes I know. That's why I made the half-ironic :P at the end. I know browser vendors won't do it, because ultimately their product will be the one "that does not work", but in my opinion the idea of accepting a word that isn't in the formal language you are parsing is absolutely insane. I mean we _say_ we use this particular language (html) but in practice every vendor implements a client for a MUCH broader language that isn't even close to the original one. And this behavior isn't even a bug but absolutely intentional. I just don't like it :D
It depends on the what makes the html invalid. e.g. ignoring some mandatory attributes (img alt) may be fine, but guessing/closing tags is just plain evil imho.
New Facebook games may be an opportunity to hunt down bugs similar to this, they are quite often hurried through, especially the ones by smaller teams of programmers. I got one before, managed to insert html to play a TH-cam video offscreen (for the sound effects). It actually got a laugh out of the programmers of the game before they fixed the issue - there were a ton of other bugs too, that I helped get removed before the game was attacked by someone else. No reward money though, but earned some kudos, none-the-less.
Im pretty new to all this but from what can follow. The writes the script in a way that the paser fixs rewrites the script. Now the wbsite thinks its okay put it just help script to work and take over .
@@luizzeroxis Yeah but quick and dirty pages mean the browser has to guess what you actually meant, and introduces these security issues. Why should your convenience come at the cost of others security? Obviously this isn't just targeted at you, half the web probable contains invalid HTML etc., but if people actually took the time to check their code was well formed then browsers wouldn't have to 'guess', removing an entire class of security exploit.
@@amunak_ The saying used to be, "Be conservative in what you send, be liberal in what you accept". But experience has shown that this leniency in what you accept results in bad data getting incorporated into future versions and standards. It sets up an incentive to make an effort to parse bad data so you're not the program that can't display site X. Over time, it gets rolled into standards.
Wait... I can get the point of needing styles in HTML emails, there one would need to have some HTML tags. But why did they not just escape any and all unsafe characters in the search bar - you know, replace "
Hello, thank you for the very informative video, it was well explained, but I havent quite grasp the point about the XSS problem in that case. I see that you basically alter the HTML of the server to get some JavaScript executed. But as long as you dont get googles servers to execute that it should be relatively harmless right? You could even use like ctrl+shift+i in google Chrome to get your browers debugging and can change any HTML attribute add Scripts and what not which would get to the same result. As you have shown in the video. I am aware that if you happen to be able get your scripts embedded into the youtube comment section by just posting it there it will be executed by the clients of every user that watches the comments. So this indeed is a huge problem. But what exactly do you gain by executing java script on your client in your googles search bar? Because there is only you who would see it. Sending someone a link similar to what you got at the start of the video is of course an option, but so would any other link of a site you have control over. with a similar looking URL also its not quite seamless as you had to click into the search bar to get it executed. could you or someone else please explain it to me?
This is a newly exploitable bug due to fixes for IE that were coded incorrectly, so it was never always possible, just a recent change that has been reverted.
@@JochemKuijpers incorrect, it was badly coded compatibility fixes made to address rendering for Nintendo switch. It was about 5months in prod before rollback. Edit: my bad english on first comment, I meant Googles js had fixes to address IE compatibility 5/6months ago.
A few years ago TH-cam had an issue where if you just put two script tags in a row (I think?) one could slip through. Lots of sites also just do a single pass stripping bad tags, which fails when given [scr[script butts]ipt ...]
Browsers should add support to new optional header, which would fully disable any DOM corrections - for companies like google it only produces problems.
What blows my mind is the bounty he'll probably get on this. XSS in Google's home page is a no-no. Browsers are kind of those weird machines. So much going on.
So maybe I missunderstood something, but why is it possible to enter HTML inside the Google Search bar that gets interpreted somehow? Is there any valid reason? From a Search Engine I expect, that everything that is entered in the search field gets "interpreted" as Text I am searching for. And the example with Webmailers shows me, that we definitely need a different Standard for those types of Input, that is not HTML. Something like Markdown or so. But not HTML that can cause Problems in Browsers.
@Michael Murphy But why the heck is google still trying to do so? That doesn't make any sense to me. Because from how I understood that, by default the text inside a input field is not interpreted anyway.
I know what you are coming from, Because that string does not make any sense even for a developer like me, The end-tags are on the wrong places & it are two end-tags missing! It should look like this: '' '' If this wasn't an *xss* script! // Swedenstyle34
So then my question is: Why, in God's name, should the browser still interpret bad code? Wouldn't be easier if everything was always interpreted using whatever strict/pedantic flag the interpreter has?
@@Blazagg I have no idea where/how it started, but it's so deep that some of them are part of HTML5 specification. html.spec.whatwg.org/multipage/parsing.html#parse-errors My best bet is that in early days there was no formal standart and/or sophisticated html editors, so browsers implemented very loose parsers, so non tech-savy users have less problems with creating their home pages.
2:53 neither html, head or body are required elements for valid html. in a minimalistic webpage, only the title element is required. Also, we're kinda talking here about code embedded into an already existing site, so the validity only comes down to "broken" tags and non escaped characters () inside an attribute.
But its in a [string]- ohhhhh. EDIT: ...wait search bar only filters & and " ? uh-oh Uh-Oh UH-OH EDIT 2: hmm nvm looks secure, also the unit tests were sanitizing & and "
According to the Mozilla page on document.template, Internet Explorer doesn't support it. Does that mean no-one should be using Internet Explorer? I certainly don't use it, and haven't for years, with it's reputation for being the most attacked browser. I always thought the use of IE was just to download a much better browser... (Windows users only of course, but there are millions out there). I though IE had been replaced with the 'Edge' browser now, but IE is still downloadable from Microsoft.
It seems XSS is just basically impossible to prevent, the only solution is to dump HTML and JavaScript and PHP and replace them with something much more simple and sane that treats user input string as a string and nothing fucking else, not a tag, not a script. Like normal not-web based programs. It baffles me how web standards are so bloated and insecure when Internet is the place where the most critical security is arguably needed.
To understand the strictness ( or lack of it ) of html we've gotta go back in time, check out this video with Prof. Brailsford th-cam.com/video/RH0o-QjnwDg/w-d-xo.html
How can i get to understand what is this dude is talking about? This sound so advanced that i couldn’t understand this whole thing. Where should i start at? 💔
Because HTML is bloated, XSS is one of the vulnerabilities that still happens because of a reason, SQL Injections for example are easy to avoid, and they happen only when programmers knows nothing about security, but until we will replace HTML with something less bloated and maybe a little bit more strict, we will have XSS
I blame Tom Scott for this since he said that Google was fine in a video about XSS. He probably inspired people to try it.
Google is constantly changing, so errors can always pop-up. But that's also why Google invests a lot of money into bug-bounty, so researchers like Masato get paid for it ;)
blame Tom Scott
Can you give us a little bit of context? What did Tom Scott do?
He made a video explaining XSS (using an XSS bug in a twitter client as an example because it was recent at the time) and in it claimed that google is trustworthy as a company that is safe and wouldn't allow XSS. That inspired people to try and get XSS working on google
It was the self-retweeting tweet video, wasn't it?
Google: HEY HEY! STOP!
Me: What?
Google: 1
Unbelievable that Google had an XSS like that. Really interesting attack and great explanation, was really easy to understand. I hope Masato got a big bug bounty.
@M. de k. Don't you think thats way to little? He could have overtaken the internet and make Billions with this XSS in less than a day...
@M. de k. Hmm, yeah you're right I guess.
@M. de k. But to be honest, for 3000$ I'd have kept it a secret and used it to rickroll as manny people as possible. The faces of my coworkers would have been priceless.
@@abc321meins then you'd be persecuted and no money...
M. de k. Hi, i am curious, who does he get the bounty? Google see his tweet and verify it is a bug then give him money? Or he needs to report it to google?
Amazing vulnerability! Loosely parsing html always seems silly to me. If browsers started being strict about displaying html, people would start being strict when writing it.
Sadly xhtml died a sad death
or just give option to websites to opt-out from corrections, and make browser render html 1:1.
That's kind of a feedback loop, browser vendors do not want their browsers to stop working on a lot of site unexpectedly.
@@omri9325 Maybe we can write some extensions/plugins for major browsers that parse everything as xhtml...
I got goosebumps when the alert(1) opened.
Cedric Brandt
1
Alert: (1)
[OK]
@@pseudoforceyt AaaaaAAAAAAAA
@@termviewerthelost75 nmn n m n m n m
When you literally hacked Google and everyone else thinks it's just an April fool's joke.
Achievement unlocked: Hacking Google.
문동선 you can’t hack websites with XSS
@@alandosman5002 yet you know you're hacking it when you find an exploit like that
@@문동선-j7d its an exploit, more of a bug or easter egg of sorts, not hacking
@@cyborggoat2467 what do you think is hacking then?
@@MrGrazyD96 literally getting into their servers, being able to see what they see, break it if you so chose
So, in conclusion:
1.) Sanitizing should be done on the client, because its hard to do on the the server.
2.) Woops!
3) The noscript tag is parsed differently depending on context.
4) replacing all with their appropriate html entities before DOM insertion would have fixed this.
5) ok lets filter & and " but not < or > .
@@JochemKuijpers or adding textnodes instead of using innerhtml in the first place. there was probably some reason they needed a limited set of tags though.
wouldn't filtering < do everything?
I'm new at XSS please help
I always use regular expressions to parse HTML! :P
😂🤣
I actually do that a lot for webscrapers. It is faster than an actual XML/HTML parser and it doesn't make much of a difference when it doesn't have to be hundred percent accurate. Although, if one of my download tool gets outside input, I should abstain from these methods, because someone could inject something. Although the worst case scenario in that case is that wrong data gets downloaded.
I think they are using it too. Most language parsers somehow use regex. 😁 BTW I think regex is one of the perfect examples on how amazing things were created in the old days, when they had no clue how important it will be, and they cared to do these algorithms the best possible way.
"Regex" and "parse" in 1 sentence... My hearth stopped beating.....
Evil RegEx input is coming at you muahahahaahah
i was looking at memes how i am here?
Stay a while, this dude does some cool stuff.
@@Jcraft153
Is he German, because he sounds so.
He must be using some unknown exploit in youtube recommend algorithm. ;)
00:52 basics XSS 05:10 mutation XSS 05:35 Client-side sanitization, DOMPurifiy 07:47 masato, noscript element 10:38 DOM XSS
LiveOverflow: "Google search is arguably the front page of the internet"
Reddit: *sad noises*
He’s not the copypaste machine, he’s the one who makes the exploits
Reference to your older video 🙃
Masato is a browser bug machine!!!
LiveOverflow thanks for the heart and reply :3
Copypasting is also boring just create something to do it for you if you really want to
Keep making websecurity videos keep up the good work
Idk how I got here... Idk what's going on. I feel incredibly stupid.
Programmers
no
@@realcartoongirl thx, that explains everything
same bro same
I think this is honestly, one of the best channels on TH-cam. The time you put in to explain and share what you learn with us is GOLDEN! thanks dude. I'll support.
Thankfully there is a javascript framework for everything :D
Now this is scary how many sites use the template parser, which appears to be vulnerable
attacker's dream
Anyone else who had their Google assistant Google JavaScript for you at 12:23 ?!
Did you guys notice at 0:05, when @LiveOverflow puts quote it says "I put ' it gives bug" (a video by Liveoverflow, easter egg)
Actually 🤔
"Google search is arguably the front page of the Internet"
*reddit ceo is angry*
I don't understand anything but it's still sooooo interesting xD
Gutes Video
HTML has reached a critical mass of bloat that there will always be a XSS vulnerability discovered every year.
Yeah, it's a real fustercluck. I think there are other tags that parse differently, such as xmp.
Feature toggles are there to fix it in the future, you will be able to remove the old browser features that you don't use to prevent potential vulnerabilities.
At this point, I wish that XML5 would be worked on: github.com/whatwg/html/issues/4436
That would solve a lot of these problems.
I think it's been on the OWASP top 10 for years. All of the bugs I've found through hackerone, or what have you have been XSS vulnerbilities. Some found within 30 minutes. More like there will be a few XSS vulns discovered every day. (perhaps not on Google, though).
@@tf2excession I know, some Intel cpus even have a "god mode" instruction that can execute any instruction, and it wasn't even in the manual, it was probably there for debug purposes and they forgot to remove it.
Browsers should only parse strict and correct HTML.
That would break the internet
@@LiEnby where are the days of XHTML, those sitty hipster kids with their shitty HTML5 and fancy CSS3
In a perfect world.
@@UltraNyan what we would like and what we can acturally do are completely different things..
We should at least have the option of only parsing correct HTML. I wouldn't mind having an experimental flag in my browser for it which I could turn on whenever I see fit.
search encrypt as an interesting approach to sanitizing their search requests.... it just takes out any < and > :D
Just escape the quotes and "greater than"/"less than" tags. Google doesn't need to parse HTML anyways.
agree
Yeah, it really doesnt make sense to even handle html at that point. But the vulnerability was only possible on the querystring tho, if I understood correctly, there must be a reason for accepting html there.
With the second example with the invalid code, the browser was correct. tags are CDATA, meaning that the contents will never be interpreted as HTML. It also means they cannot be self closing.
It is not because of parsers.
With both examples, the browser is not being "weird". It is following the W3C spec, which states that scripts are CDATA, and that browsers must auto-close tags.
BTW, great video!!!
Browsers should phase-out HTML correction.
If a website requires inserting HTML tags, it should inform the user with some yellow bars at the top like the "prevented to open a window" message. There should be a config option to this like "notify", "ask", "reject", making the notify the default now, then after a year or two, making the "ask" the default, which should be as hard to click through as an invalid TLS cert. window.
Really, pages without matching open/close tags and with syntactically bad javascripts are a major thing, errors should really be show up to the users, which will motivate companies to fix their annoying websites, then after a time it should not be allowed to work like nothing happened.
No need to be as strict as certain required attribute missing or something semantically wrong trigger it, but if the structural syntax is broken, missing closing tag, closing braket, closing quote or so happens, it should not be rendered to the user at all.
Nah it will just make users angry at the browser. They don't understand this and they don't have to. Opening up some old forums page from 2005 (which is way more likely to have these issues than sites that are actually still maintained well enough to fix it) is no hazard (unless you download stuff) and yet you wanna show the users all kinds of warnings? Worst idea I've ever heard. On the web, "breaking" stuff is a bad idea. Even just making https the default with warnings for http sites was a major discussion, and that's much less obtrusive than what you propose.
having paused the video at 2:50
What the browser _should_ do, is saying:
"Malformed document. Aborting execution."
:P
If they do that a lot of websites won't work. Just run any HTML validator on almost any website and you will get dozens of errors. One of the pains of these web architectures is that they should be backwards compatible and cross-browser.
@@karlkastor yeah, that's why versioning was invented at some point. Just put some "strict" flag, tell non-strict is deprecated and support will be dropped by browsers starting from 2030, don't add new features in permissive mode, and you just improved the web by 999%.
@@karlkastor
Yes I know. That's why I made the half-ironic :P at the end.
I know browser vendors won't do it, because ultimately their product will be the one "that does not work", but in my opinion the idea of accepting a word that isn't in the formal language you are parsing is absolutely insane. I mean we _say_ we use this particular language (html) but in practice every vendor implements a client for a MUCH broader language that isn't even close to the original one. And this behavior isn't even a bug but absolutely intentional. I just don't like it :D
Karl Kastor Haha, nah. Fuck them.
It depends on the what makes the html invalid. e.g. ignoring some mandatory attributes (img alt) may be fine, but guessing/closing tags is just plain evil imho.
"Google is obviously the front page of the internet"
Reddit? You're not going to argue?
This is brilliant, and the vid goes so deep and thorough on the topic. You really are the best security channel on YT.
I Love It! Your explanation is intuitive and easy. It is very helpful for studying!
Why not use xhtml so if something breaks you don't get anything at all?
Can this be used for malicious stuff?
New Facebook games may be an opportunity to hunt down bugs similar to this, they are quite often hurried through, especially the ones by smaller teams of programmers. I got one before, managed to insert html to play a TH-cam video offscreen (for the sound effects). It actually got a laugh out of the programmers of the game before they fixed the issue - there were a ton of other bugs too, that I helped get removed before the game was attacked by someone else. No reward money though, but earned some kudos, none-the-less.
Im pretty new to all this but from what can follow. The writes the script in a way that the paser fixs rewrites the script. Now the wbsite thinks its okay put it just help script to work and take over .
Is there any benefit of fixing invalid html code?
I cannot find any. I think that pages should be blocked by browser.
It's less annoying when you just wanna make a quick and dirty page. I don't even use the html, head, and body tags, they don't really have a purpose.
We need a "use strict" for html
@@luizzeroxis Yeah but quick and dirty pages mean the browser has to guess what you actually meant, and introduces these security issues. Why should your convenience come at the cost of others security? Obviously this isn't just targeted at you, half the web probable contains invalid HTML etc., but if people actually took the time to check their code was well formed then browsers wouldn't have to 'guess', removing an entire class of security exploit.
Backwards compatibility.
However there should definitely be a mechanism to disable this behaviour, just like we have CORS headers.
@@amunak_ The saying used to be, "Be conservative in what you send, be liberal in what you accept". But experience has shown that this leniency in what you accept results in bad data getting incorporated into future versions and standards. It sets up an incentive to make an effort to parse bad data so you're not the program that can't display site X. Over time, it gets rolled into standards.
April Fools? (Idk for real)
EDIT: Wow! 8 likes?!
Wait... I can get the point of needing styles in HTML emails, there one would need to have some HTML tags. But why did they not just escape any and all unsafe characters in the search bar - you know, replace "
Was thinking the same Google search doesn't let you do custom styling anywhere lol
Just ...
agree
just why??????
"Google is arguably the front page of the internet"
Reddit would to have a word with you.
PFFT
epic upbboated xD
edit: thanks for the gold sir
r/ihavereddit
Hello,
thank you for the very informative video, it was well explained, but I havent quite grasp the point about the XSS problem in that case. I see that you basically alter the HTML of the server to get some JavaScript executed. But as long as you dont get googles servers to execute that it should be relatively harmless right?
You could even use like ctrl+shift+i in google Chrome to get your browers debugging and can change any HTML attribute add Scripts and what not which would get to the same result. As you have shown in the video.
I am aware that if you happen to be able get your scripts embedded into the youtube comment section by just posting it there it will be executed by the clients of every user that watches the comments. So this indeed is a huge problem. But what exactly do you gain by executing java script on your client in your googles search bar? Because there is only you who would see it.
Sending someone a link similar to what you got at the start of the video is of course an option, but so would any other link of a site you have control over. with a similar looking URL also its not quite seamless as you had to click into the search bar to get it executed.
could you or someone else please explain it to me?
Humans still working on google, don´t expect everything to be perfect...
How do i Remove Code? I just add a bunch of letter to ruin the code. Like instead of id do lol
😂
Isn't there like a big bounty on exploiting Google? Did he get any money?
Can confirm that this also works on Firefox version: 66.0.2 (64-bit)
This is a newly exploitable bug due to fixes for IE that were coded incorrectly, so it was never always possible, just a recent change that has been reverted.
Recent change? IE hasn't been updated for years. That bug fix was pretty old too.
@@JochemKuijpers incorrect, it was badly coded compatibility fixes made to address rendering for Nintendo switch. It was about 5months in prod before rollback.
Edit: my bad english on first comment, I meant Googles js had fixes to address IE compatibility 5/6months ago.
interesting exploit, it shows that even big companies can suffer from these things
A few years ago TH-cam had an issue where if you just put two script tags in a row (I think?) one could slip through.
Lots of sites also just do a single pass stripping bad tags, which fails when given [scr[script butts]ipt ...]
Browsers should add support to new optional header, which would fully disable any DOM corrections - for companies like google it only produces problems.
One day I'll open a LiveOverflow video and suddenly a alert will pop up. One day some random user will make it.
I will remember your words
i always use markdown to style text inputed by user
Why doesn't this work for me?
What blows my mind is the bounty he'll probably get on this. XSS in Google's home page is a no-no.
Browsers are kind of those weird machines. So much going on.
Lol, you're on the money.
Xss
I Just Hope something replaces HTML
So maybe I missunderstood something, but why is it possible to enter HTML inside the Google Search bar that gets interpreted somehow? Is there any valid reason? From a Search Engine I expect, that everything that is entered in the search field gets "interpreted" as Text I am searching for.
And the example with Webmailers shows me, that we definitely need a different Standard for those types of Input, that is not HTML. Something like Markdown or so. But not HTML that can cause Problems in Browsers.
@Michael Murphy But why the heck is google still trying to do so? That doesn't make any sense to me. Because from how I understood that, by default the text inside a input field is not interpreted anyway.
Every time i watch your videos i keep another mind as a spare, to replace the blown mind. thank you
yeah but why not, you know, htmlentities?
Me: - not knowing dick about programming -
TH-cam: yo watch this video about programming.
holy f that debugger tip at 10:26 blew my mind! thanks!
I've worked in javascript for too many years and not known that... god damn
Same here :D lol
How come the biggest tech companies still get these kind of errors?
I'ts a full time job to find backdoors and bugs snuck into systems we rely on every day.
I know what you are coming from, Because that string does not make any sense even for a developer like me, The end-tags are on the wrong places & it are two end-tags missing!
It should look like this:
''
''
If this wasn't an *xss* script!
// Swedenstyle34
Yes i was correct! :D
So then my question is: Why, in God's name, should the browser still interpret bad code? Wouldn't be easier if everything was always interpreted using whatever strict/pedantic flag the interpreter has?
Because you can't just cut out half of the web if you want someone to use your browser.
@@niter43 But then, why would the browsers allow such things in the first place? (speaking about the very early days)
@@Blazagg I have no idea where/how it started, but it's so deep that some of them are part of HTML5 specification.
html.spec.whatwg.org/multipage/parsing.html#parse-errors
My best bet is that in early days there was no formal standart and/or sophisticated html editors, so browsers implemented very loose parsers, so non tech-savy users have less problems with creating their home pages.
2:53 neither html, head or body are required elements for valid html. in a minimalistic webpage, only the title element is required. Also, we're kinda talking here about code embedded into an already existing site, so the validity only comes down to "broken" tags and non escaped characters () inside an attribute.
The first example should not work at all. It should not be interpreted at all.
That is the reason why I always send the XHTML header.
But its in a [string]- ohhhhh.
EDIT: ...wait search bar only filters & and " ?
uh-oh
Uh-Oh
UH-OH
EDIT 2: hmm nvm looks secure, also the unit tests were sanitizing & and "
I'm so fucking not ready for anything front-end related. Front-end used to be so simple, there was nearly no need for security measures...
Good tutorial, interesting title music...who is it BTW?...👍👍👍👍👍
According to the Mozilla page on document.template, Internet Explorer doesn't support it. Does that mean no-one should be using Internet Explorer? I certainly don't use it, and haven't for years, with it's reputation for being the most attacked browser. I always thought the use of IE was just to download a much better browser... (Windows users only of course, but there are millions out there). I though IE had been replaced with the 'Edge' browser now, but IE is still downloadable from Microsoft.
But, can i just do htmlspecialchars() to prevent it ??
i was realy interested in this until i realised he sounds a little like Claus from American dad. i cant concentrate now
It seems XSS is just basically impossible to prevent, the only solution is to dump HTML and JavaScript and PHP and replace them with something much more simple and sane that treats user input string as a string and nothing fucking else, not a tag, not a script. Like normal not-web based programs. It baffles me how web standards are so bloated and insecure when Internet is the place where the most critical security is arguably needed.
So, js developers still don't read the documentation, but teach others. Just use document.createTextNode("")!
Instructions unclear
Ended up DoS Google servers
How did i get here?
I dont understand anything
Mizistein Welcome... Red Pill or Blue Pill? This is where you decide
i think he got $13,337 max. that akward comment google's love for l33t language cut down your bug bounty payout, lol
To understand the strictness ( or lack of it ) of html we've gotta go back in time, check out this video with Prof. Brailsford th-cam.com/video/RH0o-QjnwDg/w-d-xo.html
The payload
And to noone's surprise the fix that introduced XSS was to support Internet fucking Explorer..
Nice video
0:05 I put ' it gives bug
The link www.google.de/search?q=&cad=h doesn't do anything when I click in the search bar
How can i get to understand what is this dude is talking about? This sound so advanced that i couldn’t understand this whole thing. Where should i start at? 💔
why do we still have XSS Vulnerabilities in 2019 ?
Because HTML is bloated, XSS is one of the vulnerabilities that still happens because of a reason, SQL Injections for example are easy to avoid, and they happen only when programmers knows nothing about security, but until we will replace HTML with something less bloated and maybe a little bit more strict, we will have XSS
Because the web is a huge pile of spaghetti and legacy cruft that's become so bloated and complex that it's impossible to do correctly.
Why did Google do sanitizing for search field that just wants plain text (not any html tags)?
I want to put this into face to people who shot down XHTML 5 and strict parsing by default
April Fool?
Wait a second. Youre telling me go-
Google.com doesnt have a cross site scripting filter??
Curious to know why they aren't using htmlspecialchars or entities :|
Im very noob but can someone maybe say what someone could do with this vulnerability?
timmithan letting someone click a google link and execute JS on that.
ahh okay, thx 👍@@Mar_Ten
Xss only exists bc the browser assumes all web devs are ****, which is tough but fair
Fucking ELITE HAXOR GOD
0:05
*flackback*
i try put '
it gives bug
I wonder if this guy (Nick Reid) is still allowed to make commits.
Browsers are not wierd, but the way programmers code are.
Aha google offered in Deutsch are you german?