 Is there a chat to Okay, we're live Yes, there is a chat Dave. It's on the left side. You click the button to the left. It looks like a sort of dialogue box The green arrow so screen share. No the one above that Anyway, go ahead. Okay So thanks everyone for coming today. We are lucky to have with us Dave wickers Dave is one of the founders of the open web application security project And also founded aspect security. He's a well-known security evangelist and security practitioner Focusing on software security and he's been around in the community for a while He's one of the people who welcomed me into the fold and into the practice of application security like 11 years ago now and Dave is he's been the he was previously the sort of like project steward of the OWASP top 10 and he is Going to present to us this in this presentation about the 2017 OWASP top 10 which Dave did not steward but Has intimate knowledge of and is able to speak to and I thought it'd be useful to have an outside expert Come in and give us some of their ideas about the recent changes in the top 10 So I'm going to hand it over to Dave right now Hey, thanks So I can share my screen somehow Yes with this green button And then I got to find the presentation Which I don't see No, I'm not a There you go. You guys see my screen see my presentation. Yep All right All right, so thanks for the introduction. I have a little bit of news to which is kind of interesting So as was mentioned, I was the top 10 project lead From basically its inception through the middle of last year for various reasons Jeff Williams and I was my colleague we decided that handing the project off to new leadership was In the best interests in the of the project and ourselves actually So we handed it off to Andrew Vanderstock and some other guys and they did a great job at taking the release candidate that we wrote and Stewarding that to a final release And so that's what I'm gonna be talking about today is the final version of the OWASP top 10 Which is similar to but not identical to the release candidate that we originally produced. I was also on the OS board for about 10 years. I Am or now was a co-founder of aspect security But we were just acquired by Ernst & Young so I now am an executive director at Ernst & Young So anyway, that's a little bit about me. I've been doing a sec for 30 years ish 2027 anyway a long time. So I have a little bit of background in this space So the slides that I'm going to present by the way, there's about 40 of them and It's way too many to really present them in the detail. They deserve so I'm going to highlight What I think is important particularly focusing on what's new and I'm happy to provide a copy of the slides to you guys, so I'll send that to someone in the Foundation and they can distribute it to the attendees or posted on your website or how we want to distribute it and in fact something similar to this might get posted at OWASP as a You know the description of the of the top 10 from a presentation perspective So what is the top 10 at OWASP? It's not a standard although a lot of people treat it as such. It's intended to be an awareness document of the 10 Most important risks you should probably focus on first and there's certainly many more Including things that fell out of the top 10 over the years It's been around since 2003. It's it's a de facto standard now because most of the application security community Or at least the web security community specifically looks at it as like the flagship Thing to focus on and it's been released about every three or four years since its inception So this is what is in the top 10? 2017 There's a lot of familiar faces here. In fact some of these things have been in there since the 2003 release Which is kind of disheartening Like cross-aid scripting and injection and so on and so forth But there are three new ones this year two of them are XML external entity injection and Insecure deserialization Hey Dave good. Go ahead There's your your slides don't appear to be changing. Are you in presentation mode or I am Can you so maybe the presentation doesn't is it? What slide do you see now I still see like The slideshow view well, I see like I just see PowerPoint. I see like the sidebar with all this Wonder if I have to tell Google somehow to share that I just tell them to share my entire screen take it off presenter views No, if I go to screen share can I just say share entire screen? You can do share entire there's full screen there. Let me try that and then let me go here And let me go Here is that better? Yes much better And so now you see this transition When the red box came up. Yes. Yep. All right. Thank you for chiming in and tell me I wasn't doing it right So a for which I'll go into detail later are Kind of good meaty new technical security issues That we've been seeing a lot of lately And so having them show up at the OS top 10. I think is a great Edition Because it gets some focus on these particular issues, which is the whole point of the OS top 10 Obviously some things fell off like cross site request forgery and Unsecure redirects and forwards, which are still of course important security issues That you should deal with and avoid in your web apps, but they didn't make the top 10 list this time But I think that's okay because giving some sunshine to some of the newer issues Uh and these are based on risk the top 10 is not based on prevalence Or how new it is But it's based on The risk to the application and the data that it processes And so xxc and deserialization vulnerabilities are Big deals. I mean even if they aren't incredibly common When you do have these risks they introduce a lot of risk to the Application and its data. So it's a risk-based analysis that caused These two items to get added to the top 10 And a third item got added to the top 10 this year. So this is not common to have three New items in the OS top 10 But that's that's okay And this last one's kind of a interesting risk It's not really a vulnerability. It's about the fact that applications Frequently have insufficient application layer security logging And of course then the correlation that you also Probably don't have good monitoring now. Obviously if you don't have any logging then there's nothing to monitor. So Clearly logging is a prerequisite to good monitoring but the lack of This logging and monitoring introduces risk Because attackers can typically attack your application with impunity Until they find an exploitable vulnerability Which is why a 10 got added to the top 10 list Uh in this release of the top 10. So I'll talk about all these in more detail in a moment As I mentioned, it's about risks Not just vulnerabilities. And in fact, the Number 10 that I just mentioned Is technically not even a vulnerability. It's a lack of a security feature it's not even A control per se in the traditional sense But I actually think it is a fundamental security control that applications need And frequently don't have or or just barely have And they're nowhere near sufficient to what they really need to be doing to Reduce risk to your application So the top 10 is as I said, it's based on risk. So we have a risk rating methodology That's based on a generic OWASP risk risk rating methodology that's been out at OWASP for years And we basically came up with a very simple formula That says hey looking at the threat agent and how it works. We're going to look at the likelihood That you have this vulnerability in your application The likelihood that an attacker could Detect it And then the likelihood that the attacker could Successfully exploit it So we give a ranking from one to three For each of those ratings And we average those numbers. So that's what these first three columns here are So we give you a score. We average them. So in this case, we're doing injection, which is A1 and that was the most severe risk in the top 10 And the average ranking of these three is 2.6 and 2.6 out of three is a pretty high number And then of course if the attacker successfully Finds and exploits an injection vulnerability The typical impact is very high or we call severe in this case Which is also a three. There is no higher number there So that causes this to have a very high risk rating, which is why it's number one in our list And all these numbers and these risk ratings are listed on every Page of the OWASP top 10 itself And in fact if I let me jump out real quick and go to a browser and See if I can bring up the top 10 document itself So go here Go here So the top 10 itself is a pdf document. That's about 30 odd pages There's some introductory material and there's some conclusion material But the bulk of it is the The 10 pages of the risks and each risk is documented on one page So for example if I go to the next one You can see that it's got a score of three to two On the likelihood factors and an impact of three Which is why it's ranked number two instead of number one now these of course risk rating factors are completely generic They're independent of any particular organization Or application or the data So when you're doing risk ratings You need to think about What these risk scores make sense and for your applications or your organization And that might cause the order of these risks to change for you And that's totally fine because You need to do your own risk analysis and your own risk decisions We've just sort of done a generic one to give people a sense of the priority But I wouldn't get too hung up on the order Of the top 10 They're all pretty important But of course, you know things you know the top are usually more important than things towards the bottom So anyway, we added three risks We merged two into one to make some room and we moved the priority of three of them That's not a big deal The methodology for producing it keeps evolving We've been doing more and more data calls getting more people involved in Providing there both broad data and their in their opinion The new top 10 team led by Andrew Did a data call when Jeff and I had already done a data call, but that's okay More data is is good Allowed in the doom with some deeper analysis We're also making this data publicly available So we can imagine people doing other interesting analysis on this data And in fact, I think this is the first time we've really made the data public through olas before the contributors made their data public But the format was inconsistent and wasn't all together so it made it hard to analyze the data Now it's all publicly available in a single source in a single format That allows people to do some interesting analysis Uh on that data Um, so this is a picture right out of the olas top 10 that just shows the changes Between the previous version and the current version And as you can see, you know a few items just transferred straight across no change Three of them moved around two got merged and these three brand new ones Showed up This one this one and this one and those are the ones I'll tend to focus on Um, so that's what's changed So let's the the rest of the presentation is really and it's like 40 odd slides and I can't spend You know a minute on each slide because we go way over on time, but in each one I go through, you know, what's the basic risk uh an example And then what are the best? You know the current techniques for avoiding that particular risk And so some of these are going to go through quicker than others because they're Probably old hat to you guys Um, one of the things that's changed a lot and so I'll skip ahead for a second. I'll come back but over the years OAS has been really whoops OAS has been really focused Uh on producing this series of cheat sheets We wrote the first OAS prevention cheat sheet or defense cheat sheet. There's an inconsistency there, but um These are cheat sheets to help developers learn the most brutally effective and efficient techniques for avoiding vulnerabilities And we started out with one on cross side scripting way back and like I think it was 2007 not about 2010, but I think it was 2007 And then in the last 10 years that's grown into like 50 cheat sheets on various topics not all of them are Great and wonderful, but a lot of them are really good And they allow you to really focus on that particular issue and the best way to deal with it so You know, I can say stuff in this hour that we're going to be talking Um, but in terms of a takeaway if you just learn, oh, there's a series of cheat sheets on the top 10 topics And in fact many more there's 30 or 40 of them Knowing that they're there going out there using those cheat sheets telling your friends about them And in fact providing feedback to the authors of the cheat sheets would be fantastic, particularly if they don't An address a kind of technology or issue you're dealing with um, let the author know and frequently they'll Do some research and they'll get some friends and they'll figure it out Give you an answer and they'll add it to the cheat sheet. So everybody benefits From that research and knowledge being in in one place. So And pretty much every item in the top 10, there's at least one cheat sheet Related to that topic and in fact in some cases there are a bunch of them like this one for example lists four kinds of injection Uh defenses for each in a different cheat sheet, which is a fantastic resource So let me go back real quick So what is injection? I mean Most of you if you know anything about software security at all are familiar with SQL injection as like a big big deal Uh, and it is from a risk perspective. It's also very very easy to avoid Because there are very straightforward techniques for avoiding SQL injection So the generic generic problem of any kind of injection is you're using an interpreter to process a command Like call the database or shell out to the operating system or what have you And you're combining user data with the code of the query or command And that user data is added unsafely To this command in such a way where that data can become code And now you have user supplied data Executing as code in some interpreter somewhere and that obviously can be really bad pretty much game over depending on the interpreter you're using Allowing the attacker to completely take over the server or the application or both and in fact Frequently then being able to pivot off that server and go off to go after everything else on that same subnet Or wherever wherever that application is hosted So we we typically think of this as SQL injection is the big problem and it certainly is But there's many many other kinds of interpreters as I've mentioned So be be very familiar with The interpreters you're using and make sure you're using them safely So here's a very simple example of a SQL injection You know you've got a form is taking two parameters from a user and account number in a skew The developer blindly appends the user supplied data To the query in this case is the red text that's being appended Uh when that query gets past the database the database doesn't know that the black text Is from the developer and the red text is from the user It treats it all as one string that it assumes is safe It executes the query and if any data comes back it sends all that back to the application Then the application might in turn send the first row of data in this example back to the user Or I might send all the data back to the user depending on how the application is is coded So this is the classic SQL injection issue Luckily, it's very easy to avoid this problem first off The primary recommendation in all cases is can you avoid the interpreter entirely? Is there some way of doing the same functionality? Without calling an interpreter or a shell Uh, that's the obvious best answer like why are you shelling out to the operating system? Can't you do that natively in whatever programming language you're using for example? um If you can't avoid the interpreter then look for an interface to that interpreter that's aware of data versus code And use it like in sequel they have the concept of prepared statements That have bind variables where you're making it very clear. What's data and what's code? And no matter what you pass in as data, it's going to be treated as data and never executed Uh, there's other things you can do of course input validation Uh reducing privilege so on and so forth But the primary thing is making sure that data is always treated as data However, you can do that in that particular interpreter So that's the classic risk That's injection that's been number one in the os top 10 for the last three or four releases of the top 10 Two is a combination well as is the was broken authentication It was also called broken authentication and session management before It's the same exact thing as it was before, you know, how strong is your authentication? You store the user's credentials safely through strong hashing Are those credentials protected in transit properly? Um, what about all the ancillary functions related to authentication? You know create account change password recover password Uh, you know secret questions for second factor authentication or machine binding or whatever You got to think about all of those things and in fact, of course one of the best things to do with to have Good authentication is to of course build one authentication system And use it over and over and over across many many different applications So you're not trying to rebuild the same security control Over and over and of course that's true of Any kind of security control anytime you can standardize And minimize the duplication of effort for that control The safer you're going to be and the less re rework you're going to have to do To secure the same thing Again and again So here's an example of Session management issue There's a zillion different authentication problems you can have there's no way to do justice to the examples here But in this case they're putting a session ID in a url That's obviously a bad thing You should not do that instead. It should always be in a cookie Anyway, there's many many examples of authentication issues So how do you avoid authentication problems again? Look at your architecture. Do you have six simple controls? Are they standardized? You know, have they been well vetted? Maybe you're using a third party product That might be typically stronger than something you build yourself Or maybe it's provided by the The container or you know the system the framework you're using so you don't have to reinvent the wheel And then anything you've had to build yourself, you know, you should assess I mean, you should of course assess things you're using too But clearly anything you've built yourself you need to assess to make sure it's done correctly And in fact, we have lots of guidance from well wasp on various factors related to authentication and session management Um, so I list five of them here These are probably the most important ones on this particular topic But there might be some Other ones as well One of the things I just want to mention real quickly for example is there's one on credential stuffing You might not have heard of this before but it's actually a pretty common attack For an attacker to steal someone's password database that they've implemented weekly So that the attacker can Get the passwords out of it And then what they simply do is try all those same usernames and passwords On other web applications To see if the same user is using the same credentials in another site, which is a common behavior Of users because users are lazy And so you're going to get A series of login attempts on your site where there's one login attempt per account So it's not going to look like a Cracking attempt where they're banging, you know hundreds or thousands of passwords They're just going to try one so they're not going to trip your You know three strikes and you're out login policy for example Um, so the question is can you even detect that attack? And if you do Do you do anything about it you block That attacker Well, you know if they're doing a distributed attack then I don't know how you block them So that's an interesting new problem That we're dealing with in the last three four years related to authentication So us put together a cheat sheet to give you some basic Ideas on how to get started, but this is still a very new area that deserves additional research Um, but at least you can be aware of this problem and think about do I care about it? Am I going to try to defend against it? What does oas say? Um, and certainly that's not a definitive article So if there's things that are weak or missing of confusing about that article, let us know and we'll Try to make it better for for everyone. But anyway, that's just one example of Some of the resources we've got available at oas Sense of data exposure is about protecting sense of data in transit and at rest This is a relatively obvious topic For the most part these days we're telling everyone to always use SSL for everything or hdps Whatever you want to call it, you know transport layer security That way your authentication tokens your session cookies your credit cards whatever is all being Exchanged encrypted on the network. Well, what about data at rest? This is where a lot of organizations fall down They don't encrypt data at rest because they don't think it's sensitive enough to deserve it or it's too much of a pain Or maybe they don't use encryption internally on the network because they don't see the risk These are the kinds of things that we're talking about here Ideally, you'd be encrypting all sensitive data wherever it is And it would always be encrypted on the network inside or outside Your environment So this is what a three is about. Here's an example of a credit card example Where maybe the app the app owner knows that credit cards are sensitive. So they encrypt them at rest But they didn't realize that some component was doing some logging And the credit cards were getting logged In the log files, maybe only when there was an error or maybe all the time And so there's a side copy of these sensitive files and the attacker breaks in and steals those From an unexpected location. So In this particular case, it's not even an encryption problem It's really they're logging sensitive data that they shouldn't log And the answer is not to encrypt it But rather is to stop logging the sensitive data in the first place and that way The uh, the data can't get stolen because it doesn't exist in this alternate location So that's frequently the best defense for dealing with uh sensitive data is don't record it Or throw it away quickly There's been numerous situations where like a merchant online merchant gets hacked Their transaction data gets stolen With just credit card information in it and other information that's sensitive and it turns out, you know, they got seven years of data available in this system Well, why why would you have seven years of this data online? Available for an attacker to steal. How much do you need to be available online like that? Maybe One year would be fine or three months would be fine. So if you simply trim that log Then you would significantly reduce the impact of a breach Without requiring, you know, fancy encryption or extra access control or so on so forth Now, of course, you still need to protect what's left in the log But at least by reducing the volume You've reduced your risk. So sometimes there's very simple things you can do to significantly reduce risk related to processing and storing a sensitive data that doesn't involve anything really complicated at all actually So anyway, here's a bunch of tips on um cryptographic storage. I did want to point out the password storage cheat sheet uh A lot of systems build their own password hashing solutions Sometimes those are very old legacy solutions that are seven 10 15 years old They're using really really old hashing algorithms. Um, so upgrading your storage solution So that you're pretty confident that if an attacker did get a copy of it You still have confidence that the attacker cannot reverse engineer the passwords out of it That's where you want to be and if you're not in that situation today Then you need to upgrade your Storage approach and you can do that in place without invalidating all your existing passwords. There are techniques For improving the security of password storage That are transparent to your current users So you can uh improve that without causing a significant disruption to your customer base So this is just an illustration of you know, people are typically using you know ssl Let's see on the internet, but they're frequently not using it And once they get inside their environment And that's a risk that you got to decide whether that's acceptable or not You know, what's the technical complexity of of adding? Internal encryption on the network and what's the risk reduction that you get? You know, is this a risk you're accepting? Or you're not even thinking about Or not so we're seeing a lot of insider threat going on probably 40 to 50 percent of the breaches that we're seeing are still being done by insiders So assuming that the inside is safe and the internet is is the only source of danger is a very bad risk Position to take in a lot of a lot of situations So anyway, here's some guidance on This again, make sure you use good encryption. It could be commercial encryption It could be Using encryption built into your programming language like java or what have you There are some very complex encryption solutions you can use but sometimes very very simple solutions are Just as good and have a lot less complexity The main thing is to identify your sensitive data decide What data needs to be encrypted? When like on the network at rest And then making sure you consistently apply that encryption Where it's needed and again as I said avoiding storage of data is frequently the easiest way to avoid sense of data exposure issues So we got I've already 35 minutes in so I'm going to go quicker through some of these others But I'm going to stop on the three new ones. Here's the first of the new ones So xx e stands for xml external entity And so the vulnerability is like an xxc attack Or xxc injections sometimes people call it xml the standard has this concept of an internal entity. So think of an external entity as either a url And that could be a file url or an htp url or whatever or it could simply be a variable Well, if you include this url or this variable in your xml document and the xml document came from An untrusted source like an external user That url can then reach out to whatever it's pointing to To access Data that it's not authorized for and potentially return that data to the user um, it can also be used to Cause a an xml document to grow Abnormally large and cause you to run out of Memory or disk space or what have you so let me show you what that looks like. I have an illustration here So in this first example, we have this external entity called xxc fun And that's now a variable so I can reference that variable here Um, but the variable refers to a file in this case. I put etsy password So here's the here's the rub here if xml external entities are enabled by your xml parser Which frequently is the case Then when this document gets processed It's going to actually reach out grab the copy of etsy password and replace that right here Now if you then return this xml document back to an attacker Then now the attacker has a copy of your password file Now typically these are caused by the fact that the developer had no idea that this was even a feature They're not using it. They don't give a crap about it. Um, but it's a feature that's available For an attacker to abuse Here's another example where you declare an entity. Maybe it's a abnormally large number of the letter a Let's say this is 10,000 of them and then you have another element that's got 10,000 references to Uh a then obviously this is going to expand in size to 10,000 times 10,000 whatever that is a large number So that's not a huge number, but you can see you can quickly Repeat this process and with a few lines of code create documents that are You know gigabytes or terabytes in size And of course that would exhaust all resources on the on the machine So that those are examples. These are trivial examples of attacks The question is how do you avoid these? Well, typically the basically the way to avoid these is Is either use an xml parser that has external entities disabled by default Which is common in some languages but less common in others Um or disable it yourself. So here's a java example of Parser called Xerxes or which is this in this case a document builder factory is the name of it So there's a simply a feature you can set called disallow document type declarations That will disable the xxc feature And so if it then parses an xml document that has an xxc entity in it It'll throw an exception saying hey, sorry. That's not allowed And you're safe Now in some cases you want to allow These external entities for these entity definitions But you want to say fine, but they can't be external. They can't point to the file system. They can't point to URLs So you can partially disable it without disabling it completely But it's very rare that I see situations where people are even using this feature at all So it's better off to disable it entirely. In fact, I would probably Execute all three of these Set feature commands typically when using this parser just to make sure Now this is just one parser of dozens that exist out there So what we've been trying to do in the xml Our xxc defense cheat sheet is list for every parser that we're aware of across many different languages Is it safe by default? And if not, how do you make it safe? And I've been actually working on that cheat sheet for years And so everything I know about xxc is documented in this xxc prevention cheat sheet Uh, which is obviously a fantastic resource for you guys learning about what xxc is and how to avoid it Um, so here's some basic guidance, you know, first off Are you why would you even accept? An unvalidated xml document from an end user I mean that is a common behavior. So it doesn't surprise me people do it But if you can avoid it, then you solve the problem But if you can't avoid it make sure you're either using a parser with an off by default or disable it yourself In some cases there are parsers that you can't turn it off And in that case you need to replace Your parser with a different parser that can be made safe Or is safe By default. So this is actually a very very easy problem to solve You just got to look for it Set a few switches and move on For the most part. So even though this is a big deal in terms of risk It's mainly because of lack of awareness and I suspect Now that it's so high in the top 10 The awareness will bloom in the next three years. That's the goal of the top 10 And then people will become aware of it and this xx e issue would hopefully Drop significantly for the top 10 in the next release Ideally you would drop off the list entirely. I don't suspect that'll happen in one cycle, but maybe by the 20 23 versions of the oas top 10. I would hope xxc would fall off Because everyone knows about this problem and the easy ways of avoiding it Access control This has been around forever The main thing is you got to make sure that the user is authorized for the functionality they're interacting with And are authorized for all the data that they're interacting with And in the way they're interacting with that data, you know, are they authorized to read it? Modify it create it, you know Destroy it can they grant other people access to that data, etc So it's very very easy to make mistakes in the access control area because it's all custom And tools can't help you at all in figuring out if you've done this right or wrong or what have you This is required a lot of custom Development work and a lot of custom verification work for dealing with access control So i've got some slides here on some examples like Force browsing a directory to get access to functions that you maybe can't see But can still browse to and you should still be denied access. Of course, it's trivial to modify the Identifier of a of an object reference and try to access someone else's account You know, these are relatively obvious attacks You just got to be really hyper aware of all your end points for functionality and data access And make sure you've built that Safely so we've got some examples here on how to do that Right on this slide here Security misconfiguration has been around forever a lot of people argue This doesn't belong to the os.10 because they don't think of it as a developer issue Maybe that's true, although with devops now configuration and It's all developer issue, right? So to me this is even more relevant today Then it was when we first introduced this way back in 2004 or whatever first came out I mean securely configuring your components your web server your app server your database Your firewall your web allocation firewalls Your frameworks, you know struts in spring and hibernate All of these components Have security configurations and people Screw them up. They don't have the the configuration in In configuration under configuration management They can't automatically deploy the same environment over and over Be consistent They don't have a good way of auditing the configuration to make sure it's correct And it hasn't changed in an unexpected way So a lot of work needs to be done around this and because of that this is still a significant risk in a lot of organizations And so anyway, we've got some examples of here and I'm not going to go into them But this is still a big risk and I think it's with devops is becoming even more critical People need to spend even more time on this particular security risk Cross-site scripting has been around forever. It's a complex Topic it has been dropping in the top 10, which is good in terms of risk Because everyone's hyper aware of it and it's been focusing on it But it is a complicated issue I really can't do justice to this topic here because I can spend a whole hour or four hours on this particular problem Um, so I'm not going to spend a lot of time on cross-site scripting I am going to mention that you know sort of traditional cross-site scripting where you include data in a page and That that script executes immediately Is kind of fading away because now we're doing everything with ajax and things like that So the the page is typically static and then we send data to the page using Ajax calls And we can still introduce cross-site scripting when we do that because we're using a javascript method Or a javascript library method That if it's given snippets of javascript, it'll actually build active javascript when it updates the Dom for that page And you can end up with cross-site scripting that way and that's a type of cross-site scripting called dom-based cross-site scripting Which is a very complex topic To talk about and I can't really provide Do justice to that there is Several cheat sheets on the awesome. Whoops Yeah, there are several cheat sheets related to Cross-site scripting. I just want to mention those here The original one is the xss cheat sheet, which was the first prevention cheat sheet we wrote And that talks about you know embedding user data on the page as you build the html and the javascript and the links What have you and that still is definitely a risk and people still do this But that's not the common way of building web apps today Uh, as I said, most of them do dom-based access or dom-based Are ajax based websites whether using uh javascript framework is to dynamically change page on the fly And so we've got another cheat sheet on xss related to dom-based xss which Tries to give you some guidance on this topic Um, so I definitely read it But it is a complicated issue. It's very the solutions are very dependent On the javascript framework you are using so there's no way in this one cheat sheet We can give everyone the guidance they need Uh to for any kind of framework you really need to understand Which javascript methods? Can create active content and which ones cannot And then for the ones that can you need to make sure you trust the data That you're passing into those calls Or you've validated that data to make sure it's safe Before you do so And so it can be very tricky to find dom-based cross-site scripting flaws And then fix them Which is of course somewhat of a good thing because it makes it hard for attackers to find them and fix them too However, there's some really clever guys out there that are really good at this stuff Probably far better than the average developer And so the advantage is definitely in the attackers court In finding and exploiting dom-based xss versus The developers avoiding all of them in their web app that they're building So the second new oas top 10 topic is insecure disutilization So it is not uncommon for applications to take a plain old, you know, like a java pojo or whatever language is which plain old java object So it's a plain old whatever language you're using object And serialize that into json or xml Or could even be binary And then send that object to somebody else browser or wherever put it in database something and then Try to accept it back from the user And then turn it back into the object it originally was The problem is the attacker of course can tamper with that serialized object And frequently if they're clever about it, they can actually get arbitrary code execution as a side effect Of the deserialization process and then it's completely game over So this is a really big deal that Has really ballooned in the last four years as people start focusing on this particular risk I have a few examples. These are all open source Or public examples With with cv's associated with them all these happen to be last year But there's many many more. These are just a few Um And these are all in uh, usually typically in open source components. Some of them might be a commercial products So we've got some javascript libraries. We've got some dot net components. We've got some java components Uh, you can see this is not specific to any particular language In this case the solution to these four specific examples Is to upgrade your component or your product to a version of that product That has a fix Right, so that makes Uh, you know, avoiding use of known vulnerable libraries, maybe even more important Which is a nine the next topic Um, but if you have a deserialization issue In, you know, your code Um, oops. I went the wrong way. Sorry If you have deserialization issues in in Your code then There's a number of ways to fix it. So my first suggestion to avoid deserialization components Are issues is to just don't do it. Don't send serialized objects to your users and then um You won't have this problem, but if you must Then you need to make sure that those components are are safe So how do you make a deserialized? Uh, object safe before actually trying to deserialize it. Well, one way is to provide some kind of integrity seal So in other words, if you send it to them and you're expected to come back unmodified Sign it in some way and verify the signature and if it fails, then you don't deserialize it um, you can also of course harden your deserialization mechanism to only support a limited set of object types and That'll reduce your risk And there's some techniques in the deserialization cheat sheet down below Where they give you specific guidance on how to do that in certain situations like in java, for example and things like that um So there are there are some basic techniques for avoiding deserialization, but a lot of these are very specific to the The technology that you're serializing and deserializing And but of course step one is awareness Are you even aware that you're serializing objects? sending them to users And then having the user send them back to you a lot of times they don't realize they're doing it Maybe it's automatically happening because some framework hydrates and you know dehydrates these objects for you or And you're not realizing it's happening um, so Again, top 10 is about awareness. So step one is are you even using serialization technologies at all? And if you are you intend it did you intend to? Uh, and if you did what steps are you taking to? You know avoid that a particular problem. So this deserialization cheat is very new But I certainly encourage you to review it and make your friends aware of it A9 is about use of non-vulnerable components That's been uh, it was in the introduced in the last top 10 as well There's actually we got some pushback that people thought that was silly Um, and then very quickly people realized now that's pretty major deal Um, and in fact some of the biggest breaches that have happened in the last four years have been exactly because People are continuing to use non-vulnerable components because they have no mechanism for detecting and fixing these issues quickly And in fact the attackers know this so the life cycle of X you know cve is reported in library x to live exploits are happening against that cve Have dropped from you know One to two months maybe 2012 2013 to 48 hours, maybe even 24 hours So think about that. You're using a framework in your web app The cve comes out right now 330 eastern time And in 24 hours The attackers are going to start exploiting that and taking over servers because it's got a remote code execution issue How are you going to fix? your portfolio of applications that have this problem now not every app will have this problem, but let's say, you know, you got 12 apps in your out of your hundred that have this specific problem can you Identify those apps develop a fix You know like upgrade the library to the patched version regression test it and deploy it in 24 hours The answer for most organizations is no not even know as hell no And yet that's where we need to be And so this is a big deal. There are some commercial technologies out there that can help you Detect these issues. There's some free technology like awas dependency check that can help you detect these issues But you also might need some kind of patching technology that allows you to mitigate the issue until you deploy a real fix Because the light the time cycles are getting so quick That actually rebuilding and redeploying an app is just Impossible in the time frames that we're we need to deal with this kind of issue today So you guys heard about the you know Equifax for example uh, they they got hit by a Struts exploit within Few weeks or maybe just a few days of the release of that uh, cve back in like may of 2017 And you know 140 odd records 140 million records got stolen because of that breach So I only got a few minutes left and then I'll take questions wherever wants to hang out the very last one of the awas top 10 is lack of logging and monitoring and as I mentioned before Web apps are frequently very polite They'll let people attack them all day long. They'll simply provide error messages like sorry That didn't work. Please try again And of course the attackers are happy to oblige and they'll attack and they'll attack and they'll attack until they finally find the vulnerability that they are looking for and figure out how to exploit it and then they'll uh Do some damage, right? So why are our web apps so polite? That's nonsense You know, you wouldn't let someone walk up your front door and start chopping away at it with an axe For two hours without calling the police and telling them to take a hike But we don't do that with a typical web application So we need to we need to log security events We need to have standardization. We need to know we have sufficient security events We need to make it easy for developers to comply with this policy Like hopefully build this logging into standard security controls Then they make it easy to add custom events when they have to build custom controls We need able to distinguish these security events from non security events that we need to monitor those events So that we have, you know, real-time or near real-time event detection So we can raise alerts Maybe even lockout attackers um Detect the defined thresholds of events not just single events So that when a threshold is exceeded over a period of time that triggers Some kind of action But there's very few systems that we see that have anything close to what I would call you know, sufficient security logging and monitoring in the typical web app and OS agrees by putting it in the top 10 um One of my favorite OS projects has been around for a decade. It's called the loss app sensor And it talks about this kind of stuff. It gives uh, there's a reference implementation, you know for a java library There's uh guides that are written really well written guidelines to give you advice on how to implement this kind of stuff So OS has been thinking about this problem for a long time It just hasn't risen to the level of the top 10 until 2017 um, but just like you don't have Network like today if you didn't have network layer intrusion detection People will look at you like you're crazy Right, we've we've had that You know, there's been an expectation for network level ids for the last five if not 10 years But there's no such expectation at the outlayer yet We're hoping the top 10 is going to tip that scale and hopefully within three to five years People will look at you funny if you don't have really good application layer intrusion detection um That's really the goal of the top 10 putting this in even though it's number 10 of the list is hey, this is really important This is a big risk If you don't have good security logging in monitor So anyway, I got some summary slides here that I don't have time to cover Uh, and that's all I've got I like I said, I'll make the slides available And I think they wanted to record this session and make that available. I that's totally fine um Is there any questions or I don't know how you want to go through the next part of this Darian, but uh, I know we're sort of out of time But I'm happy to hang out for as long as people have questions. So whatever you want to do Any questions from anyone in the hangout or in the room there? Yeah, I haven't seen any come in through irc or YouTube yet, but if anyone has any this would be a good time And people could send me an email later So I'm not very hard to find But dave.wickers at owas.org works. I'm happy to answer your question Today next week next year I do get questions out of the blue once in a while and I'm totally happy to Help you my typical answer is I point you at an owas resource that frequently I helped write and say Hey, why don't you start here and if you got more questions? ask um Anyway, I'll take questions at any time. So Well, I think uh, I think we can go ahead and wrap up if there's no questions We don't want to keep you too long dave again. Uh, thanks for doing this presentation. It was great Really appreciate you sharing your time with us uh Yeah, it was excellent. Thanks a lot all right It's basic stuff for me, but I think it's getting this awareness out is great So I'm really appreciate you actually inviting me to do this Because that's what the top 10 is all about. We want to spread the word. So let everyone else know about this I think either hopefully watch the recording or at least get the slides reference the cheat sheets And uh, a lot of these again are that hard to deal with It's awareness lack of awareness is our enemy still in 2017, which is really unfortunate Anyway, that's all I got. Thanks. All right. Thanks again. Thanks dave