 So, you must be wondering what this lady is going to talk about security. So, let me start from where this all started for me. I have been working, this is like way back in 2000, when I was working with a multinational company and then we were releasing a product which had an 100 million dollar revenue at that time. Interesting, we had just shipped the product and after lot of late nights had great fun shipped, we just settled down and we were still partying in fact. And then one of our customers called up and said there was a nasty bug. Nasty bug was bad during those days because that was the pre-cloud era. We used to ship products in CDs, burn them into CDs, put them into red boxes and ship them out. Now that, I was in the San Jose office where we had hundreds of boxes returning back because of one nasty bug that we had left into the code and it was almost a humiliating experience to sit as an architect and see hundreds of boxes getting returned from channel partners from our distribution specialist from our vendors just because there was one single security bug. That's where I started being a little more passionate about fixing bugs, fixing security bugs, trying to find it, fix it much earlier than where it started. By the way that bug was a fairly simple one. It was in some random error condition that we were throwing up the admin password in clear text which was not so great but yeah, but it was nasty beyond words because we had to recall CDs during those days. So that's where I've been almost a decade or more primarily around security, security reviews. I'm an ethical hacker, been around security for a long time but that's what got me started really. So let me just get started with why would any of us move into a house that does not have doors or windows? We want. We need all the doors done, all the windows done, all the last latch, all the last lock done. Before that we wouldn't enter into the house, forget occupying it. Even if there is one bolt that's missing we'll say no, this has to be fixed. That's where all of us are, right? But reality is here, 60% of code that's there on the bed, that's alive today is almost like a house without a door or a window. So that's why the house is actually open to vulnerabilities around the neighborhood. You can have only buglers around your neighborhood come and attack your house. Pretty much, there is nobody else who will come. But code that is on the web is pretty much open to the entire world but then we take the least chance with respect, most chance with respect to that and say yeah, you know, let me put functionality, let me get it working, let something go wrong then I'll figure out what to do with it. Only any time that we say no, let me fix it before it goes and 60% of code is functionality. Maybe there is time pressure, there's functionality, there's competition, whatever. But most of our ship code that's functional and not really closed, secure. So the focus of my talk today will be about how to make jQuery code a little more secure as we write it. So the agenda of this meeting will be common errors that we as engineers, we as developers do. It's not to talk about bugs that are in the jQuery code, vulnerabilities that are seen in the jQuery code today, I'm not going to talk about that. I'm going to talk about bugs that we make as engineers, we all make mistakes. I'm going to take some very popular examples and then explain what the problems are around it. I will talk about how to overcome some of those bugs and then the tools around it. Any time, feel free to stop me, ask me questions or we could do it at the end of it. Yes, most of it would be. I would take very popular examples so that you can relate to what I'm talking. One big thing that we have to remember is hackers always work around barriers. No, most hackers will not go and break your barrier and say, oh, I've broken this for you. That happens hardly once in a way where you hear some government website hacked and then he says, oh, I hacked it. I hacked it. Don't do all this. They just keep walking around nicely, safely, never realizing, never using your gate that you have put. Keep using it. You never realize that it's been used for like a period of time before you knew it was used like that. So very few hackers go back, bring down the website and say, oh, I did it for you. Most people just work at the background without you realizing what is it. So hackers work around. They never come to the fort and say, OK, here's what I did. OK, so let's get started. I would not go through all the problems, all the security, possible security risks, bugs that we could. I would take a few of them, explain them in depth, go over what are the possible examples, scenarios, how to fix them. We could take others maybe offline. One thing that we have been talking even in the previous session is there are thousands of scripts that are readily available. That's reality today. All of us as engineers feel very nice when we have to, say, put a, put some slider. Oh, we go search, Google search. There's something, throw it in. That's the greatest thing we can do. And then, oh, slider comes up. Next, like you need a login dialogue. There is some authentication you need. Something comes up, you're done. This, somebody was saying about this, you know, Stack Overflow based development. Let me also do Google based development. Search, you get it, pull it in. Yeah, it almost works there. Now what happens? It's nice, quick development, great. All of us are doing nice. What's the problem? Now let me take a very popular example of a timer JavaScript. Apparently, this was a JavaScript that was a, that was a timer that was used, that was very popular. This script was used by a lot of engineers like us who used to, you know, generally pull in code to work. Now look at what happened in this script. Is that, is that the site that was using this script suddenly got blocked by Google? So the guy who was hosting this site had no clue about what was happening to his code. Why did he get blocked? His code seems right. But he was using this timer. Now what is wrong with this code? I'm not sure if it's readable. Is this, look at what was hacked and it was pointing to a malicious website. An even more interesting part of the code is this. This if statement compiles to true only on IE. So you look at what happened. There is, there is somebody who's introduced a malicious code inside into a JavaScript and then he's also put some if condition which executes only for a internet explorer scenario. Now this was a problem obviously which like most of us when you are taking a plugin looks nice for us to start working with it. So that was just an example to say what could go wrong? Yes? Yeah, you choose to break on all, all IE's apparently. Okay, so what can go wrong when you pull in plugins like this? The plugin site is down, which is like, you know, most of us developers are like, oh, you know, today I wrote something great. I want to share it with the world. I share it. After some time I lose interest. My site is down. You don't know, you know, you are left in a lurch because of me. Second is this whole compatibility issue which, which like, no, we all are, you know, swimming against pretty much. You know, you do something, there is some other compatibility, something goes wrong and then goes down. And there is, most often developers are not committed to keeping it for lifetime. I mean, it's just a fancy hobby that, you know, oh, I just created something new like I feel like putting it on the web. I put it. But then am I committed to it for the next five years? No. Am I going to keep it alive and then, and then fix bugs over it? Almost not. But then we, as people who are consuming it, assume, you know, assume it's forever, most of the time. And that causes huge problems. Now, the worst form is really this. The plugin site gets attacked, code gets in, code gets injected and then your, your site is down. Pretty much, you know, your site is now, is now spreading the malicious code out because the guy who started it is no more interested really in the, in the site that he's hosting. So you want your site to be secure. Pretty much you don't, don't use any third party hosted libraries unless you're 100% sure. 100% sure that he's going to keep it alive. He's going to keep it updated. He is, he is, he holds security higher than you because you are using him as a library there. Okay? So you cannot assume that it's going to be as much as what you want. In case you're using it directly, which I would strongly recommend, don't do it, use some tools to verify it, which I'll go over. Except for Google, CDN, general thumb rule is don't do it. It's not worth it, it's not worth the effort. You're just getting into trouble. Let's, the next problem that I would talk about is URL encoding. URL encoding is an interesting thing because what have, okay, we know HTTP URLs need to be encoded because there are alphanumeric characters, there are special characters. You need to encode, you need to escape, great things, we all know it. Unicode character support came in because multiple languages needed, all that, everything came in, protects us from cross-site scripting, great so far. What does URL encoding get us into as trouble? You can really abuse the encoding mechanism to the extent that you could. You could basically escape encoding with like, with like, you know, special characters to create a URL, which could cause damage to you. I'll, I'll go to a very specific example. The bigger problem is that client and server start interpreting these as valid requests as long as they are not able to figure out that it's an encoded or an escaped, escaped URL with you. And most often hackers disguise URLs, disguise then, use encoding to disguise, rather than to encode really. So you are into trouble as it starts, okay. Now one very popular example, that's a little old, but it's interesting. You see this, this was the code red worm. This is, it was a URL encoding problem. Nothing seems wrong. Look at this part of the thing. It was an assembly shell encoded in 16-bit sequence using a URL encoding, using, using Unicode encoding. It was an assembly shell sequence that got encoded. And, and what did it do? It was simple. Percentage, 1990, translated to two no-ops, which basically translated to two no-ops on an X86. And, apparently, there were 12,000 IAS servers that went down over this one hack. The estimated damage was 500 million, over a simple percentage 1990 that went out. There was, there was nothing, nothing too complicated in it actually. Okay. So, you see real world pretty much, the things that you don't look for is what somebody hacks at. It may not be something that you can apparently see and say, oh, nobody's going to do it. Never happens. Which is why that whole window example comes back. People are waiting to see which door can be opened. And that's reality. Okay. Solutions. Simple. Avoid using get method to submit data. That, that I will explain a little more in detail, but avoid it to submit data because that can cause you more URL encoding problems than like normal. Don't ever rely on client side validation. Client side validation is pretty much hackable the other side. So, there's nothing that you can securely keep yourself saying, oh, there is client validation, there is this that I've done, no use. On the server, importantly, it's a fail. Any input that does not pass is a fail. A default data processing should never be a pass. Any data that you ever get should be a fail unless it passes certain things. It can't be, okay, I'll pass it down and then check for error conditions. You fail it. You don't pass it always. Understand how the RFC syntax for the URL validation, URL encoding is. There is, RFC clearly mentions how to do it. You'll have to, you know, figure out how it does. And remember different web servers have different things that they, you know, support, and things like that, which is going to, you know, vary. Example, the percentage you buy is. So URL encoding in summary is basically hackers can escape, escape unicode characters, escape, escape, use a set of sequence of characters to disguise what has been sent to you. Unless you are careful over what is being received at the server, you're not going to be able to manage what has come. So always do your security check after the data is decoded. Don't, don't do the security check and then decode data. Because once you decode your data, you really don't know what has gone wrong before that. So this code red bomb is a great example of seemingly simple sequence which went wrong. The next problem that I'll talk about is cross-site scripting. This is a famous one. Cross-site scripting over years has cost more than 18% of all web hacks today. Cross-site scripting works dramatically simply actually. Somebody sends you a link to your own bank and says, sbi.com slash something. You think unless you see the person who sent it, you're going to click it, which is easy. User, now you as the user now sends out this script onto sbi.com because you go send it there. Now that's so far good because you haven't realized from whom the mail came in the first place. Now the script is returned executed on your browser. Now what happens? The script has now captured cookies of your session down and that's where he's able to steal your data. Now the sequence started with you doing a simple thing of taking a mail from somebody and then just clicking on it. But that's reality. You're going to continue having hackers who are going to continue sending out mails like this saying, you have one million tomorrow. All this we all keep seeing these mails. It's not anything new. So how do you as the web server protect yourself and also your users? That's the focus of this. So cross-site scripting is the second largest way to hack after SQL injection. So basically cross-site scripting there are like three different ways that people do cross-site scripting. One is a persistent cross-site scripting where what you do is suppose you have these forums you have wiki pages you put a script there and wait for somebody to click it. So the script is already thrown into your website and then somebody is clicking it and then the process starts then this whole session cookie everything starts from there. So the first is persistent where it's basically already thrown into your website. It's thrown there and then you start. Reflected one is more where where you are not it's not thrown into your website but it's more of data that is given as input. Let's say I'm taking a user name and password. As a part of that input he hacks it in. From there you are now again getting into trouble because from there like the script starts executing into it. Dom-based access is the most dangerous one because at this point the server is not even in picture. The client sees the web page your user sees the web page he assumes everything is right he has no clue that something is already wrong. Somebody is injected something it is showing something that you should not see in the first place. So there is no way to protect against the Dom-based accesses from the server. There is really no you will have to protect from the you will have to protect how you write code rather than say you know I will go and save it the other side. What can a hacker accomplish? Most hackers look for cookies. Cookies of sessions sessions of your bank sessions of your social network logins sessions of anything. Basically session IDs session data is what is the most interesting data mostly for hackers. They use that and then transfer it back again as an authenticated session because the session is now authenticated you read the cookie you have an authenticated session you are ready to go. Key logging is the next one where your key key sequences are now getting stored where your what you type start getting stored and then you know what you can get when he wants. So what hackers specifically do as they start off is wait for you to bite it. Most often people wait for you to bite it and then see okay see most of these reflected accesses are like Dom-based accesses needs social engineering that is you just throw out it and wait for somebody to click it wait for something to happen wait for somebody to have logged into sbi.com and still come back to your website that's when the session is alive and that's when you start getting data about all this. So that's more of what they wait and watch this whole thing and you will have to be you as developers need to be extremely careful over some of this. I'll just go over this Dom-based accesses a little more because it's more interesting from the way it starts. Look at what the attacker did he sent out sent out and said check out this see the attacker servers this website is your website he sent out and said check out this he's done nothing really wrong he sent you website slash search website is your website which you always trust which could be facebook.com sbi.com which you always trust you don't really worry about the site he had a keyword of a script the keyword where he sent a script what happened you harmlessly clicked it your end user clicked it went back to the server server no clue server assumes you are the person now the server has no clue that it's already injected in he thinks your your app is asking it he returns back the data now look at what happened he got it back and now data is already in into the script the script now sends back the cookie information back to the attacker server now the sequence of what happened without the server having any clue of how he actually sent out information is very interesting because of the whole way that you can do DOM manipulations at runtime really that's the real problem in this whole thing ok so going to solutions on this I'll give these are basically thumb rules that people keep saying because there have been enough of study over XSS being the worst form of attacks for us don't ever set inner HTML or dot inner HTML directly don't it puts you open to more attacks set use set inner text avoid APIs that can turn strings to code like your set interval set time out these are which can just turn it and then you are back to trouble use strict content policy I will talk about this a little more untrusted data should never be mixed with your HTML content untrusted data your data don't mix these two together you mix these two together end user doesn't know you your server doesn't know you are just blinded by the whole thing untrusted data is let's say you are taking an input you have not encoded validated decoded the input don't use that input to to now create a run like to create a run time HTML run time just don't do yes you shouldn't you you can take it from a form but then if you are putting it back to the user don't do it yes like a Facebook comment is like a great example I'll just go over some some of these random ones in some time one other thing that you can do which as as security experts people recommend you to do is that start encoding output there is this tool called jencoder which you can use which protects against most of these DOM based attacks you can do it and then it will at least encode the output so that you are safe with respect to scripts that you have there this and even more interesting security risk cross-site request for this is one of you would see this in different forms it's called session hijacking clickjacking hostile linking it's called with various forms and the bad news about CSRF is that it can happen when your session is over HDTPS and you have a valid session this is an interesting one because what happens is you log into a bank you keep that on one time you go and see some random site which says click here when you see a dancing cat we all see these random ones right go click it what happens there he's taken this session ID and then started working with it I don't know if this is readable see what happened there it's an image there where the source started now he started using your bank ID your bank transactions down is that readable it isn't but the bank is now validating the session because he thinks it's a valid session which he created in the first place so he's going to say it's fine and then continue doing it so there is no way to protect unless you write ways to stop forgery write when the person is trying to do it because most often you can't expect end users to say when you're using bank transactions don't go and click any other page none of us are going to listen to all this so it's better to protect a friend this was an interesting problem that happened last year it was a very well broadcasted CSRF that happened LinkedIn last May LinkedIn had a simple CSRF attack where anybody could delete any other user's recommendation it was a simple one from what it seemed how if you look at the code when you see today on LinkedIn you can see anybody's recommendation to anybody as long as it's public look at what happened so the source code already had the user ID there you see that user ID that I put up there it's there when you give a recommendation here is the link that you get look at what LinkedIn did now to withdraw a recommendation he did nothing much except changing the DEP to WDR that's all he did so far good now what could somebody do with it simple he went took that user ID from there and then removed recommendations of him I've got everything working sounds surprising right straight forward as it looks it looks straight forward surprising now that it was such a simple attack anybody could have seen the URLs and then done the same thing so get a user ID go to your own provide recommendation you had a link just change it to WDR change the user ID you had done this happened last May LinkedIn fixed it almost immediately as soon as the vulnerability was reported but that's how real life is you think it's secure it really need not be you don't expect a CSRF attack with respect to LinkedIn but reality is it's code and then all of us with it okay so simple solutions to CSRF there are lot of solutions to how do you avoid CSRF CSRF is one of those attacks which as end users end users are not able to understand at all because if you saw in the previous case you keep one tab you go to another tab of your browser end user has no clue of his going wrong you saw the LinkedIn again LinkedIn did something right he just changed the WDR to change give recommendation to take recommendation he didn't realize that you know people could go ahead and do something else so check for the referrer header check the headers okay some browser support origins check it the other interesting thing that you can do is you can double submit cookies what it means have a cookie and also a parameter which is a random value so that the server checks both and then you know okay it is coming from you or there is a different way of doing it which is also called synchronize a token pattern where the server generates a token sends it out to the client per session now the client has to send back that token for every form input every URL input like the client has to send it back server validates it and then knows okay this has come from the same client it has not come from a different client so you can also tag tag every form with a unique token but then remember when you tag it with a unique token you will have to change the token see lot of times you assume that if you have a secret cookie it is going to work a secret cookie will not work because a secret cookie is what will get sent again you do a multi-step kind of multi-step processing this step, this step, this step as long as your steps are being able to play somebody is able to play back your steps you are in trouble nothing is going to work because somebody can replay the same sequence just like what I showed you with LinkedIn you just need to replay the sequence in the correct order so while people think post secret cookies or something like you know you just you just keep a way to you know multi-step process is going to work pretty much does not work again CSRF so if you see the concept if you have to explain it very simply add a parameter into your request include that token get your server to validate the token back did it receive the token or not if it did not receive the token he knows he has already had it is but how many of us do it none of us right great thank you so let us go to some more tips I think these are the four broad problems that I wanted to cover because these are problems that are that can cause havoc when they are combined with each other also I will like talk about some of that interestingly after some time see URL encoding we all encode URLs without realizing URL encoding can cause us problems plugins plugins getting misused malicious code getting infected is a huge problem cross-site scripting you would read enough that that is one of the first vulnerability around CSRF is dangerous anytime it happens so these four you have to be careful as you are writing your code now let us go to content security policy I will just talk about what is content security policy and why do you do it how many of us use content security policy for our code okay content security policy basically tells tells the client the server enforces a content security policy and says okay you know it is sent along with the HTTP header the client can enforce it after that he sees the origin and says okay from this origin is all that I take if he sees an error he just throws up a post and says okay but there is something wrong now this is interesting because you can give directives for everything images for your fonts for your plugin types for your connections everything you can give you can basically stop so what happens you have your code if somebody injects some code into it just like what I explained earlier it won't work because it is referring to content outside your website it is not going to work so as long as you are able to lock down content to your own server your own origin you will be safe the best thing about content content security policy is that you have various parameters on which you can control it things like font, things like frame, things like child frame see lot of us put iframes in you can control some of this and say what can you take from which place what can't you take from which place so that you know it kind of closes door with respect to what can't be executed within your within your file now content security directive by default is open it's a it's a wide open directive you will have to close it back if I don't put font hyphen src equal to anything it means it's start it can take fonts from anywhere I'll have to tell it where to take it from now if you look at lot of these social widgets they will need you to allow content from say plus.google.com you know he can send out this content correctly back the other things to do is that I would strongly recommend not to use inline scripts don't use inline script inline script is a place for somebody to inject code but if you're using an inline script put a noun there and there you know keep a content security policy which describes the exact nouns back so that your your code is not getting hacked with something that is unknown if you're not putting a noun you can also create a hash of the script itself back of the entire script section and then put it back into the into the content security policy now content security policy also takes it takes sha 256 hash so it should be okay for you and avoid changing text into script this I've been talking about it multiple times before I was talking about lockdown content completely default source is none script source is none script source is only you style source is only you there is just no way that anybody injecting anything can ever execute something into your within your application context lockdown is the best policy really unless you can't avoid it SSL again you know use SSL but then it doesn't help unless you know you're using it along with something else okay so all this yes it doesn't happen to me it happens to everybody else except me we as engineers tend to say this oh it happens to everybody else not my code my code is the safest code which is why I started with that example of myself where it was I think almost humiliatingly embarrassing so that's now this is reality of what trends are 99% of websites according to this have at least one vulnerability which is pretty much all of us and if you look at white hat data on in 2013 he again says this 86% of websites have at least one vulnerability and the biggest of most websites have more than one vulnerability in fact the average is 55 it's not one average website has 55 in it the first top categories that get hit are retail education and then it goes down but top categories are into all these e-commerce retail kind of websites so while you can say okay it's not me it's definitely all of us 99% of most often we all know there is a problem in the code that's where like the 30% comes most often people know there is a vulnerability vulnerabilities take long to fix in my previous organization we used to take anywhere between 4 to 6 months to fix a vulnerability customers who have deployed it taken it push it out test it in fact the average today is 193 days to fix a vulnerability fix it roll it out ensure that nothing else is broken on the way most often you fix something something else breaks on the way so essentially tell us that yes all of us are in trouble sometime it's not that you know it's not my problem most of us tend to say oh it's not my problem you know I have deadlines to meet I have functionality to fix code to ship and security comes in the end this is even more interesting statistics of last year apparently most Americans fear hacking more than even terrorism it's interesting right because we think terrorism is like the most important thing oh you know not it's almost like double the thing people are worried about vulnerability hacking more than one 30,000 websites get hacked every single day every single day that's a huge number it's not 1, 2, 30,000 and Google continues blacklisting a lot of websites because they are pointing to bad malicious sites, web code sites all that he blocks apparently around 10,000 now that's a lot of data one of us will like easily fall into that data how many of you are aware of the Sony hack that happened okay so the Sony hack was interesting right the Sony hack supposedly a zero day hack it started with some email email change nothing could be more damaging than personal mails unreleased feature films contract compensation of their senior executives went out nothing could have been more damaging than that unreleased feature films senior executives talking about Barack Obama everything went out in public into sites and they had to get it to a point where almost for 10 to 15 days they went back to facts and hand written mails they never knew what started that hack for them they had to shut down everything including the routers to everything and then they started doing telephone calls and hand exchanges that's how serious the whole situation got for them it got out of hand totally and it started with a mail obviously it should be somebody who started with a CSRF and then went down quickly but somebody played it safe somebody played it quietly over 3-4 months pulled out the entire data and then he was Sony was down on its knees okay so that pretty much comes to my next part of the topic yes so all of us need to prevent protect secure code that we write there is we can say it doesn't happen to me but it happens to all of us so let's go over what can be potential security attacks you see security defects that you can see there are tons and tons of them that can happen you can write you can have bad authorization you could write bad business logic as in you just wrote bad code there is nothing to correct it and there is lot of pen testing vulnerability testing which you can do and then there are lot of static analyzes which you can use static code analyzes which you can use which could be help so I will talk in this session basically about static code analyzes which can help us during the development process rather than talk about pen testing or some kind of penetration testing tools which also would be interesting for us okay this tool is interesting retire.js this tools tagline is interesting what you require you must retire that's pretty much whatever you think what you require you will never retire but you should retire because there will be a better version there will be something else which comes after it so this tool basically this it basically looks for publicly disclosed vulnerabilities which is very important because when you are using external libraries it's good to keep track of what's happening with somebody else means what's happening with like libraries that you are using what's happening with like things around it so there is a way to configure it to like automatically monitor and then run there are command line there are various ways to run the tool itself this is a screenshot of what happens set it up correctly it will tell you it will keep checking and then tell you okay this has some vulnerability please look at it so you can actually as you start including libraries you can put in put in something like this in place so that you know in case like the library itself is now hitting vulnerability you are aware of what's happening rather than going the reverse way this js prime is an interesting lightweight tool again which basically parses for you know sources and syncs that will find common vulnerabilities the syncs if you are not using it right he has a nicely sophisticated the code flow analysis algorithm which seems to be pretty good which will identify what code path could potentially lead you into a vulnerability now he is his best usp is really that he is able to his number of false positives and false negatives are pretty low most code analysis static analysis tools like the problem is everything which doesn't seem to fit him he is going to say it's wrong which is really not the case with this which seems to be pretty good actually so you could look up at this use this again favorite one is js hint js hint is something which is a very popular static code analyzer which you can integrate into your development like your eclipses or your visual studio whatever you are the good thing about js hint is that you can configure it based on how you are coding how within your team your organization you have coding guidelines you say put braces here do this here declare variables so you have a set of configuration and you have a scope not true this doesn't work so that the tool will start catching all these correctly okay yeah I am just going there okay what is the output of this code what is console log print what is it print okay what is wrong with this code now what is wrong with this code I can't hear yes it's not declared it's not declared what is wrong with this code global scope pollution works code works code compiles works something is wrong with this code js hint finds it for you he will actually tell you that there is a problem this is where you start using it for variables look at the next example what's wrong with this code my editor is already marked it so what happened yes counter got declared again telling you clearly it's defined but if you run this code it's going to work there is nowhere that you are going to find js hint I just gave you two random example but js hint really captures lot of such coding errors which you generally it just habitually will not catch if you are just doing black box testing on it it never catch lot of black box testing will say yeah it's fine I mean lot of this code is fine code actually you can run more sophisticated code but I gave you simple examples to say see it will catch you simple errors today and that starts correcting helping you to correct okay so when do you run static analysis of course as engineers we don't have time any time obviously right every time we are running behind deadlines which don't work the best time to run static analysis is just before just at the point of integration testing that's the best time to really run it and if you see the cost gross exponentially as it moves off there is you you don't catch it there you are running into more trouble as it's getting caught later so run static analysis as you are integrating coded helps long term to fix code correctly okay quick summary implement security by design this is one of my favorite lines means what as you start grounds up build it right security cannot be an afterthought to you when you start your web server runs with least privileges least privileges required for you assume that you are going to have malicious attacks assume that input is going to be wrong assume that you are going to have vulnerabilities in your in your libraries assume all this don't don't assume that oh this doesn't happen to me no it happens to us it happens to every one of us never trust any input or output never default has to be a fail it cannot be a pass fail is what works pass is based on conditions fail is based on fail is how it starts second third secure by default most often we have this whole crib which I also hear with lot of people saying usability versus security you start increasing security usability goes down obviously but you have to get that fine balance of with respect to you where does it draw line but I would recommend secure by default is much much more important than the usability for you because security is down recently there was that olacab attack right where like somebody went ahead and then put some few million addresses out in public credibility lost there is no way to recover that and say you know olacab baby we shall just see actually what he did was simple he just didn't take another way to authenticate the same thing he tried to simplify it saying oh just just take the just take the phone number or something it works prone puts you back into attack now it's it takes you a lot of time to like build that credibility back and say oh by the way you know all your credit card information is safe with me it's never safe anymore who's going to trust Sony anymore nobody I mean whatever you say you know we are trustworthy you are no more trustworthy you are done most vulnerabilities are a combination never do people use CSRF or a CSS or one of them and then you know most attacks are a combination of attacks with a lot of social engineering in it social engineering is most of us stay logged into Facebook stay logged into LinkedIn stay logged into our bank accounts and also go and visit some random sites just while browsing all of us do this most attacks wait for some of these sequences to happen correctly and so it will be a combination of any of these these techniques to be deployed by the hacker and at this point hackers are going smarter than than like the engineers who are writing it if you see statistics today 30,000 websites every day down is huge statistics for us use tools use tools effectively tools don't cost you much time it feels like oh you know I have to set up another tool I have to do this I have to do that no long term huge benefit for you nothing can it may take you two days to set it up but once you have set it going it keeps working for you you know what's right what's wrong you keep doing it newer engineers come in fall into habit of writing correct code rather than you know saying oh you know we will finish all this and then oh you know there is a quality assurance team which needs security compliance let's just let's just go and run some tests never works security as you do right from the beginning gives you much more hold on what's happening around with your code and more importantly stay tuned to security advisories this SSL hard bleed was a great example of something that supposedly working for years went down now if you are not keeping track of what's happening around you you are done I mean you had to pack you have to do it better do it as you hear it I leave you with my favorite slide it says okay when do you fix bugs fix bugs as soon as you see it because bugs grow as you as you leave them with you it grows manifest into something really big that is going to really take you long long time to fix and security bugs are even more nasty than like normal bugs so stop it as soon as you see it rather than say oh input validation that escape character I will do it in the next round of testing oh I am just shipping a beta the next time it works I don't have a problem never works it's more a practice just like when you sleep you lock the door lock your windows and sleep you never leave the door open and say oh by the way you know my area is very safe nothing happens in my area we all are very careful we will lock the door ensure that the door is locked and then sleep reality is the same lock it as soon as you see it don't keep it open and say oh you know there are like 1 million websites who is going to come and hack me you never know for fun somebody may have somebody really wants data out of you maybe it's easy I am done guys thank you questions I take was it useful questions comments talk to me I would be rather very happy to talk to you about security anybody wants one on one just talk to me about what you are facing interesting because I have been basically doing lot of security reviews in my in my previous organization I used to head a security review board which reviewed more than 100 product architectures designs implementations including protocols file systems servers to see what could go wrong and then invariably we would see enough of things going wrong so over time you learn to start saying okay do this do this do this do this don't do these so that you know you are at least keeping the base sanity of your code intact yes sorry I can't hear you yes same thing right it's simple right Airtel if you saw that entire sequence of what happened and then what I explained today it like explains you what what happened Airtel was using some library outside that guys server got hacked code got infected in now like Airtel is now disowning responsibility is now a different thing you know Airtel says okay like I'm not responsible is a different thing but that's not fair I mean we as Airtel users like oh what the hell I mean you know how did Airtel allow a library must be one of one great engineer like no like us who just included some library in and then that code got infected location went out yes yeah that's see reality of situation is at at different points in time you are like consumers or like suppliers in this particular instance we are like consumers so we are like oh Airtel is unfair how many times your code is broken would you call it unfair no you'd say yeah you know just happened so you know it's both ways security is basically something that most often people don't pay attention that's real I mean as bad as it looks we don't pay attention and when it hits we disown saying yeah see what did Airtel do he said oh we just use a use a library from some jithub we don't know what happened there that is a stance which is okay but doesn't work because Airtel is today in like monopoly with us it all works if you are not in monopoly it will be even more interesting so don't use libraries directly don't link their libraries directly because you never know what is the other side yeah download it keep it with yourself and then you know use it if you really want to use it okay there is nothing that can 100% guarantee you there is nothing today okay that's there is see if you see Sony had till now we have I think the white hat community or the hackers community we haven't figured out what was the sequence what was the problem it hasn't been figured out people know where it started what it ended what was the sequence what and all caused it see it's always like the hackers are like two step ahead of you every day and you need to stay there keep track of what's happening that's that's the max that you can do around it if you are using others code as I said pull it down to yourself that's the safest pull it down to your repository keep it with you maintain it with you even if you don't understand that code most often library somebody else's code you don't understand it's easier to pull it down keep it with you because at least this snapshot works for you and you know it works in your environment because once you are you are pointing to something external you are done yeah it's very good yeah this this is a good one don't treat anything as a black box and say you know I'm just using it it may work it may not work tomorrow I have to understand it fully if you don't understand it there is lot of time that I use code that I never understand or you think okay you know I'll understand this later and then later never happens but I always pull in code first keep it with myself never link it somewhere else because you never know what has what's happening