Angular and the OWASP top 10 | Philippe De Ryck | #AngularConnect

[Applause] [Music] nice to see a full room for security so I'm always enjoying that so I'm gonna introduce you to the OS top ten in the world of angular so essentially for those who don't know the real meaning of the or stopped and the OS top ten is an awareness document it's something created by the OS foundation to raise awareness about the really dangerous problems in web applications we face today well today is kind of relevant they have a new version every couple of years so every couple of years they build a new list of what they observe in real applications like these problems are there they look at the impact of the problems they look at how prevalent they are and how easy it is to exploit and based on that they create a list you can see the 2007 version right here on the screen showing you what the problems are in 2017 this is the OWASP top 10 what I'm going to talk about is how do s top 10 applies to angular applications because angular applications are different they are not really traditional web applications you don't really generate pages on the server and send them to the browser for rendering no you load the application with traditional requests one time you have your sba your single page application loaded and at that moment we're essentially calling api's we're doing things on the front end and that kind of means if we're talking about angular it also means first of all that we are kind of separating developments yes you can still build things together but essentially you're gonna have front-end tests and back-end devs especially in a large organization whether it's the same person or not it's different roles for potentially different people or one person who has to split his time between these things so for the AUSA top 10 this kinda means a few things so for example injection is a server-side problem injection means sequel injection command injection things like that we have on the server potential problems we typically see they're in the front end they're a bit less relevant I wouldn't say extremely irrelevant but in my opinion we can rearrange the OS top ten to make more sense for angular so this is a very personal a biased view maybe you don't agree with that I'm happy to discuss that after the talk as well but essentially some of these issues matter more for angular deaths and other issues are a bit less relevant in a space of angular applications I want to talk about three of them I know it's called the OWASP top ten but first of all a few of them are irrelevant second of all I only have 27 minutes left to talk about these things and I I tried covering more and it ended up at like 90 minutes so I'm not gonna keep you hostage for the rest of the hour so let's talk about tree here it's like about a top tree and I want to start with cross-site scripting cross-site scripting is a really really nasty problem it's essentially an attack where the attacker succeeds in executing JavaScript code in your application and in the curse any time some untrusted data ends up in the page there's a potential cross-site scripting vulnerability any time you put something into the page from a message from the database from the API in the backend they put it into the page it's gonna cause problems and we've seen these problems everywhere and if you want to know how prevalent cross-site scripting is I can guarantee that almost every application will have them and recently we saw one on one of the most I would say the most secure pages in a roll to Google search page very simple they have one in one input field yet because of some weird Brasserie behavior there was across the scripting vulnerability right there in that page just to show you how hard it is to prevent things like cross-site scripting that's a bad part the sad part of the story a stock bite exists in angular that's a good part of the story so the angular team actually knew what they were doing when they built angular which is a good thing since we all use angular so thank you for that so let's let's look at what this means in angular on top you have your untrusted code so this is your angular code you put some untrusted data right in there untrusted data is something coming from user input doesn't matter how it ends up in the application whether it's from a database or from a parameter or from an input field whatever it's the value that matters and in this case you see the value hello that's kind of expected and then somebody gives you a bit extra data gives you an image tag and that image is going to try to load unicorns of PNG which of course does not exist so it's gonna trigger the on error handler instead and it's gonna pop up an alert dialog when this gets executed this is a textbook example for cross-site scripting if you have vulnerability chances are that this payload will always work regardless of the scenarios that you're trying to exploit interesting a side note here the alert is really annoying like this pop up in the browser and you have to click it away and keeps coming if you keep executing this payload so it really annoys the hell out of you but it's not really dangerous but this is a very simple proof of concept so a real attacker obviously is not going to insert alerts unless they want bug bunting and it's a good way to show the vulnerability and collect on the money but real attackers are gonna insert real payloads and the moment they can execute JavaScript they can do whatever they want if I can execute JavaScript in your application I can make it to whatever I want I can start using permission ap based API so I can grab images from the webcam if your app has permission to do that I can use the microphone I can get location information I can deface your web page which is if they only do that you got away very easy that's good but I can also start sending requests to the backend in the name of the user and there's basically nothing you can do to stop that so cross-site scripting essentially for angular means came over the moments XSS happens if the attacker is skilled enough you lose there's simply no way to recover from that that's a side note so cross-site scripting really really dangerous how does angular handle this well if you output this data and angular you're gonna see that because angular is not stupid angular knows very well hey I'm putting data into the page here with the curly brackets that's exactly what that means so I'm gonna make sure that this data will be seen as data writer browser the browser doesn't see the dress code the browser moment if you look at how to execute that because browser knows oh this is data and it's gonna show you the data so in this case that output is safe that output will never trigger the execution of script code in no circumstances because everywhere we put this angular apply something called strict contextual escaping which means angular is going to look like hey you're putting this right there and I know that these things are dangerous there so I'm not gonna allow that to happen and they have you covered and that's good this is awesome old applications PHP Java server pages ASP you had to do this yourself modern applications server-side frameworks have something very similar today but angular applications on the front end to this automatically an angular is not alone the other ones do it as well react does it and ember does it and I'm pretty sure if you does it even though I'm not too familiar with it and so on and so on so this is good this is a massive step forward so that's awesome of course outputting HTML if you want some fancy output your business users and not going to be very happy you're gonna see HTML instead of very nice images or paragraphs or headers or whatnot so this is only useful for simple outputs a name sure that's gonna work there's no HTML in your name unless you're really unfortunate but you can have a lot of other problems with HTML based names as well I can guarantee that but let's say you want some outputs that does contain some HTML well angular has the inner HTML binding this is not a Dom API it's not a Dom inner HTML is the angular based property to bind data into the dot and if you give it output like that what's gonna happen well angular is gonna output that and notice like hey you want some HTML in the output so well actually you get the image well you don't get the image because it doesn't exist but you don't get the alert either because what angular does here is it knows like hey I'm putting stuff and putting untrusted data an inner HTML and I know that that's the cost from major problems angular already knew at an angular 1 they gave you an error in Satellite now we're not gonna do that you could fix that error and get it right but an angular 2 they do this automatically every binding to inner HTML is automatically sanitized and that means that angular looks at your data and says like whoa these features I know that these are good like the poles yeah I know that's fine the image tag yeah that's pretty cool this harmless I'm gonna allow that on error attributes no I don't know what that means I'm gonna take it out if I don't know it it's probably not safe so I'm going to take it out and make sure you don't end up with any cross-site scripting vulnerabilities in your application and this is absolutely awesome because this means that by default you are protected against cross-site scripting as an angular developer and that's pretty cool let me give you a few guidelines because there's a few things you need to know to watch out for so the good news of the story is that first of all you need to get out of the way just let angle or do whatever it does because angular is really good at that just two things the angular ray don't try to be smarter than angular just to whatever angler says this is how you put data into the DOM and you're critical because it applies everywhere the angular a binding to an href you give it a URL like this guess what a browser does Oh JavaScript boom execute that just like that however when you try to do this in angular angular it's like no no no I know that you're putting this in a URL field and I know that this JavaScript colon thing is very dangerous well actually angular doesn't even know it's dangerous it knows it's not safe because it doesn't recognize it and it says like I'm not allowing that value in that URL field and that is pretty pretty awesome by the way as a side note angular is the only framework that does this by default the other libraries like react and ember they don't offer features like this URLs are not protected there you have to do that yourself as a developer they don't do sanitization either you have to do that yourself it's not necessarily that hard to do it but you have to figure that out yourself or include additional libraries and hope they offer this protection in a correct way angular does all of that automatically and that's why I'm personally a big fan of angular here second guideline is don't use functions that start with bypass security in the name you can manage that right why the pipe a security an angular one the function was just called trust as HTML and you will find code snippets on Stack Overflow which we all use to build our applications that actually misuse that function and as an unknowing developer you had no idea unless you actually looked up the documentation I figure that out on your own or watched one of my talks from back in the day that's why they renamed this to bypass security because this will trigger a bell if you copy paste code from cycle overflow and it says bypass security that will make you think like what should that mean and that will trigger looking up the documentation and avoiding the use of that function if you're building libraries by the way he offer unsafe functions always put something like that in the name because it really works well in triggering developers to notice potential security problems how does this work well if you feed that untrusted data and you pass it through the function angular is not going to protect you so in this example giving it the data from before will actually give you that pop up because by the function bypass security you can tell angular this snippet is safe I vouch for the safety of this snippet so angular like Oh in that case I'm not gonna do anything go ahead and in this case it ends up in a bad location so this is intended for static code snippets if you want to output a static code snippet something you wrote yourself based on a certain condition and sure you can use this but don't ever ever use this for untrusted data user provided input should never pass through this function because you're gonna cause cross-site scripting problems third guideline don't use Route Dom api's so there are ways to get access to Route Dom elements with element refs don't use these api's to output data into the Dom don't set attributes or contents with those values because angular is not in the loop anymore the moment you get a route Dom element and start calling API sand that angular cannot protect you same thing if you add something like jQuery to your application to do something outside of angular or jQuery that's a very bad idea because jQuery requires a lot of internal knowledge to prevent cross-site scripting vulnerabilities because they do a lot of crazy things with the values that you give it so don't do that stick to the angular way of doing things very very important guideline here now final guide line to avoid cross-site scripting here is don't give the user control over resource URLs resource URLs are the only place where you need to think about security yourself because angular cannot protect you there let me give you an example of a resource URL dynamically loading an iframe the SRC here this value will automatically trigger the loading of a document the moment you set it there's no clicking in between there's nothing in between it simply triggers that loading immediately so angular if you give it a URL like this it will load a youtube video very easy very straightforward however if you give it data like that it's gonna pop up an alert I'll log I know why on earth can you put the javascript URL in an iframe SRC to pop-up I don't know why but it works challenge here is it angular can't really protect you yes they could determine that you probably don't want to do this probably you shouldn't but do you want to load YouTube videos maybe you do maybe you don't human on load stuff what if this value comes from the user net says like evil dot example come / hack me dot HTML you want to load that probably I don't know maybe so anger can't really decide it for your angular doesn't really know what to do here so it's gonna give you an error by default you can say like hold on no no no no I'm gonna I know you want to set this but I don't know whether this value is safe or not please ensure that it's safe first tell me it's safe and then I'll put it into the page that's essentially how this message message translates here and that means if you have to write some code so you have to write a function or a way to tell angular like hey this resource URL is trusted that's a line here bypass security trust resource URL with this URL of course before you call it you better make damn sure that is trusted that you are sure it's a safe URL so my recommendation here is never give the user full control of that URL because the moment you do that it's going to be tricky tricky to secure tricky to ensure it's safe so if you fix the scheme the host and at least a pod separator or even a part then you fix the host or the request is going to that way you are entirely sure this request is only going to tug the duct at youtube.com and then you give the user control over the untrusted part the identifier you merge that into the URL and you're critical and then my recommendation here is as a defense in that mechanism run it through the default URL sign sanitizer the one angular uses when you put a través to an anchor tag use that to ensure that in case something really crazy happens that angular is still in the loop to say like no no no I don't think this is safe so I'm not gonna allow to that URL to be used and this way you can actually ensure that that resource URL is safe and you can put it into the page and angular will load it at that point awesome final word on this use äôt it's gonna be available in development mode automatically from at next version we heard that in the keynote this morning which is definitely recommended because it prevents some weird template injection attacks that existed in angular 1 where there was no a compilation of template code up front I'm not gonna go into DT here detail here just use it there's a lot of benefits and one of them is security and that brings me to the first takeaway that's a message I've been teaching a lot of developers in training courses when we talk about angular well I talked about multiple frameworks with a message for angle it's actually very easy just stick to these simple rules it's a bit Messier for other frameworks but sure so automatically applies access defenses so that's good all you need to do is follow the angular way of doing things don't try to file angle or don't try to pipe as it just do things as angular expects and you're good to go all right one down the next topic is called broken authentication in the OS pop 10 which is a very generic way of saying everything that has to do with users and session management connecting is messy and problematic so yeah there's a lot of vulnerabilities there I'm gonna be fairly brief here I'm gonna sketch the landscape and I'm gonna give you some advice and point you to further resources right after this talk so Romania dealing with user authentication here you want to authenticate users and authentication well we all know passwords we all hate passwords probably but we know them and all our users know them as well but the authentication landscape is insanely complicated it has gotten really complex in the last five to ten years we have attacks like brute forcing we have a text like credential stuffing where they take leaked credentials from other websites and try them out against your applications we have time based attacks all of these are insanely complicated to stop password policies and account registration account recovery and all of that is a lot of effort to build on top of that you have multi-factor authentication today with awesome things like UB keys and that means that you'll have to implement support for that in your application as well and all of that I can guarantee you you don't do that in a couple of days that this months and months of effort and even then it's gonna be really hard to get that thing secure so my recommendation today is don't do it don't build it well you need some security so don't throw it all overboard but upload that to an identity provider use something like open early connect which allows you to have your angular application rely on an identity provider and that identity provider will be responsible for handling all of that if you use log in with Google awesome Google will be responsible for handling all of that and you just have to call them you get some result back and you're good to go of course you don't have to do this with a public identity provider you can easily use products internally as well you can buy identity provider products you can deploy open source solutions and you have cloud based services you can use as well which can be private to your applications so there's a lot of options here and it's really really recommended to go that route because implementing all of that is really complicated honestly you don't want to be spending your time on that anymore today if you're using a YDC in combination you're typically gonna use it a combination with a lot and now we're entering into a landscape which is insanely complex as well figuring out how to use OAuth on how to use already seeing what the right properties in the flows are and I'm not gonna talk about that in detail there's a session right after mine about authentication angular if you want to know more go there I don't know what's gonna be covered because I'm gonna be in the audience as well um but it's it's probably highly recommended they're from out zero they should know what you're talking about I won't just want to set a few things straight about OAuth and oh I DC so what you have here is you have the user is authenticating to the identity provider so if this is log in with Google or your internal system doesn't matter the user is only authenticate into that system one place one place only if you're building an angular app the user is going to interact with your app and if it's a front-end app only if you don't have your own back-end if using like Google API or whatever api's then your app is gonna be receive an identity token so the user is actually authenticating to the front of the application which is kind of meaningless so you can't really authentic eight your front-end but at least a front that knows who the user is and that user is authenticated at the identity provider then the front-end can access a couple of api's and it's going to do that with all odds based access tokens so open and connect is all about authenticating to an application to the front-end in this example and ohad is about accessing api's or resources on behalf of the user and these are merged together but also separate concepts so don't use identity tokens to access api stickers and not intended to do that they're supposed to be you access with OAuth access token switch which you can get during the same flow so while you're attending you can get access tokens as well and access API for example for Google if you build an angular front-end to manage some Google spreadsheet data for example and get a user to log in with Google asked permission to access spreadsheets and you will get an identity token and an access token so you know like hey welcome Phillip and you can access that spreadsheet with that token instead that would be one way of doing things another way would be if you have your own backends if you have your own back-end application your angular app is again what user will interface with and the angular app is going to interface with your own backends in that case the user is authenticating to your back-end application user is now going to the identity provider log in as Philippe with the identity provider and your backends will now know like who the user data type authenticated was Philip with user ID something-something and the back-end can now link that to an internal user like if it's a messaging form like oh this user on the forum is actually a dolphin's our great call now we know that dolphins are great authenticated and we can link that to the data we have internally again the identity is used here to authenticate against the back-end application and the backends can again access api's on behalf of the user if they want to and they would use a lot access tokens for that so these are two very different use cases they require use of different flows in these protocols but if you have more questions about that I'd be happy to talk about that later in the expert zone after lunch not broken authentication recommendations today which I always to give developers and most companies have been moving in the direction is use overriding connect because you don't want to be implementing this yourself for accessing resources on behalf of the user use oauth2 that's what it's designed for you can use both together in a very easy streamlined fashion so that's pretty awesome you don't have to implement many of the dirty details yourself you can use libraries for that we have libraries available that support all of these features so you use them they're highly recommend it I gave you one example on the slides before and you can find many more online by the way if you want to grab a copy of the slides later they're available on my Twitter feed you'll find a link and you can grab them from there as well alright one more the last one it's about using vulnerable components in your application that's a problem and especially in angular it's a real problem because over 97% of applications are dependent F application code are dependencies nowadays 97% of your code or your application is code you are pulling in from the internet and I know that 97% is like that seems like a lot so how much is it really well I run the numbers a while ago if you generate a new clean angular application with that command it's going to ask you some questions like do you want routing like yeah sure we want and you want do some assess or whatever yeah that sounds good yeah it's gonna run npm install on the background so it's gonna take a while but after about 30 seconds it's gonna come back and say like yeah we installed a thousand 169 packages from a thousand 30 contributors like yeah that's kind of a lot so you're now running code from a thousand developers that's impressive but how much is that really well let's count the lines of code there's an NPM module to count the lines of code so you install the npm module and then you can start counting lines of code you'll find a lot of languages in there but the interesting part is you'll find that you're now including two million three hundred and thirty six thousand two hundred and twenty eight lines of code this is a real number this puts things into context we're building a new angular app we have written zero lines of code yet our application is two million three hundred and thirty six thousand two hundred and twenty eight lines of code that's what we're talking about here that's a lot of code that's a lot of code you're trusting on to not be vulnerable because this is built by developers a lot of them free our volunteer developers freelancers people doing this for the good our daughter the good of their heart and they all make mistakes we all make mistakes so one of these mistakes can be a cross-site scripting vulnerability whoops one of these mistakes can be god knows what that can happen so what if that happens in one of these dependencies then it's a problem for that library they can update that but now your let your program your application is also vulnerable because you have that dependency with that vulnerability so you'll need to update that and this is something that will go on and go on like that and that's only about legitimate mistakes accidental form abilities this ecosystem is under a lot of attack lately because this is a very lucrative attack vector let me explain let me tell you one example story it's not necessarily an angular story it was an addition to our period the react ecosystem but it doesn't matter because it can happen to anyone let me explain to you what happened there's a company called AI Komodo I think they built a product to manage your cryptocurrency in a wallet very very sensitive it's real money depends on what day it is how much money but you kind of get the idea any attacker in this case meant it was an open source application daemon to get up and I said like hey wouldn't it be cool if the application was an electron app running on the desktop if you would be able to use like native notifications like the Mac OS notifications are the newest notifications that would be cool right and the product owners were like yeah actually that would be cool and it's like I was like you want me to create a pull request for that and you're like yes please do that so the attacker went to work he created a package called electron notify native which does exactly that it allows to hook into that API from the operating system and they publish that on NPM and they created a pull request using that library and added that to the application and two days later that was included by the target application so we went in about two weeks time we went from hey wouldn't this be cool to here's a pull request you can integrate that in your application everybody was happy because it's a legitimate feature added by a volunteer so awesome that's that's what makes a community beautiful right that's what we all depend on what we all hope is gonna happen in our community and then they said lucky interesting so you have now included my dependency and they updated their package to include malicious code so they pushed out an update they increase the version number and they said like you know what now it's going to do this notification plus a little bit extra a little bit extra was not good extra electorally included code to steal the seeds from the wallets and publish them on a server somewhere so they could build up a database to get access to all of these wallets at the same time couple weeks later the target application the wallet system in this case included that dependency and deployed that so at that moment the malicious code started running start collecting these seeds publishing them on a server and just waiting just grabbed all the money this is bad this is real this is a targeted attack against one application the there's a plot twist now the good part is NPM tries to do as much as they can and they actively scan libraries for potential malware they have patterns to these access and they detected this and they said like oh this is not good and they contacted the company said like yeah we have a problem and they will turn in like yeah we have a problem because the lab that the seeds were already stolen so the libraries are the wallets were already accessible by the attacker if they decided to do so and eventually decide like what we're gonna do with that and this is real movie material here they actually stole everybody's money using that for mobility and put it in a safe location they transferred all the money to a safe location outer reach for the attacker and then they set up a whole process where users could reclaim their wallets through the proper procedures and get access to their money again but this is to show you what we have to deal with today any of these dependencies in your application can become a list at any time whether it's intentional or because of a mistake because someone breaking into npm into that specific account and publishing in updates all of that can really happen and we need to be aware of that and there's not much we can do against these active attacks except the vigilance there are a few things you can do in your applications and you should set up dependency scanning today because there's a lot of these known vulnerabilities we know that version X of Y breathe Y is full to this attack but if you haven't updated your libraries in a while then you might have that for mobile version but you don't even know that until you set up dependency scanning github has a free service the dependency graph and they scan your package of JSON or whatever you're using and they tell you like these libraries are for mobile update now please wasp has a similar tool called dependency check can run an offline mode supports a few different languages really awesome software they just scan against known vulnerabilities and they fix or they tell you about that and sneak is a commercial company they have something very similar with a lot of good features and they offer a free version for open-source developers as well so you need to be aware of this you need to setup dependency scanning it's really really really important that you do so so you can update your libraries as soon as possible and that brings us back towards the beginning so we talked about the top three there's seven more if you want to collect them all some people like that talk to me at the expert zone so I'll be happy to go into depth into all of these topics to wrap it up I built an angular security cheat sheet which you can grab from my website so if you go there or if you go to Twitter you'll find that link as well you can grab like a nice overview of things to watch out for in angular applications and with that I have zero time left so I'm gonna wrap it up and I'm gonna thank you for being here follow me on Twitter for more security news and talk to me at the conference while I'm around [Applause] [Music]

Channel: AngularConnect

Views: 5,102

Rating: 5 out of 5

Keywords:

Id: jc0YYLLEol0

Length: 30min 48sec (1848 seconds)

Published: Fri Sep 27 2019