Building Secure React Applications

this is a society of creative anachronism tournament on that crossbar on just in case you're like what is that Jim okay so thanks for clicking show their ad Jim so hi everyone and welcome to what was previously known as the secure developer podcast we now have a new name of Mike dev suck-ups and we have information on our website about rebrand so you can add there to check out exactly what that means my name is Oliver I'm one of the community managers at sneaked and we help deliver these sessions every two weeks and today we're joined by Jim Monaco and Ron Paris both from Monaco we're gonna talk us through building secure reacts applications I'm would love your feedback as we go through this session as well so we are currently in our slack in live sessions channel so as we get go through this session if anyone has any questions please feel free to ask them as we go through and we will pass them on to to Jim and to run and the slack channel is actually the best place to interact with our speakers as well so during the session after the session as well so you can feel free if you're listening to this as a recording or any questions come out come to you afterwards you can feel free to post those in the slack community I wanna make sure that I get - did you answer on so once the session is over the recording will be posted on our website which you'll be able to check out at any time and I think that's enough for me at this stage I'm gonna hand over to Jim and so everyone and they're gonna take us through today's session hi everybody my name is Jim Annika I'm really happy to be here on this not a podcast not a webinar live it's a live session let's start with just getting that scare terminology right we're on the lives is it a virtual session or a virtual live session I already fixed it up that's a good question we call that a virtual session very why I already I'm just sorry my marketing terminology bit off it's a virtual virtual session and we virtual session but we're live - we're live right now yet you know it it's it's my great pleasure to also introduced Ron Paris again I've known Ron since 2013 we used to work together at white hat security which is where we met back in the day Ron is one of my favorite researchers in the application security space specifically he does a lot but specifically his work around JavaScript security is some of the best I've seen and you know what there's a lot of us who make a lot of noise in the industry but it's often I think the folks behind the scenes really doing the hard work who are some of the really best contributors and I'm I see Ron is one of those people how you doing Ron up to it well Jim that is true we did be 2013 during our brief stint over at white hat security great company that was you were doing 200 Olas meetings a year right yeah something well it was a fascinating experience a lot of travel and I did love the experience there now that now that it's sold my stock is cashed out I could say it was a circus holy I can't say that I'm not part of that circuses are fun places and a lot of like a lot of very skilled professionals are needed at the circus so drunk Ron Ron Paris does not endorse that comment he does not endorse that comment so we start talking about react security Jim I remember in 2015 you had already done some early research and maybe even provided some guidance to developers on on how to get a ride with react 2015 there was not a lot of people talking about react security and it was beginning to grow exponentially in terms of use so all right and there was a few people chatting about it on Twitter and a few people posting blog posts and I was collecting the information from like seven or eight different people who posted little bits about it collected it and began to add it to my course where with references and began and I pushed out like a brief guide on react security back in 2015 and I know JavaScript but I don't know JavaScript at the level of like closures and some of the more advanced techniques I'm like when you're jQuery JavaScript guys right I spent years doing it and so I remember when you looked at my research and I remember correctly I I hired you to like look at the research and extend it I know they think that was a November of 2017 yeah I think you had given me your early research and I looked it over and it all looked like you know high-quality stuff good guidance and I think what was happening around then was that most folks were still writing angular so angular one was still very popular and react was the Challenger and I think back in 2017 November so two years ago you pinged me and said hey would you mind for mana code just doing a deep dive on the react security stuff and then I think I spent the next six eight months really digging in and figuring out what it takes to write a react application and take its threats and attack surface into account and and we were gonna give a talk at apps like DC and when I saw your presentation I was like holy cow you've taken this research to its like logical conclusions so far ahead that is starting to get beyond my abilities like again I did all my JavaScript development in an era where jQuery reigned supreme I wrote a lot of JavaScript but that didn't require a lot of the advanced powerful features of JavaScript that I think are now necessary in modern development and this is where were you jump in this is where you took over and really extended that research to the max I heard a lot of people comment on your DC talk and they were like that was amazing and there's like hat to talk I didn't understand so I think and then he explained why it's not because it wasn't a good talk it was because a lot of us in the security industry are thinking Jake we're thinking jQuery level JavaScript there's not a lot of people that I know in the industry who really understand JavaScript at the level that's needed for like modern node and modern reacting angular development that's a that's a small number of people so yeah it's definitely taken a jump and that JavaScript syntax I mean with the update 2015 in particular the JavaScript standard doubled in the number of language features so the size of the standard if you printed it out would be double in size so what at that point a lot of language features were introduced and I feel like you know security pros and apps like folks might not have had the time to dig in to those new features of JavaScript but I think now here in 2019 I heard something like 70% of JavaScript developers use real currently in some capacity so this is this library is really taken over so I think it's good that we provide some guidance to folks writing react and also folks that are you know taking care of a react application from an aspect point of view or just interested in maybe doing some automations around security I agree so this is a good time to talk about all this talk about your employer on this on this virtual session sure yeah no I mean I do training in mana code I've been doing that for a few years and enjoying it do a little research for mana code I'm currently working for NPM as a security engineer so NPM as some of you might know they they have a lot of the world's JavaScript modules and those end up getting downloaded and used and they also provide security tooling such as nvm audit that we'll give you I'll talk a little bit later about kind of how that fits in I know sneak also has some tooling around the same kind of use cases plus more so I think we're both allies in this you know finding and reporting of vulnerabilities and helping people automate security I agree so my my question for you is like how many modules in NPM are react components like if I want to download a third-party react component and use it within my react app I know that react has this big third-party library ecosystem how many like how many modules are an NPM yeah okay so let's take one step back why are you why are we writing react code right what's the primary task that racks helping us with the primary task is it's gonna do Dom updates so state of our application changes on the front end and we want to change the Dom to reflect that new state and like you said jQuery was often used for this in the past you would use jQuery code if jquery had a slogan that would be fine something and do something to it so you just kind of always manipulating the Dom in different ways but we react as is a unidirectional data flow model where updates happen in a very specific way and from a security point of view that's important because it means that if you use react correctly you shouldn't have to think about security concerns every time you go to update a piece of the dog they hopefully react has some safeguards built in that will prevent you from kind of coming off the rails so remember when you ping me back in twenty twenty seventeen know about writing some research on react I thought isn't this a done deal I mean isn't this salt what what's there to talk about and then when I tell get a little more into these ecosystem you're talking about and it's sixty five thousand modules that I found on up on the NPM registry I'd say that it's not a salt problem for various reasons we kind of break those down a lot of the use of jQuery in my air development we were doing asynchronous work with it with the Dom we were mostly making a page request pulling down a page and jQuery would let us manipulate the Dom but not in an asynchronous way it was more of like styling and some fancy components we couldn't get in basic forms but it wasn't a lot of like live updating the Dom through like Ajax JSON round trips that's not a lot of what jQuery was used for at least am i our development I know and as that became in vogue in the last couple of years jQuery we're gonna break apart it's not I don't think it's the best library for that and this is where the angular is the views and of course the reacts real I think shine the most is when you're building a complex UI with a lot of like Ajax live data updates that's where you almost need something like react I would dare say that you know absolutely absolutely and that you know if we take a step back and think about the security implications you know I remember watching so they talk to you Georg I you know in 2013 12 and you talked a lot about cross-site scripting and and defense and mitigation and a lot of it was around a server-side rendered templates right and how to get it right and whether you're pulling something out of a database and you're generating a page on the server side you're about to send it over to the client that was kind of the way to apps for being built back then and reacts part of this modern era where you get a big bundle of JavaScript HTML CSS and then the react code is responsible for making these requests asynchronously and pull it in whatever JSON and then redrawing parts of the Dom based on user interactions so things have definitely shifted in it and that's gives you a tax surface right that's a pretty big attack surface you're now dealing with dynamic data entering the Dom you're doing live Dom updates reacting to user events and more and this really does change how to deal with the main vulnerability we care about world's cross-site scripting and so the advice we gave about cross-site scripting even just a few years ago even the dom-based xss advice we gave its a whole different ball of wax as we move into these modern frameworks now the knowledge to really build secure user interfaces has become specialized you have to really understand react and Dom XSS and and JavaScript to be able to build secure react application so in some way I think it's easier to build a secure user interface on the web in some ways it's a lot more specific and and challenging in some ways we're gonna talk about in this yeah yeah not a webinar but virtual session during this virtual session yeah I remember when I was asked to do this research for Hanako the net result was that was a report that was shared with corporations and customers of Hanako and partners and I remember that they said I had a relevant research that showed vulnerabilities that were already found in the ecosystem and then I could talk through example code and I said okay no problem let's go grab a few reactor bones from the public database you know we a component library holds and I'll analyze them and you know and jump in but what I realized is that there weren't that many reported vulnerabilities so you had 65,000 modules but the number of reported vulnerabilities at that time we really only had one that I was able to point to in the NPM registry database that's yeah and you know of course the man who found it Adam Baldwin who's always five years ahead of everything so he was already thinking about it and already moved on by the time the rest of us even knew this would be a problem react security but I went in I found 66% of all the component library vulnerabilities in 2018 all right also how many was that man don't steal my punchline I found I'm 40% I found all 40% of all react component library vulnerabilities since 2016 and I found 100% accorded the NPM database of the cross-site scripting react component library vulnerabilities he of all time these are the component libraries not not the react you know library itself I'm with ya and to do that I had to fight a grand total of two vulnerabilities and so why fine wait can you give me that that whole like every time I hear this I can feel my head wanting to explode can you sum this up one more time for me please I'll make it easier for you so since since there are 65,000 modules out there in the ecosystem and according to NPMs advisories there's only five known vulnerabilities in all of these libraries and I wouldn't looked at some of the 65,000 libraries as part of the research I did for me on the code and I was just tripping over kölner abilities I mean I was literally the first thing I opened pop five minutes in here's a cross-site scripting open another library ten minutes in boom there's a cross-site scripting so ret component libraries often contain vulnerabilities I think they're just not being audited we don't have a lot of folks out there helping us look for vulnerabilities in these libraries hopefully this virtual session spurred some researchers who are interested in maybe get a few CDs on the resume or participating in one of these bug bounty programs like the notes' foundation ecosystem workgroup runs a bounty and if you find these vulnerabilities and report them you know you're you might be eligible for a CBE but then maybe even get some credit and potentially there's a high download library you you could be eligible for bounty pay so I would say that like your biggest concern when using react is probably the library itself so does react the library itself contain vulnerabilities and in the history of the react library it's only had three vulnerabilities but it's both it's a pretty impressive one was in 2013 uh it was a it was an attribute creation vulnerability was cross-site scripting via attribute creation what raised my crossbow so someone's like last time I was on this virtual session I threatened Simon one of the lead Java guys there with the with the machete throughout the podcast because he need to be kept in line you know Oliver is very respectful but I just I know these sneak guys and I always got to bring a weapon with me and so I brought crossbow to represent cross-site scripting so so Oliver keep in line is what I'm trying to say don't make me use this and somebody asked me on the live session are you bringing tonight I'm like I'm not gonna bring a knife that's terrible I'm bringing a crossbow this is my society cream dozens across well here never promise for you Rigo whoa well it's stuck into the wall oh my god check this out here be in here no no there there's my crew I gotta show you this because my girlfriend's gonna kick my butt when she sees this that that is what I just did I just kind of shot at the wall oh wow let's go back to work Ron think about something pretty exciting I can tell Oliver wanted to know more cheeseballs in the other codebase luckily I'm renting let's move on there was also a cross-site scripting vulnerability in the react library and there was one in react Dom as well so all three of the vulnerabilities in the react library itself have all been related to cross-site scripting zombies cross-site scripting server-side rendered code related cross-site scripting and then zombies cross-site scripting so I'd say that if you're using the react library you probably just want to stay up-to-date and there's a chance that there will be another process scripting in in the react core library but they don't have them very often now when it comes to your code like what can you do to avoid cross-site scripting vulnerabilities I think maybe a little bit of screen share here kind of shows a CO example while Jim does archery practice let me yeah I'm back Ron I'm back okay we're cool session cross-site scripting and react ecosystem I'm more focused now morpho okay yeah I'm ready for I'm ready for a sneak poster no Alfred I'm probably gonna get like a contractor get some you gotta get some fixing there yeah that's bleep I really didn't think through my Cosmo demonstration it's like a safety it's a safety bolt didn't didn't provide the safety I was expecting very much like we see in the world of application security and modern framers as we're about to talk about that's really the metaphor I'm trying to get across here wow so Oliver Jim can you see my screen do you see this built-in exit defense line no life how do I do why not I just see Ron how come I don't see it I'm not sure do you see it Oliver it's a filthy XSS defense at the top yep I can see the screen what matters is what matters let's do this so here we got react component and we're defining a new app component and it's got some markup here they kinda looks like HTML do you know this stuff is Jim it looks like HTML but it's inside of your JavaScript you know is he talking JSX or something or yeah this are JSX yeah we got some geo sex here so j sx is own sort of looks like a markup language did you author in your javascript files that gets transpiled to javascript it will run in the browser so in this case like these divs this div with the class name equal to app that will get transpiled under the hood to something like crate element in the react library and that class name will get passed in as part of an object and the property will be equal to the class name and then its value will be equal to that string so what you're looking at it looks like HTML this like she could transpile into something that runs in your browser as javascript and so like i said the primary thing that react does is it renders dawn so what this is gonna do is it's gonna render a div and then in that div it's gonna place some text content here that text content looks again like some markup but you can see it's in quotes and if we intend as a programmer for it to be a string is this vulnerable to cross-site scripting Jim there's no way an example this is this is where JSX shines is where this is why a lot of react folks say that you can't have XSS and react is because whenever you're putting any kind of content between two mustaches it's gonna do contextual contextual output escaping it like like you see in the bottom example it's it we're converting like the left hand symbol to the HTML entity and purse and lt semicolon which means it's gonna display the attack gonna display the markup or the JavaScript but it's not gonna execute it in the browser when it gets displayed so this is the main defense when it comes to cross-site scripting output escaping and ron we talked about this for over a decade maybe we have and i - joy here you talk about it I remember the first time I ever had to listen to a live have to listen to a speech you were giving at UCLA they told me at Whitehead they said hey you got to go meet Jim Manik oh he's giving a speech and you've gotta sit there watch it and then afterwards you guys are taking a meeting together and so I said well how long's the speech and he says be four hours long this is gonna be the worst day of my life he's gonna be talking about because I already know for four hours I said the audience I didn't look at my watch once so you talk about contextual escaping as much as you watch him I'm very honored glad to hear you talk about it well it's amazing in the last couple of years we've seen frameworks like some frameworks like old-school Java Java Java server page some of their default components will do some escaping but in the modern era we see things like go templates which does contextual output escaping react and angular and even view as modern JavaScript frameworks that do this escaping so and a lot of other modern template even server-side templates will do this stuff automatically this is a big improvement in the world of XSS defense when building web user interfaces but as you know it's not you know just because you escaped data in certain context doesn't mean you get perfect yeah yeah I love this example because we have an example of we're putting untrusted data in a URL context and even when it's escaped properly a JavaScript URL is a common way to bypass this particular piece of code and as a quick note and please go back and re explain this again as a quick note the the Google researchers like the people who write trusts too tight Chris Kristoff and and some of the other folks who are at CSP Mike Samuels still working on the standard I think it's Chris Kristoff is the lead guy we're doing trusted types and I'm not sure who's working on CSP that's a w3c standard now but I know that Michael spagnolo and Lucas why show bomb for Google they pushed out several talks on how to implement CSP in the real world and their data is some of the best I've ever seen so I'm a big fan of these three and I really think the leaders in this of content security policy I call Lucas why sure mom and Michael Spagna yolo top top-tier guys because they're not just building the standard they're deploying it everywhere and all these different properties and understand the nuances of bypassing it with these gentlemen have told me is that one-third of successful attacks that that breakthrough Google properties are because of JavaScript URLs so I don't want to even though this is one example how to bypass react I don't want to minimize how important of a bypass this is it's one of the most popular ways to get XSS into a web application of some kind I mean yeah react is all about updating the Dom so they know about this threat they know about JavaScript URLs I know from the beginning they made a decision to allow them and it was a conscious decision they just accepted that people want to be able to do this but like you're saying you know Google's struggling with this they've built these technologies like trusted types content security policy dad defense-in-depth because they know this kind of stuff slips through either because a library author intends for it to slip through or because it's accidental and gets introduced into the dog so those those other technologies like trusted types and content security policy we're taking a look at when you just assume that somebody could possibly bypass a mechanism or in this case you know the library mediators just just allow it and to be fair coming coming soon to reactions the PR has already landed they already warning users are already warning users in development mode about JavaScript URLs and then in the future they might be actively blocking Java cert URL so they're super on top of this the react team is they just have left it there because it's sort of these weird intent functionality things and that's that's a big struggle we have with libraries in general right now I work in that security work group for the nodejs foundation do an ecosystem triage on modules or have vulnerabilities in the ecosystem and a lot of the times when a bull devotee gets reported the maintain your library will say hey that's intended right are you showing something like this you're like hey this is a bypass obviously the react team doesn't see it that way they think that's not a bypass that's intended and I think that's a controversial stance because if you look at the angular framework this is protected automatically view is like we don't care about it I don't know if that's true you does not defend against this and the next version of react there's gonna be a way for this to be to be handled automatically by the framework so I know that the react team in the past have said like oh it's not our problem this way it's supposed to work but other modern frameworks including I believe the next version of react is gonna deal with dis automatically I believe right yeah well I have a code sample later if you take a peek at this is how I'll jump there now why not it's job well this is how they're planning to deal with it I'm is this I was a good way to deal with the JavaScript protocol URL no this is what we're looking at here Jim a big freaking regular expression that made me sick to my stomach I'm not trying to make fun of the react team I know they're working hard but this is the absolute eponym sane way wrong way to handle this problem this is not acceptable you know I recently heard that if I used to say a joke about regex that if you have a problem you solve earth regex I heard then you've got two problems yeah exactly they knew what I heard is that the plural of regex is regrets yeah but this one what's the other problem besides being a regex we have to use regex I'm just joking but what's the what's the problem of this approach I mean this is not well that what I the tried-and-true way to handle validate this is essentially an input validation problem someone's gonna submit a piece of content that we add to a URL context and I want to restrict certain kinds of content and allow other kinds of URL content this is not whitelist validation this is looking to find malicious activity and block it where I believe the way to really do this is to use the URL class and define which protocols are acceptable HTTP and HTTPS frankly that's it make it configurable if you want and any other protocol gets rejected this is a real simple and clean way of blocking these bypasses and without having to have this very unmaintainable performance unfriendly blob of regex that no one fully understands it's just not yeah you know I tried this at my house you know my kids they're small I've got two small kids and I don't go to police station every morning and print out the wanted posters you know and I would bring them home and show over the kids and I'd say hey if any of these bad people come to the door don't let them in but otherwise let everyone else into the house and I said you know show the kids pictures of you know people in the family that we trust and only allow those so I think it'd allow list is probably the way you want to go you probably don't want to have a denial it's like this case and by the way I can bypass this with the data URL done i bypassed this and I got XSS through a URL context that's the other problem it only solves the JavaScript protocol problem but you can execute untrusted script through data the data scheme or data protocol I know I don't know where this is a fly maybe they handle that case but what do you but what you're saying is you're tempting someone to find a bypass and we know folks especially the folks that are working you know with cure 53 and others they're going to find a bypass especially for something like this I think so do you do you have a copy of that code that the rate in the secure react component back in the day uh I might have it around I'll link it in my blog it's in my blogs all link it in the show notes let's charge on let's turn around this is awesome so let me let me pop back over here real quick so you're probably thinking well what do you straight it does escaping but like sometimes when you write application it's like you actually want to inject yeah some kind of HTML directly into the dog this comes up right that's kind of living dangerously if you ask me but it is an important thing you have to do right yeah so like what's what's the current best practice if I have a chunk of markup and I needed to stick it into the Dom if you're in this situation Jim back in the day what do you do with that markup before you go and put in an inner HTML or something back in the day as the input hit the server we would server-side as a validation routine run that HTML or user authored input through a server-side HTML sanitizer one of the bit and the Java ecosystem there was none back in the day so that's where Michael Samuelle from Google wrote the Oh wash java HTML sanitizer the PHP world there's the HTML purifier class Ruby on Rails has an HTML native class that does this Java also has the J soup project that does this Python has the bleach project which does is all from memory so these are all the different server-side HTML stanning libraries out there all of them have been bypassed because this problem is so bleeping complex give me a chunk of a chunk of HTML and and let's provide some assurance that it doesn't contain malicious JavaScript and this is and yet still support all my complicated HTML input this is a really brutal problem and and I think a lot of people even believe doing it server-side is not the right place so just a few years ago this is where mario Heidrich and the careful III team shows up and they they broke the library you know Dom purify and and so now react shows up a couple years ago and they just did not address this problem they said if you want to live dangerously then use dangerously set inner HTML and we will let you add whatever markup you want directly to the Dom and this is insane it's and I think it's bad that the framework itself doesn't address this but what they did do to their credit at react they named this dis attribute dangerously so we know we're doing something foolhardy but if you look at angular I'm not a big fan of angular I don't like the the complexity of it I prefer react but angular has a built in HTML Fannett Iser I just say it's HTML and they'll sanitize it automatically using a similar tool we react when I say a dangerously set inner HTML it's raw editing the Dom with markup and there's no control built-in to react to help me solve this security problem I think that's disappointing I'd like where yeah so I would say like this thing right here is an escape hatch that's how I look at it this is a patch I'm a developer I don't what I'm doing I'm trying to get the Dom I want to make changes I need to get in there and do it I know what I'm doing use this particular escape hatch and like you said the react team named it dangerously said so it's obvious to other development you're doing some dangerous so if you if you had to do this gym and you had to put this stuff in you're using dangerous either you know what's the control I should be implementing here what library should be using to deal with this string the the library that has dominated client-side JavaScript based HTML sanitization is a library from the Cure 53 team called Dom purify this library is so important that's going to be added to the next version of Atma script it's used on Google's homepage at google.com and it is I think one of the most important security libraries in the JavaScript ecosystem because we do this stuff all the time and like when I go back to old jQuery stuff it's little riddled with XSS and I can use Dom purify to to plug all of those escape hatches and add an HTML sanitizer to make XSS even on my legacy JavaScript filth fix all that stuff as well so this is a there's no library to modern JavaScript development Dom you know the approach has changed under the hood recently but I know pretty pretty recently there was a there was an article on live over flows podcast on rubber duck somebody had a bypass in this approach so they're on Google home page in their search box you could put a certain input and now would result in a cross-site scripting vulnerability when they did Dom manipulation and it's because of the way that Dom purify works I think it's similar the way that Google mechanism works which is it creates a template tag I believe and then it puts the the content in that template tag and builds up a DOM and then it sanitizes and removes based on a white list of allowed elements and attributes it removes all the dangerous stuff and then it takes the output of that Don fragment and then turns back into a string and an inner HTML is that back into your Dom so there it's sound the ideas sound the problem was there's a slight difference between the way that no script tags were handled in an element tag versus how they're handled in a live dog and that little time difference but something attackers could exploit so even Google is dealing with cross-site scripting zombies cross-site scripting because of these types of issues in even the best in the world are there still bypasses so I endorsed that video this is from orange Desai on live overflow just do a quick search on unlike google.com bypassed live overflow Dom purify and it's and it's it's Dom purify and Google sanitizer basically the same thing and and yeah that bypass was sophisticated and amazing but if to your point improves that even when you use the best practice of an HTML sanitizer client-side or server-side you've got to keep those libraries up to date there's bypasses in them on a fairly regular basis cuz it's a hard problem to solve a really hard problem cell and you're probably thinking like ok dangerous editor HTML that's not something people often use right I mean react is all about updating the Dom why do I need to jump out through an escape hatch and like grab some random part of the Dom and update it so you've moved the single action this is one of the most widely talked about and used messaging apps especially in the security industry their claim is it's doing it's doing some of the best message communication a transport security that's possible with today's cryptographic technology so it's a really I'm sure it's a great tool and a cryptography is great and that's the hard thing about our industry right we're flaw finders so it's hard to talk about things without talking about some of the flaws what a great engineering work probably happened there but you know this is a difficult problem that teams grapple with which is how do you update that you know the contents of the DOM and this was the approach that sicko lab took they've now patched it but they were using react and they were taking the text if they received from the other party so you're getting a message on signal and secure communication platform you're getting a message and they're taking that message and they're taking the text of that message and inserting it directly into dangerously senator HDL that's that's a big deal and these are like a very security knowledgeable team with some of the best best cryptographers I know on the planet in terms of the work they're doing and they made so it's hard right you end up in these situations room we thought over to these escape hatches you go to do it and you try to do the right thing but in some cases you don't have all the controls in place so when you're using dangerously senator HTML will talk about you know using a linter to catch the usage but really these escape hatches truly are the way that you're going to get this this dog based cross-site scripting into your application you know when you and I think about this to me is is easy I'm never gonna use a dangerous sink I used some kind of sanitizing or escaping but you and I have stared at just the app set problem for like a decade now to the average developer even secure developers are worried about functionality dates they're worried about competing in the market and like security is one of a you know a dozen or more concerns on their mind this is my like only concern how do I teach secure coding and but I gotta realize that but even though it may seem like an easy problem South to me that's not the reality in the world of development we got to respect that yeah I mean in this case what would be the right approach I mean I think would be if you have to use the Angels II said in our HTML which hopefully you don't oh wait you find another way then you probably should be using tom purify and if you're then using dom purify there might be a bypass so you probably want content security policy and trusted types layer on top I agree and frankly what I do is I like to do server-side sanitization in one library put that in my database return that to JSON and then use Dom purify so and turn on CSP so if you gotta bypass my stuff you gotta bypass my server-side sanitizer Dom purify and bypass CSP and trusted types will back will back up any sink I don't define but I'll usually to find a dangerous sink to be Dom purify so again if you're using a good CSP policy doing server-side sanitization and client-side sanitization there's three layers that need to be bypassed and of course keep your freaking libraries like righteously up to date on a regular basis now we're talking secure software my pink yeah so if we think about the Jersey senator HTML if you had a guest Jim at the top what a hundred react component libraries as far as download goes these are using dangerously cetera HTML you think I talked to I did I'm gonna guess I'm a bit more jaded in this world and I see how often it's used I'm gonna say 40% 40% percent okay it's making a scale percent it's 12 percent 12 percent of these libraries need to use this escape hatch so the top under it 12 of them are using this escape hatch right how what kind of living is that to you Ron what kind of living is that that's living like heavy crossbow bolts through the wall of my rental I just did that and it's not a joke so I was trying to Democrats crypting I brought a knife last time machete to threaten Simon Oliver you know Simon right he's always out of line he got away with knife at him to keep in line are you right am i right no come on no Clement so I brought a crossbow to keep Oliver in line but Oliver is very respectful gentleman as we can tell so like I was demonstrating my this is from the Society of creative anachronism I'm old man I don't do upfront battle I do I shoot at people from far than I run away right away and they shoot crossbow bolts at them so I was demonstrating the crossbow this is like old-school medieval crossbow with a manual crank and a manual and that's a real crossbow meant to hit people hard and I used a safety arrow at the tip and I said without thinking I shot it at the wall so I'm like it's safety arrow and Ron here's here's my here's my this is my rental I'm gonna have to get this fixed don't worry lean I'm gonna fix this it's my landlady she's like you did what to my house so I put a little hole in there I'm gonna keep it in there and remind myself to fix it this is one of the advantages of a virtual session over a podcast you know you know what kind of content Oliver this would work on a podcast right you're on the bus when you send to this you can't see the bowl you can't see the whole wall not a webinar webinars are stuff Iran this wouldn't work webinars to stuff that you can work out a webinar here it's not a live session that's improper terminology it is a what Ron it is a build live session no no it's not a live session it's a virtual session it's a virtual live set virtual I think it's virtual session it happens to be live sorry this is live so back to back to react I'm yeah okay so that's the story right they knew senator HTML do the right thing but you know what's interesting is there's another way to get access to the Dom when you're using a react library and I think this is where we're going to kind of walk away from some of the guidance that people have been seen since 2015 and start to talk about some of the more modern attack surfaces being discovered so for example did you know Jim that RF will give you direct Dom access in react I knew you bring a herd of that I knew refs I knew props and types roll and crate component I didn't know about tell me about this rest up that's rest up is new to me what's so riffs are like it's a concept of react where you want to during some part of the lifecycle of your a component get direct access to the Dom and here's an example what you might want to do you might want to like when it renders the component you just want to like take the focus and put it the browser focus on the input field that's benign right you're just focusing an input field that's doesn't have a security vulnerability but where the starts to get crazy is I was looking at some open source code recently and I saw somebody doing this with RF they're planning your read or something and they're saving access save ref this nut element equals the current element so this is the currently rendered element but this is its Dom direct Dom API access and then they're saying the current element that were rendering react let's run this parse link which is an auto linker library that takes user input and finds potential links and it's like if you have a phone number or something looks get an email address or URL it turns it into markup so let's have this thing auto generate some markup and then let's jam that into the inner HTML property of the element we're about to render so inner HTML as you know that's a script sync so anything that comes out of this pars link this props text this is going to be directly inserted into the Dom and bypass any security controls that react as in place couple our stott link to one more time I know how that does everyone you're grabbing a prop that they tend to not get auto escape and said this is dangerous this is a third-party library this pars dot link this is a third-party library that's an auto linker and what auto linkers do is you give them text and then they give you back text plus markup so essentially like let's say I'm typing to you on slack and I say hey go check out Google Calm it will take that text and then it'll take the google.com part and turn that into an anchor tag and set its href e equal to google.com it'll do all that work for me but typically these automakers they don't do a CV so if I typed to you and I put you know a script tag or some other malicious content in the input that I'm sending to you the auto linker will pass that markup straight through and won't apply any escaping I imagine I can get JavaScript URLs through this other linker as well you can straight up to image source equals x on alert type oh I got scripting yeah you can use that cuz it's decided so they're not doing escaping for the different the different the URL and the display sync yeah so I can look at mine too I mean I'm sure your hands start sweating right you're taking something this stuff props up text okay that should be text we got from the user and then I'm gonna directly assert that indicator H to you about somewhere within my react component that makes me nervous like I shouldn't be doing that I know what that we wrapping the output a parse link and it you know gone purify again or something like that to escape the content so I think that this is a scary this is a scary usage of refs and I would looked at the module ecosystem and 61% of the top 100 modules or 61 of them are using refs so refs are ultra common where you know only a few people are using you know datacenter HTML refs or ultra prevalent so this really increases your attack surface so here a map SEC team and your are currently linting for dangerously senator HTML you might want to address to that list a lot of the use it might be benign but some of it might be just a stuff that's crazy I'm sorry run just to interrupt we just have a saw in the chapters ask if you can go back into presentation mode circuit thank you so much better yeah yeah that's great thank you [Music] yeah Jim so I think that in this case like what would the defense be here if you're going to be using refs like this you're gonna be doing interests EML my first reaction is when I'm doing link creation see III I don't want to just dump purify this I'd rather use a parse dot link that had security built in that it did actually be escaping at the attribute level that did entity escaping at the display data level of an anchor or similar and would and would do weightless validation on URL type to make sure it was like HTTP or HTTPS only and every other protocol get dropped so ideally I would like that solve at the at though at the link creator and then as an extra layer I can send that link and do Dom purify and that should all get through just fine so I personally want to solve that at two levels and okay for even better as a diffusing your HTML to assemble the URL programmatically Dave sinks would be another way of doing it sure so that hopefully I mean I wish that was the end of the story I think I wish it was dangerous he said a ninja to melon rafts and that was it for for attack surface but it turns out that this still exists in react which is this fine Dom noticed an escape hatch so what this thing does is it gives you direct access to a particular component in the Dom so if you have this going on anywhere in your in your react components you're back to Street Tom access you're back to having to worry about all the different seats and all the different escaping issues and I thought yeah go ahead is this really needed in JavaScript development is this like a programmer being lazy or is this really critical to react development I think goes back to what you were talking about which is a lot of people are coming from jQuery and they're used to having direct on access and I've even seen react components that contain both jQuery code and react code so they've got some react going on and then they've got some crazy escape hatch stuff going on and they're jumping in there a jQuery because it's like use the tools you know I mean be great if everybody understood idiomatic react used hooks or whatever the latest pattern was but realistically if you're gonna get the job done with what they know how to use and sometimes they don't have to do direct Dom access that's how they only get the job done they're gonna look for these escape hatches I got you so I was doing some searches on on github and I found there's 18,000 results for find Dom node in the open source world and look at the first example in here they're going Rick find it all no I feel pain just looking at that that's really bad immediately they're starting to concatenate you know spam class I mean these are static streams so they're not vulnerable but I see as a code smell this makes me nervous you've got people grabbing directly the Dom and immediately looking for inner HTML and things into it this is potential to have cross-site scripting vulnerabilities it's also performance unfriendly from UI performance you're way better doing programmatic creation of components rather than slamming markup into the Dom it's like this is it's not just a I think bad design but I also think it's bad performance if you really care about client-side performance yeah well this one is this is the number of react packages ecosystem packages and a number of reported vulnerabilities so we got the dark purple here do you think we're staying on top of these these these vulnerabilities or find them and report them well you gotta zoom in you gotta zoom in you see it if there's a there's there is a line here it's almost like it's almost the same colors Oliver's jacket their sweater yeah so so we're sealing vulnerabilities in the react ecosystem are underreported right so we could use help with this I found I found some vulnerabilities myself like I mentioned and they're not hard to find they're relatively easy to find like here's an example of one that I found it's a react SVG library so it's gonna take an SVG and it's gonna jam it directly to the Dom for you and it says that any SVG content that contains a script is never going to be run that's the contract you're in the documentation it says you use this library you give me an SVG that SVG since its X c'mon XML can have a script tag I'm gonna jam that into the DOM and I'm gonna probably use dangerously set in our HTML but you're good because those scripts are never gonna execute and then I went looked at the source code what is the source code down here the bottom saying we're gonna do Jim do you see anything about evaluating of scripts there in a source code it says eval scripts once I feel like this is different than never right like very very different like if it is an important distinction looks like Ron I would never ever do that ever well maybe just once but I really I would never ever shoot my crossbow in the house well I just do it once a day I feel like that's different right I would never ever hire anybody else to work on an online product for myself maybe just once okay I now get the difference between never and once I really get it now sorry I made notes here and it's not configured in a way it wasn't I wasn't necessarily going to present slides today cuz I I wasn't sure if this was gonna be in a podcast format but here's your this is a I know I know that but okay so react mark markdown here's another library this is a really common attack circus in react do you want to take some markdown and they want to convert it and then you want to take the output the HTML and put into the Dom but one of the things that people don't know about markdown is they think that markdown is like not related to HTML but it turns out that markdown is a superset of HTML so all valid HTML is valid markdown so if you pass markdown through a parser it's gonna come out markdown the new elements plus the old elements that were passed in and so for this reason every place that you go and take markdown output and go and put it in the Dom you have to do sanitization and in this case markdown preview says here at the top this is in their example code it says that the sanitized option is equal to true so we're all good from that point of view they're gonna turn on the sanitizer in the underlying markdown library they're using a conversion but then if we dig a little deeper into their source code we find this weird fragment at the bottom these four lines and what this thing is doing is it's creating a new renderer and then it's doing some overriding of the renderers functionality for when it encounters links so anytime it encounters an anchor tag during the conversion instead of running it's a normal sanitization code it's gonna do this stuff one of those plus symbols when you I see plus symbols they freak me out are they string concatenation right this is string concatenation right so we're gonna be taking user input and doing a little string concatenation well often does that lien cross-site scripting like every single time you know that means like tripping you Manuel escaping at this level this is important on a bigger level a lot of people have told me well don't do HTML sanitization just use markdown and this problem goes away and it does not there are so many implementation flaws I can still get certain kinds of script attacks through markdown conversion so markdown does not solve this problem of how to let a user submit rich text to some kind of application it's got tons of problems like we're looking at right here yeah so this one's just going to take whatever href you gave it and concatenate it in right in the middle of this anchor tag it's building so as you know if your href value is set equal to I don't know a closing double quote and then close this tag and then start a new tag of any kind of tag you want that will insert trips to the Dom look at the image in tag with a on-air attribute or whatever you've got cross-site scripting here we could fix this if we again ran the H ref variable through an attribute escaping function which it does exist in JavaScript and then run that through a URL protocol parser which make sure it was only a legal scheme like HTTP or HBS we could lock this down but this is this is dangerous code that I would not expect to see in a markdown conversion library at all in again these two bones I actually found about six vulnerabilities when I was doing the research for you back in 2017 and I reported them through various reporting channels and these were the two that got kind of remediated or at least acknowledged by the maintainer x' the other ones went into this weird voyeur you're just kind of waiting for a reply from the maintainer and you haven't publicly disclosed in they kind of you know so there's still in some in limbo right and I found these vulnerabilities you know in a couple of afternoons and I think that if more people were looking at these 65,000 modules we'd be able to uncover a lot more vulnerabilities so I hope that by showing these examples of how simple these vulnerabilities are to find that so folks that are obviously better researchers than I am that's actually not my you know exploit research is not my background but if your copybook yeah yeah there's really really talented people to know how to do this stuff and also they don't hack me and I think that you know they could go in look at these libraries and they can dig it uncover probably hundreds and hundreds of older abilities and I there are some tools out there they're trying to help us with this for example I know that github recently released a tool around their ecosystem security module uses code QL it's based on sembly they can do analysis of a single project if you write a rule a rule checker and it's code ql language you could you can analyze a single repository for a flaw and then you could upload that code ql in some way to to github and then they'll run it across more code bases and moldboard bounties so the idea is that you're not just finding one offs you're finding patterns and then you're writing something in a pattern language like a linter or code QL it's gonna catch things across the entire ecosystem and these guys are to see they're developing in a platform for this as well I've worked with them a little bit in the beta period for their platform and this thing gives you the ability to run analysis using rule sets like es lint type rule sets across a large group of NPM modules so the idea being that you know you'll just find one mole when you're looking for something but you find class of phones and then that runs across the ecosystem of modules and uncovers you know all the instances of that type I know that you did some some early work on like static code analysis engines Jim this is like generally the idea right you you write a check and then from there that that runs across your whole codebase right you're basically taking you're grabbing the code converting it to some kind of abstract syntax tree and then running linters or rules throughout that tree to discover it to discover obvious motor ability problems usually you're not doing it correctly against the source but against like like some kind of compiled version of it so it's a standardized form but all the same stuff and like the real work of static analysis is not the conversion to some to some format like an ast the real the real work is building this huge library of linters and rules to find these problems and that requires very specialized knowledge it's really hard to get researchers to write rules of this of this nature this is yeah I think what a lot of these are absolute teams that I know with reactives have been doing is they can't find a static code analysis tool that can fire up their and do the flow analysis and the source the sink and put the teens in and all this complex stuff instead they're just writing really simple linters and so this is kind of like this is kind of the bread and butter of dedsec ops or apps like automation as Jim calls it or you just call it automation right Jim that's what we're talking about we're talking like a CI CD right continues Henry continues development is called I go term automate Security checks is really what developers actually understand the most of my experience let's automate those security checks so I think you know whenever I tell a group to an absent crew hey maybe you should be linting for dangerously set innerhtml usage of props or deserialization of state they say like I can't block the bill right I can't put the stuff into our pipelines because it will block the bill but the more sophisticated teams they just send these results to themselves you don't necessary to block the build and tell the developer about it if you have a small app SEC team or even just a security focused person on the development team you can send these alerts to them and they can kind of triage handle them out of Pam so just because these kind of checks occasionally produce a false positive I don't think that's a reason to just completely discount using it winters I mean ideally linters will will not contain false positives but these are super effective it's so simple to write these it's it doesn't require the complexity that we see instead of Canales development it's something we can build into the pipeline easily and it's something that a lot of developers are familiar with working on so even if we're we can use them at the app SEC level but we can creep these linters up in developers ID in developers world I think a lot more naturally than trying to get them to use static analysis as part of their daily build so this is something very powerful in my opinion and we're I know we're sort of getting to the end of the hour here but I'll link the I'll link some good winters and the show notes that I use for react and I would also like to mention like when you're selecting react component libraries there's some indicators like low download count no readme lots of PRS open lots of issues open in the repo and I think gentleman at Steve wrote like NPM module called NPQ Liron Hall wrote this module and it actually quality checks your mom for you in an automated way so you could basically type that command or alias and PM to that command and when you do the install you get a report back tells you about the quality to module it'll actually prompt you about whether or not you want to install it so if you really want your developers to be you know taking a double consideration about without to install a component from the ecosystem possibly npq could be a solution to that I think that you know obviously you want to run things like NPM audit we all run into gme install we know that npm audit gives us findings I know sneak has some similar tooling around finding of vulnerabilities the ecosystem but you know we really need those well devotees they've been reported in order for them to show up in those scans so you can't you can't find out about a vulnerability if no one's reported it in this case you react you only got five reported vulnerabilities so the effectiveness of running you know any audit tools gonna be kind of low right if it's based on you know known vulnerabilities we need the researchers to do a lot more work of the JavaScript ecosystem so our tooling is going to be more effective basically is what you're saying and I feel that way I mean I feel like you know you can have a great tool like NPM audit or sneaks audit tool but if there's only five vulnerabilities in the database or eight or ten or whatever it is out of the sixty five thousand yeah it's not gonna be that effective I think the real solution run is that any JavaScript developer who has a new library to NPM should be banned from development for at least a year no no that's not that's not fair that says they're mine just ignore that for a moment and what I guess one final note that something is happening the react ecosystem is the next GS library is becoming very popular I think that next j/s it allows you to do server-side and client-side rendering just like react does but it promotes server-side rendering and they've created some lifecycle books that run server-side which means that now your react component libraries also contain server-side culpability yeah we're starting to see react components that do like direct direct SQL access on the server side or do command line calls so if you're currently you know give it some lenders in place you're doing some security automation for react and you are thinking about client-side vulnerabilities which historically in the problem with react components it might be worth taking a look and seeing if you also are horrible to some server side well they're companies comes your react opponents that's I think those are the thoughts I had to share today I know it didn't close to time here do you have anything else guys Ron I'm really impressed with your research you really are one of the the deepest react security thinkers I know of period and keep up the great work and I'm just really grateful that you took time to do this do this not a podcast or a webinar but a virtual session with us you're awesome Ron thank you so much no thank you Jim and thanks Oliver for hosting us and Sam I know she's around the corner so thank you very much for doing this thank you so much guys again a great and it's very entertaining session Jim I hope you don't get in too much trouble he knows of a good contractor in the northern Northern Virginia area please contact me at Jim Atlanta co.com looking for a contractor who can fix a little hole in the wall I know it can be done so you know the same contractor let me know please again yeah feel free to drop any recommendations in the flight channels and we'll pass them along so Jim so thanks everyone who's joined us live today and again if you're listening to the recording as well thanks for listening along and the next session that we have is in two weeks time same time as this session and it will be with developer advocate Sam Balan from author who's going to be talking about authenticating single page apps using JSON web tokens so hold on there will be a another very entertaining session and the recording will be up on my deaf Cyclops that IO very shortly and once again if anyone has any questions after this session please feel free to drop them into slack both Jim and Ron are in there you can feel free to tag them or we can pass them along to you and with that we're going to say thanks everyone for attending the sessions day and we hope you all have a good rest of the day wherever you might be Thank You Marie I will see you again soon thanks guys

Channel: DevSecCon -

Views: 1,334

Keywords: Cross-Site Scripting, JavaScript, JavaScript injection, React, defenses, React applications, secure, Manicode, OWASP, AppSec, DevSecOps

Id: 7rywmJgTrDg

Length: 61min 41sec (3701 seconds)

Published: Thu Nov 21 2019