 Well, good morning, good afternoon, good evening, depending on where you are on the globe. Welcome to First Virtual Dev Conf. My name, as the slide says, is along Mureinek, and I work for Synopsys, where I manage R&D for Seekers, Node.js, and .NET agents. If you haven't heard about Seekers, or rather haven't heard about Seekers yet, Seekers is probably the best IST solution out there today. But as fascinating as IST may be, it's just not my topic today, so this is the last time I'm going to mention it. Instead today, I want to talk about security awareness, specifically security awareness for developers. So before I go into things, I just want to set expectations correctly. Well, okay, these are slides or lagging a bit. So I just want to set expectations correctly. Listening to this talk will not make you a security expert. In fact, no 30-minute talk will make you a security expert. What I do hope to achieve today, though, is to spark your interest in security, to raise awareness to security, and to help you get to a mindset, if you don't have one of these already, a mindset of thinking about security during your day job, as you code. So in the information security industry, we like to say that security is everyone's responsibility. Just as 100% true, I do not dispute this for one small second. But I believe that it all has to start with developers. Although security is everyone's responsibility, the process often starts with developers. And if we as developers don't introduce security flaws to begin with, if we think about security as we're coding and avoid security mistakes from the get-go, we can make everyone else's jobs a whole lot easier. This is especially correct, especially true in the post DevOps quote unquote revolution, where developers are empowered to come up with new features on your product, code them, test them, or more often than not lie about testing them, and then push them straight to production. So in such organizations, if developers are not aware of security and don't approach development with a security mindset, no one else will do this. So security is an absolute must for us. Problem is, not everyone can be a security expert. And in fact, I don't think everyone should be a security expert. But just starting with awareness can take us a long way. Enter OS. OS stands for the open web application security project. This is an organization devoted to promoting awareness of security, to promote knowledge of security, and to promote secure development practices. Now, it's in the name, the operative word here is web. But first of all, if we're completely honest, in today's day and age, if your application, if you work and interact with the outside world in some way, shape or form, chances are there is web involved somewhere there, be it an HTML, JavaScript, whatever, UI, or all these APIs of HTTP, the concept of web is there. Web has long since stopped being your personal page on Keraset or whatever. And second, even though I am going to discuss web today, the good news is that most of not all of these concepts are easily transferable. So even if you're not a web developer or web development is not part of your day job in any way, shape or form, the concepts are still meaningful and are still useful, hopefully to every developer. Specifically, today I want to talk about the AOSP top 10 list. This is a list that gets updated every couple of years. In fact, they're in the process of updating it again. And they were kind enough not to release an update between the time I sat down and wrote this presentation to the time I'm presenting it. So today I'll be talking about the AOSP top 10 2017 list. But regardless of the revamping it gets through every couple of years, this is the top 10 list of the most, the 10 most influential, most common, most impactful security vulnerabilities that we see in the world. Just to clarify, this is not a list of CVEs. This is not a list of specific security vulnerabilities. It is more a list of concepts. The top 10 you should keep in mind while developing. Not to say that if you go over and tick the boxes for each and every of these 10 categories, your application will be 100% safe. I don't believe anything can be 100% safe. But it's a really good place to start. Unfortunately, I do not have the time to go in depth. So to in, excuse me, I do not have the time to discuss in depth all of these top 10 categories. In fact, each of these can easily deserve its own half hour talk, hour talk, whole day training session, you name it. So instead, I'm going to focus on my own top three. Not to say that the other seven aren't impactful or dangerous or something you need to keep in mind. But I decided to focus on these three for two reasons. First of all, these three in my mind are the top three that are really solely a developer's responsibility. And if we as developers do not address these three issues, chances are no one could do it for us. Second, these three are probably the easiest to demo. It's been a long day and I feel a bit selfish. So I'm going to take the easy way out. Now, for each of these three, I'm going to discuss them. I'm going to demo a horribly written application that has this vulnerability. And again, I emphasize these are horribly written applications. I will share the source code. It's under the MIT license. Please do not test it into your applications. These are intentionally vulnerable applications. Anyway, I will demo them. I will show these vulnerabilities and I will discuss how to overcome them. All of my demos today are going to be in Nigeria for a couple of reasons. First of all, Node.js is open source, so on-brand here at DevCon. Second, Node.js is JavaScript. So even if you are not a Node.js developer, any web developer should feel comfortable with a syntax here. And to be completely honest, even if you have never seen JavaScript before, this is pretty straightforward syntax. I'm not using any bells and whistles. So hopefully, it will be easy to understand for anyone listening, even if you are not familiar with JavaScript. So that was an extremely long introduction. Let's get into things. The first category of vulnerabilities I want to discuss is A1 injection. Chances are you have heard about injection attacks. Specifically, you've most probably heard about SQL injection attacks. SQL injection is in fact so famous. I think you'll be hard pressed to find a talk about application security that does not discuss SQL. So famous, it has its own XK city comic store. But since my goal here today is to raise awareness, I'm not going to discuss SQL injection. Instead, I want us to consider injection in the oldest terms possible. Injection or an injection attack is any scenario where your application receives input from the outside world, untrusted input, which is any input, in fact. And uses it in a way where the application seems it's just text or something benign. But due to some special character or characters, this halo of this input gains syntactic or semantic meaning. That's a mouthful. Let's see a demo. So I have here a basic login form or rather the back-end handler for login form. As you may notice, this login form operates on the honor system that accepts any combination of username and password, which is of course a horrible security practice. Never do that. But for the demo's sake, we will use the honor login system. And once a user is logged in, we will log the fact that they have logged in using our enterprise-grade login system, which is just printing to the console. Let's see the slide. Here a really ugly login form, because to be completely honest, I'm not a very good web developer. Nonetheless, it does work. And if I input my username and password, I can log in and I'll get log message that says along logged in. Now I can, of course, explore the form itself, but it's not always convenient. So instead, I will use code to send a payload which contains a line work backslash n. I'm going to send this to log messages, along logged in, and uranic logged in, which of course makes absolute sense. I've just sent one single request. So by using a line work, which has the semantic meaning of a new log message, I was able to inject or falsify a log message. Now, this is an I, this is a application that doesn't do anything and no one overlooks these logs. But if you had a real application with real logs and monitoring system and events triggered by this monitoring system, the ability to falsify or inject a log message can really cause a whole lot of noise. Providing injection attacks is well easy in theory, not always easy in practice, but the cardinal rule is we never trust any input from the outside. We do not trust our users. Input is potentially malicious. So if you can avoid any input from the outside, that's excellent. Unfortunately, my systems can't because the reason we have these systems is to get input from the outside and do stuff with it. If we cannot avoid it, we have to sanitize this input. We have to think about the context it's used in, think about what special characters could gain syntactic or semantic meaning and then escape somehow. Now, I'm sure everyone listening to this is super smart and you can all implement your own sanitizers. I'm sure you can do this. Please don't. Unless you have a really, really good reason to invent a better rule, don't reinvent the wheel. Every framework, every programming language, every programming environment should have its own popular battle tested proof ways to sanitize your input against any number of places that can be abused or injected. So find the right library and please use it. Let's move on. So that was injection and perhaps a few too many words. The next category of vulnerabilities I want to discuss are XML external entities or XXE. Well, I started programming in the Iron Age. XML was everywhere. In the later years, it kind of fell from place, but it's still definitely out there, definitely being used and can definitely be a source of security vulnerabilities. The cliff note for those of you who aren't deeply familiar with XML is that XML is awesome. XML has a ton of features which developers sometimes really lack, which have a ton of power behind them. But as Peter Parker or brother has told us with great power comes great responsibility and that could be some such a thing as too much power sometimes. Specifically, I want to discuss XML entities, some external entities. As programmers, we don't like to copy paste. We'd like to reuse code. And XML entities let you do XML. XML entities allow you to define entities in the document and then reference them in various places and that document in order to avoid duplicating entries. Now that sounds like a good idea, but well, that's just in practice. I have here a very basic web application or web API that receives an XML payload, passes it and returns the text of the name element. Sounds straightforward, right? Let's see what can happen. So this time, I'm not going to offend your eyes with my ugly frontend skills. I will show you though that I can use curl. Hopefully, you can see this to send a payload, which has a root element, name element, and then it's alarm. And this web API will return name is alarm. Now, if I use curl to send a more interesting XML with an extended entity, I guess that name is a secret. Name is, sorry, this is a secret. Now, this is not the path of the entity that I defined. This is the actual content of the file. Now, again, here, this is a nine because the system nobody uses. But by sending an XML payload to a web API, I was able to get the content of a text file. This isn't even an XML file that has nothing to do with the application and just happens to be sitting there in the file system. Now, what would have happened if I were not the security conscious developer that I am, and I would have run this application as root, which nobody should ever do, but people do, of course. And what if my payload wasn't a path to this file, but an entity referencing file colon slash slash slash. Well, a whole big oops, right? So, even though XML is not as prominent as it used to be, it can definitely still pose a security risk. Luckily, avoiding XXE attacks is not that one. First and foremost, if you don't use XML or at least don't use XML to communicate with the outside world, you don't get your XMLs from external sources, you're good. If you do use XML, well, first of all, see if you can stop using XML. If you can't, double check your parser. A lot of parsers don't allow external entities at all. So, for this use case, correct. A lot of parsers that do allow external entities, don't allow them by default or could be configured at least not to allow them. So, if you can tweak the parser configuration to this allow entities or this allow external entities at least, again, problem solved. If you can do neither of these things, you have absolutely no choice, no other choice, but to write some code and to introduce some mechanism like an inclusion list or an exclusion list. Inclusion was always better to filter and make sure that your entities only access the files that they are allowed to. That's kind of a pain to do, but the good news is A, it's possible and B, hey, all developers here we like writing code. So, not that bad. The last category of vulnerabilities I want to discuss today are cross-site sculpting, A7 cross-site sculpting or XSS. Now, cross-site sculpting is kind of sort of an injection attack, but it is so widespread, so ubiquitous to web development that it got gets its own category. Cross-site sculpting is any number of ways where an attacker sends a payload to a website or web application and this payload instead of being treated as benign text is somehow executed by a victim's browser. So, this payload becomes interpreted as HTML as JavaScript usually, but generally speaking as any payload that a victim's browser can interpret, even VB script in some browsers we will not mention their names. That sounds like a mouthful, let's talk specifics. There are a number of ways to create XSS vulnerabilities. I'm going to show here a technique called stored XSS. This technique, the attacker sends his or hers malicious payload. It is saved by the target application, for instance, in a database and then in an unrelated time when the victim browsers to site this application, this malicious payload is retrieved in this case for a database and executed by the victim's browser. Let's see some code. I have here a very simple comments form. Now, when you pass to it, you will see two things. First of all, a form asking you how is DevCon so far and allowing you to separate your comment and the stored chronologically all of the comments from previous users. The backend handler of this form is pretty straightforward. It just takes a comment and inserts it to your database. You will notice I'm using bind variables here, so this application is safe from the aforementioned SQL injection attack, but of course this does nothing to prevent XSS attacks. Just for the sake of completeness, once this comment is inserted, the location is refreshed back to the form. Not really critical to display this vulnerability, but just to explain the application you're seeing here. Let's see this in action. As usual, I have an ugly form here because I'm not a very good web developer, but nonetheless it does work and if I put in what I think DevCon is great, I can sublet it to pages refreshed and I get my comments back. As always, I could use this form to try and exploit the application, but it's much more convenient using code. So I'll use code, send a payload which contains some HTML also script tag and there's some inline JavaScript that refreshes the pages location. Next time the victim launches here, they will be redirected to the DevCon fan page. Like all the demos in this session, this is kind of harmless because again it's an application that doesn't do anything. There's no imported data here and my attack was to redirect to the DevCon fan page which knock on wood is a safe page. But if you think about it for a second, I got a page to execute, I got sorry, a victim's browser to execute some arbitrary JavaScript and instead of redirecting DevCon fan page, I could have done all sorts of damage. So the defending against XSS kind of goes back to the injection playbook. If you can, don't take any input from the user. Usually you cannot. If input you have taken or taken from a user has any chance to be displayed in a browser, you have to sanitize them. And once again, please do not try to reinvent the wheel. I'm sure everyone here is super smart and can do this. Find the sanitation library or feature that matches your application framework, your programming language, and put it to good use. Now I think I'm running out of time. So let's summarize. We have seen here a couple of, we have seen here three of the top 10 hours. Sorry, we have seen three of the top 10 of the hours top 10 vulnerabilities. This is not an exhaustive list, but I do hope it kind of sparked your interest and raised some awareness and made you feel like going out there and learning some more about security. As I said in the beginning, security is everyone's responsibility, but it has to start with us developers. Sometimes because we were learned there, sometimes because even if we are not alone, if we can avoid introducing security vulnerabilities to begin with, it will make everyone else's life so, so much easier. The bad news is that we cannot always security experts. The good news is that we don't have to. First of all, because awareness really goes a long way. Second of all, even if we are not experts, us developers are really, really good at using other people's knowledge, even that we aren't, even in areas we are not experts in. Now that sounds kind of surprising, but think about it for a moment. I, for example, am not an expert in writing bug free code, but I can use other people's knowledge by implementing automated tools such as unit tests and component tests and system tests and integration tests and whatever tests to help me reduce the number of bugs. This will not be perfect, but this will drastically reduce the number of bugs in my software, even before any QA engineer takes a look at it. Security should be treated with the same mindset. Now, this is not a sales pitch. I'm not going to advocate any tool. On both sides, there are a bunch of really good security tools out there that can really help you develop more secure applications. There are several different ways of doing this and several different phases in a life cycle just might apply, but at the very least, the good tools will easily plug into your pipeline. So if your pipeline does not have any sort of security considerations, if you have a pristine pipeline that handles code quality with lentils and files with tests with nothing for your security, nothing for your security, you may just be overlooking a major part of your responsibility as a developer. So find the tools, suit you and see how you're integrating into your CI. With that, I think I'm really running out of time, so I just wanted to do a couple of things. The OS top 10 project, which I've been discussing, the source code for all of my demos here and in fact for all of the entire top 10 is available in my GitHub. And once again, I cannot stress this more. Intentionally bad code, intentionally vulnerable, please do not copy paste it to any application you care about. And of course, just to give credit where it's due, the code which I've been using throughout these demos. With that, I'm really running out of time, so if there are any questions, I'm happy to take them. If there are not, I'll just take this opportunity to say thank you for listening. Thank you for your time. And if anyone is interested in discussing these topics more, feel free to reach out to me, my email, my LinkedIn, over here in the chat, I'll be here for a couple of hours longer. It's kind of late in my part of the world, but check me up with an email or Twitter or LinkedIn or whatever and I'll be happy to talk. And once again, thank you everyone for listening and thank you for your time. Thank you all once again.