Don't Use innerHTML Unless You Want To Be Hacked
HTML-код
- Опубликовано: 15 дек 2021
- Full Cross Site Scripting Video: • How To Prevent The Mos...
Full Cross Site Scripting Article: blog.webdevsimplified.com/202...
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
#Shorts
IMPORTANT:
I want to clarify some points made in this video. Many people are saying that this is not an issue since it only shows you your own cookies and you can easily get that from the dev tools, but this can be used to get anyone's information. Since the data for the query is stored in the URL it means if you send that URL to anyone and they click on it the browser will inject and execute your code. This code could do anything from send you their cookies/local/session storage, make a network request authenticated as them, among many other things.
One great example of this would be in a banking scenario. If a bank had this vulnerability you could write code that would execute a network request to the bank's backend transferring money from the user's account to your account. Then just put that code in the URL and send the URL to a bunch of people. Anyone that clicks on that URL will be directed to the page and the code will run automatically in the background. If the user was already logged into their bank then your code would execute with their credentials and send their money to your account.
Another popular place you will see this is with things like comments. If RUclips used innerHTML to post all the comments I could write malicious code like
some people can't understand what he mean to be
That's nice.
Roblox had that issue a while ago too
Hey, Do you also teach on udemy, if yes please share your course links here 😅
it will be nicer if you name this attack "xss vulnerability"
My man has so many pieces of invaluable knowledge, really glad I subscribed
Welcome. He helped me cracked interviews for two jobs (different switches) in the last 2 years
Never trust what the client sends and always be suspicious of links in your emails.
I like the tip, but I think the title being as "Don't Use innerHTML..." is just toooo bold, I would change the "Don't Use" with "Careful with..." as this is such important method in my opinion. Cheers
That's true. Also, there are ways to handle cross site scripting attacks especially if you want to save the user input on the server. Form validation helps.
its all about clicks !
This is a better form of clickbait because its true and still gets clicks (coined "legitbait"). He is telling you not to use innerHTML and the reason why. He should definitely keep it how it is. See this veritasium video for the differences in constructive and destructive clickbait ruclips.net/video/S2xHZPH5Sng/видео.html
Ahh but then the title isn’t as click baity
Agree.
I don't know, this is a very specific use case, as others have said "don't use innerHTML" is very misleading. Maybe "Careful when using it with user inputted data"
And that's why you clicked the thumbnail
@@petarp3938 and I thankful I did, some actually important shit to learn. And to clear things up ya just go tp comments to get more info or other notes.
This only applies when dealing with user input, if you are rendering server side html content then it's fine. Also a good user input validation and sanitation prevents such attacks, be it server side or client side
Edit: Most database API handles encoding already so most developers won't really need to manually do output encoding. Nevertheless it is nice to know.
Times & time again we see work around sanitation’s
Can’t trust them fully
Encoding is the solution. Not validation and sanitation.
@@ko-Daegu I think my sanitizer is failsafe. I strip all attributes except class .
Sometimes server side html includes user input (like a username, a comment, etc), so that's not something you should rely on in general, only when you know it's safe.
And input sanitization is a hack, you might sanitize it for HTML but then it gets used in a SQL query and you end up with SQL injection. Realistically you're not going to sanitize for every possible interpretation, so it's a losing game. Encoding and prepared statement-like constructs are the way to go.
@@ricardoamendoeira3800 I agree with prepared statements 100%. In my app I have one place where users can mark up a config file with simple html that only allows div and class/style. It is validated. They can also insert a (hotspot) link with a % that gets expanded and the link is for a certain purpose(e.g to switch a tab). Probably is a small risk but that is their requirement., BB code on BBses used to allow square brackets that were expanded to HTML.
It's worth mentioned that the reason he posted this is because cases like this actualy do happen in the wild, as some people don't already know the dangers of trusting user input and loading it in with innerHTML.
A lot of you mentioned methods of sanitizing the data either via the client side or the server side, and all that which is good, but I think the important message he is illustrating is the danger of trusting and outputting HTML based on user input. Sites and applications we build need to be tested for vulnerabilities, and this is one of the more basic ones to watch out for.
Yea you never wanna send raw html since you can also send other users information or even cheat in a video game such as cards
User inputs MUST always be sanitized from the server side.
This isn't even a server side issue. Just plain client side JavaScript makes this dangerous, too
Client and Server side, actually.
@@andresaliba always:
Client = UX
Server = actually security
Sanitization is a losing game, there are dozens of possible interpretations for every input, HTML, JS, SQL, etc, are you going to sanitize for all of them?
Just make sure you encode things correctly and use things like prepared statements or textContent to not mix data and code.
Would you say running eval() or arbitrary user input is safe as long as you sanitize it? You're playing with fire when you use innerHTML, it's basically eval() for HTML.
@Paul Moore Ricardo is right. Encoding is the answer.
XSS and SQLi is one of the very first challenges and problems that software developers are taught. Great work
Try to post this type of videos in separate playlist it's very useful and it's awesome for us for developing the project as well as we will try to avoid this vulnerabilities👌🏼👌🏼👌🏼😊🙏🏼
Can we appreciate he put together some nice looking css for this example instead of using plain HTML?
Indeed haha, it's quite cool!
Looks like a tpl of tailwind or sth tho?
If user credentials kept open like this in cookie, anyways it is insecure either you use innerhtml or not
And thats why you don't allow in input fields...
Reflected XSS is nasty
The important thing to remember here is to always sanitize your inputs. No matter the language you are using and how you are processing your data.
innerHtml is also pretty heavy on resources, so bad practice overall! :p
People used to get their MySpace hacked this way back in 06.
This form of attack is called a reflected cross site scripting attack (xss). Normally the javascript is inserted into a url, encoded and then sent by email to a target. Once the link is pressed the javascript is executed, which could have many payloads but the simplest one is to send the targets cookie details to the attacker. There are two other types of xss attacks which are stored xss and cross site request forgery.
To protect websites against these sort of attacks input validation needs to be used to filter out html tags, single quotes and double quotes plus semi colons.
That's kinda true:
- If you don't sanitize inputs,
- If you don't know what you are doing & you don't understand when it is safe to use innerHTML and when it is not.
It's actually safe to use innerHTML 99.99% of the time.
Saying "Don't Use innerHTML unless You Want To Be Hacked" is bullshit.
But I guess it can help junior developers realizing some specific use case can be dangerous.
I'm confused you just end up hacking urself when you inject this code.
Its fine doing that to ur self
But hey can send/post the link to other people,
It becomes dangerous when a hacker crafts a &query= string that can post to a collection endpoint they control, take advantage of a browser vulnerability, etc. They can then sends that link to other people (targets) and potentially collect their data or harm their machines.
In the video example it was grabbing cookie content. Now what if it also sent that to a malicious party controlled server?
@@weshuiz1325 And they are just hacking themselves...
@@omniomi And on a static page as per the example this happens how? You can ONLY hack yourself via this method. If you think otherwise you clearly don't understand the web.
@@kidShibuya Just because he didn’t showcase the vulnerability on a dynamic site doesn’t make it less harmful. The principle is the same. If you output unsanitized HTML that contains user written text on to the page using innerHTML, you’re literally begging someone to perform an XSS attack on your website.
By the way, you’re completely wrong. If I knew that you were currently developing an application like the one shown in this video, I would be able to get every piece of information you got stored in ls/cookies by sending you your own link together with a http post request to my database.
Damn! Never thought about that. Thanks!!
This is essentially printf(userString) and printf("%s", userString) for the web
Good tip Kyle, but I think you can do it anyway writing alert(document.cookie) in the console, dont u?
Yes but the difference is this code can be injected into other people's browsers since it is stored in the url. You can then have the code send their information to an API you control which is bad. Console log only shows you your own information
That's just called self-xss
@@WebDevSimplified of course, tks 😉
If the injected code the hacker writes is not loaded by other users, then this is a useless hack. If, however, it's published onto other user's screens, like if the text field was for a public comment, then this hack will work.
@@WebDevSimplified I think this is what people are thinking, consider pinning this comment.
oh well thanks for notifying me but I already did my whole language library using innerHTML. maybe when I make a JS-less webpage or whatever comes next.
I’ve never seen a dev project where passwords and users are used in a cookie, most of the time it’s session ids….
This is really about trusting user input. No matter the technique, user input can not be trusted, and that includes cookies! My concern is that this is misleading to new developers, because setting innerHTML programmatically provides the best browser performance in most cases. If you don't understand the context, you might think that innerHTML itself is something you should never use.
God you're amazing, xss is so common yet so easy to fix
The browser-owner can edit any JavaScript used in the browser
hi
It is called DOM xss
Wow I had no idea. I'm a Junior dev, and thankful to learn this now, rather than later. Thanks!
as usual take this with a grain of salt, saying simply just don't use inner html is a bit misleading, sometimes you need this function. what you should do is to always validate the user input (be it coming from a form field or a get parameter) before displaying it or storing in the database. as to actual topic read/watch a video about xss to understand why can it be dangerous, and how can somebody craft links with manipulated parameters to attack your visitors. following advice blindly regardless of how good it is without understanding is not ideal
@@titandps1149 what this is saying: avoid innerhtml when handling user input if possible.
I'm familiar with issues of sanitizing data when coding with PHP so I'm not sure if that would address the issue... I quite sure it does, however I'll definitely check out the video you reference. You're a good teacher.
if you send a $_GET or $_POST and reflect it on the page immediately without sanitizing, you will face this issue. It’s called reflected XSS vulnerability
Escape special symbols on server side - ❌
Do not use innerHTML - ✔️
If you say it shows you the password and sensitive information it is because we should save sensitive data encrypted in cookies. It doesn't make sense to me! if you can do something with innerHtml you can do it in dev tools as well. Please give us a real example to show the vulnerability.
Same question honestly
NO ONE SHOULD HAVE THIS MUCH POWER.
Now i am coding this based malware thanks
Client side security really doesn’t make sense. I appreciate using textContent instead of innerHTML. But what if I intentionally open up console and run document.cookie I am getting it out of the box. It is helpful but not necessarily if the queried data is sent over an endpoint and being run on the server side I would again implement anti code injection methods provided I have already implemented it on the client side. So what is the rundown? If a user really wants to tinker with the frontend I will let him do that. Once he spun off a request with modified data I will more likely love to redirect or respond an erroneous appreciation for trying so.
PHP also suffers from this, ALWAYS SANITISE YOUR INPUTS!
This vulnerability is called DOM XSS
kyle please make a video about styled components
what do u not understand about them tho lmao styled components are so easy to get used to them lmao
What about a short explaining why we shouldn't use evil() I mean eval()?
that´s why you use server side verification, in my page i use php to first remove any html on the string and only then send the result
Despite sanitising there, you must again check and sanitise on what is sent to the server as well from the server end itself. Otherwise you may be removing HTML but god knows maybe someone injects wasm in there and you will not know.
@@ItsMeChillTyme that´s kinda obvious. The golden rule is to never trust anything the user send you.
Thanks for the tip.
Thanks,now i'm going to steal every sensitive info hehehehe.
What kind of person stores their password in plain text in cookies? You deserve to get hacked.
If this man is blindfolded he will look like Satura Gojo
Very useful and interesting topic to discuss on.
Why don't you make more videos or may be a complete series on ethical hacking and cyber security?
If the cookie is "http only" it won't be displayed
this state just in when you get input from user and you want to display he input only but in other cases not mind
This hack was very common about 2 decades ago. Now it has drastically reduced as large scale web applications enforce thorough validations. So it may not really matter for some web applications.
We just need to be careful with innerHTML, not don't use it.
This vulnerability is very similar to SQL Injection
You miss the point in that this is only a security bug if you're making a site/app where users can enter data and have it stored somewhere to be later viewed by others
First, don't store username password on cookies. Cookies are for user preferences, not storing credentials. Second, at least escape any string you get from input.
As far as I know, XSS is disabled by default on many servers, but yes you need to be careful using raw user input.
Thank u kyle❤️
No body told me that before. Thank you!
This what was happening with New World chat system lol
Love you Kyle
Thank god i've never use innerhtml to display text input from user
Any "sensitive" information stored in the page, is anyways not safe.
There must be a server side validation rule, if not your server is compromised already, you just don't know that yet.
No. That's not right. This is client JavaScript and he tells you in the video how to avoid the issue.
Thanks for this 😊🙂😊
Thanks for this.
The fact the password is in the cookie and not even hashed is a far more worrying issue.
I have a react blog that uses inner innerhtml for the blog posts because I have styles like bold, strike through, etc in the blog content. What should I do in replace of innerhtml to get those styles to show up?
Thanks!
I think it's more nuanced than described here.
innerHTML will render text as HTML to the DOM. This isn't a problem if you are creating non-dynamic code blocks and inserting them in the DOM or even when appending dynamic data as long as the source is trusted.
However, IF the data you are appending is comes from a non-trivially insecure source or (and this is the big one) includes user input, you should avoid it because someone could then run JS on your page, potentially stealing user data.
And that's the XSS.
DOMPurify if you want added level of assurance
I try to tell people this, lo and behold they use innerHTML
But we use post method for sensitive data. Search is GET I don't know if it's advisable to store sensitive info on the page. Great video too
Thanks man
Tyvm!
Why is the sensitive info being stored on the page though?
using innerHTML is fine. but you need to escape the special characters such as < and >
You shouldn’t store sensitive information into the webpage, when validating you should use POST not GET
Who saves passwords in cookies 😂
Very needed
Also don't put sensitive info directly in the document.cookie
2 words: input sanitization
T is all frontend, so it could be edited by anyone. Document cookies aren’t secure no matter what unless they are marked as such, making them inaccessible to JavaScript
Inner Text would work fine too
How can i do that green black style?
There are much bigger issues with innerHTML than this.
One issue is that it used to (likely still does) have many memory leaks.
Another is that it causes a part of the page to be re-rendered causing some references to break. I even had some references break that were for a different part of the site costing me many hours of debugging.
In a scenario like this while I was fiddling I used innerText which I think does something similar?
Is it better to use .textContent indead of .innerText while setting text of the element?
always sanitize user input
Did you have to turn off Chrome's XSS protection for this? Chrome doesn't let JS code be executed if it appears in the URL
Of course, the problem comes when you *want* to allow people to put HTML, or worse, JS, on the page…
If you store your plain password in cookies you deserve that
is innerHTML the only way to use string literals?
I simply don't understand! This point leaves me completely cold.
Can I use innerText?
Do we need to worry about this if we using any framework
Okay but this is still used every day when we make components because like you showed rendering a component as text content will just show your component as a string on the webpage. Sanitization doesn’t take long to use and innerHTML is too important to use so we can just take the extra 5 minutes to sanitize.
is there any safe use of innerhtml ? for things which we don't input is it safe to use it
As long is it is not ever coming from using inputted data you are fine.
@@WebDevSimplified thanks
that’s just like typing alert(document.cookie); in the console
Classic xxs, an id session will avoid this kind of trick.
Excellent!
Very useful
First time of hearing about textContent, what's the difference from innerText ?
You can use innerHTML with user's input, but only if you html-encode the input value first (the < becomes < and so on) so the title is kind of misleading.
What about innerText?