Running a XSS Attack + How to defend

hi if you're a web developer of course you have to build secure web applications and cross-site scripting attacks are one of the biggest threats to modern web applications and therefore it's important that you write code that's not prone to cross-site scripting attacks and that you in general understand what cross-site scripting attacks are and where potential security holes could be found in your application this is exactly what we'll have a very close look at in this video so what is a cross-site scripting attack here is a very simple application you'll find a link to the source code below the video but it is a simple application with just free files this application actually also runs only in the browser for a cross-site scripting attack you would also need a server but i can show how to launch one with this example as well which is why i'm using the simple example here we can send messages with some text and an image and we can have multiple messages here which are then simply rendered below each other and of course it would be easy to imagine that this is not just a dummy application where we can work in our browser only but that those messages and the image urls are sent to a server and then there they're stored in a database right that is how the vast majority of websites work users are able to buy a product which leads to a request being sent to a server to store information about that purchase there or you have a blog website where you write a blog post you save it it's stored in a database and users visiting your website can see those blog posts or you have a public forum a public board where users can discuss everyone who contributes and sends a message sends that message to a server where it's stored in a database and then other users can follow that discussion by loading those messages and seeing them on their screen on their device when they visit the website that is how the web works right and this application could be exactly the same those messages could be stored in a database on a server and how could we now launch a cross-site scripting attack what is a cross-site scripting attack about it's about executing javascript code on our users devices and one potential trivial attack pattern you could think of would be that you add script tags here in your message and you then have some malicious code here in this example just an alert where i say hacked and you hope that this website is built such that this content is rendered in a way that this code executes and you actually don't have to hope for that since it's javascript code you can simply inspect the website go to the sources tab of the browser and there you can simply see the javascript code that powers this website on some sites it might be minified and a bit harder to read but ultimately you can always read javascript code more on that by the way also in another video and article which you find below this video so here i can see how this website works and of course that's exactly the code you see here in the app.js file and in the end you see that the messages which are sent by the user are validated then added to a user messages array and in reality they would then probably be sent to a server and stored in a database and be fetched when the website is loaded and whenever we have messages no matter if it's like here in this dummy application or if we fetch them from a server we do render them at some point and here rendering the messages simply means that i loop through all the loaded messages and i build a long string full of list items which is then added with inner html to our user messages list to that unordered list we find here in the html code that is how messages are rendered here with inner html in the end and therefore innerhtml of course interprets everything here as html so adding a html script tag might work so if i now try this again and i sent this message you see well it doesn't entirely work nothing was rendered here no text but i also didn't get this hacked alert if we inspect this in the browser here we see that inside of this paragraph indeed the script was rendered as html though but modern browsers know this potential attack pattern and defend against it scripts added like this with inner html are not executed i'll show you another way a successful way of adding script code in a second though so just because this specific pattern is not possible does not mean that script execution like this is not possible at all now what's the problem with such injected scripts though if this would work for example well then of course the problem would be that in this dummy application we can only hack ourselves because this is a pure client-side application nothing is stored on a server but if that message would be stored in a database and other users would load and render it as well the script code which i injected here if it would be executed would be executed on other users devices as well and then this script code which is rendered here could do all kinds of bad things we could read the local storage or the cookies of those users we could send that stolen data to our own server or we could send requests behind the scenes http requests on behalf of those other users we could send a request to buy a product with the authentication data stored on another user's browser without those users recognizing it that's the danger potential by the way i have another article and video on storing data in local storage versus cookies which is also related to cross-site scripting attacks which you absolutely also should check out to defend against that you'll find a link to that below this video as well but that's just an extra note so that's the problem here we could do bad things but of course this specific example didn't work well here's an example that will work we have some message but now what about the image url this is also output with innerhtml and i use whatever user enters as an image in the end here as a source now this is just a string here this is all a string but in the end this string is handed off to inner html to be interpreted as html what if we would manipulate the image url such that we change this element a little bit for example what we could do is we could start with an invalid image url some page.com no image.jpg so this url doesn't exist but now i do something special i add a double quote here effectively closing off the source attribute right i'm just adding this double quote here and hence the source attribute is now done now we can add a new attribute and since this all will be interpreted as html this will be one way of attacking this and on an image element we can add a very special attribute which is officially supported and that's the on error attribute on error wants script code it wants javascript code which executes whenever loading the image fails so by using a invalid url here i of course can force that this loading process fails and then here i could add my javascript code without script text just the code itself and this will now work if i now send this message you see this hacked alert and here it's just a stupid alert because i want to show this example in reality we could of course do way more dangerous things and this is now a successful cross-site scripting attack again here we're just hacking ourselves but this data could be stored in a database and could run on other users devices as well so that is how a cross-site scripting attack works and how you can launch one finding such a vulnerability isn't difficult and all of a sudden you have huge problems so how can you defend against it if you are a developer building a website well there are a couple of things you can and should do you should of course avoid code like this maybe maybe you want to set the source of the image differently not like this in a string which is then interpreted as html but maybe instead the idea is that you don't set the source and don't set the alt code like that but you simply select the image element after it was rendered anything like that so maybe you can avoid this approach but in addition and more important than that there is another step you should do you should sanitize all user input you're getting and if you for example have a backend build with node.js you can search for node sanitize of course similar packages exist for php and whatever you use and you will find packages there which in the end allow you to sanitize incoming content for example with libraries like this one which allow you to run code on your server to sanitize incoming user input and sanitizing simply means that the content is checked for certain patterns for certain code and it will then remove such malicious code from the user input so that you only store clean content in your database now you'll find different packages and you want to have a close look at all the available packages to find out which one really is best for you for example the first package i showed here hasn't been updated for over two years so maybe this package is more suitable this specific package here could be used on the browser side but also recommended on node.js side and for example it detects exactly the attack pattern i showed you so sanitizing user input is really important you should have some process that parses all user input before it's stored in a database so that you only store save content in a database and therefore even if a user does submit code as i just showed to you even then that code doesn't end up in a database and doesn't get rendered for other users sanitizing is key whenever you're working with user input in addition to that sanitization you also of course can protect on the client side and for example if you are using frameworks or libraries like react angular or vue those frameworks already have built-in client-side html escaping which simply means whenever you output user content on the client side with those frameworks it's automatically escaped so that you are protected against this as well this still doesn't mean that you shouldn't sanitize on the server it's just an extra layer of security and with that you can protect against malicious user input there is another potential attack path though and that's the more tricky one this is a simple application with just vanilla javascript but we all know the reality in reality we build real bigger projects with tons of packages tons of third-party libraries which we add to our front-end react react router maybe a forum's library maybe some component library whatever it is we have tons of third-party libraries and it's important to recognize that all those libraries simply add new javascript code that is executed as part of your entire application now what if such a library or framework would now have malicious code inside of it it would run as part of your code and therefore it would not be sanitized or escaped that means if you include a library that has been compromised that has been attacked where malicious code is baked into the third-party library code then you're in great danger that's why npm has this audit feature which allows you to audit your third-party libraries that are part of your project for known vulnerabilities now that still of course means that unknown ones could still affect you thankfully a lot of projects like angular are open source and therefore you could of course look into all the code which is eventually going to run as part of your project but in reality we probably don't do that now angular of course is absolutely safe to use it's by google they have no plans on attacking us i would guess but if you're using a smaller library a smaller package it could be compromised maybe not even because the owner of the library is a bad guy but maybe because he or she merged a pull request that added malicious code without knowing it or without recognizing it so third-party libraries are potential security issues now that still doesn't mean you shouldn't use them but you should be aware of that you should use trusted ones maybe rethink if you really need that extra library with the animated tooltip maybe you don't need that maybe you can shrink the number of third-party libraries your code relies on as a positive side effect you would also ship less code to your users which also speeds up your website and that's really the key takeaway you should be aware of this fact now the bigger the popular third-party libraries and frameworks of course should be very very very secure but you never have 100 security you should absolutely defend against the other attack pattern which i showed earlier though by sanitizing user input you should absolutely do that but in addition also reconsider your third-party library usage and be aware of the potential risk you could face there and that's it about cross-site scripting attacks that is what cross-site scripting attacks are why they can be bad how to launch one and where potential security holes could be found again below the video you find server articles and videos on that topic specifically on local storage versus cookies for authentication data storage and with that i could hopefully help you build a bit more secure web applications

Channel: Academind

Views: 168,048

Keywords: javascript, js, xss, cross site scripting, running a xss attack, javascript xss, javascript cross site scripting, javascript security, tutorial, full course, maximilian schwarzmueller, maximilian schwarzmuller, maximilian schwarzmüller

Id: oEFPFc36weY

Length: 15min 4sec (904 seconds)

Published: Thu Jul 16 2020