 application security. Note that it's not demystifying web applications as security, it's not demystifying JavaScript security, it's application security in general. So today's agenda, we'll cover XSS, cross-site scripting, CSRF, cross-site request forgery, JSON attacks, click jacking, click baiting, PTSD, RSS, one of the reasons why it's very hard to start with security and especially web security is the fact that there are so many security exploits. We saw this list it's a very small portion of the OS top 10, there's a bunch of more, there are a bunch of other terms there that weren't even anything related to security and keeping on top of these things is why it's so hard to deal with security. So we won't do that. Instead let's change the topic and really talk about security in general and how to think about security in a different manner. So we won't be talking about a laundry list of X, Y, Z, this is how you secure this particular attack, this is how you worry about XSRF, CSRF but instead let's talk about how security has evolved and really try to understand where the real threats are and the aim of this talk is to really give you a thought framework on how you can think about security in your application that will allow you to at least be aware of the threats and then decide on a case-by-case basis of which ones you want to tackle and how do you want to tackle them. So really if anything I would call this talk how to think about security right and we'll focus on what we call attack vectors, what are the various ways that you could make your application insecure. Warning or caveat, this will have stuff not necessarily related to JavaScript, it's more of a holistic approach to security but that's really what is needed when you start working with security. So very quickly about me worked at quite a few different places started my career at Google, worked at Amazon where I was also a security reviewer reviewing different applications and also headed the engineering at hopscotch, written a few books again and again and again on Angular, first version, second version so on and so forth and currently I run two different startups one focusing on consulting basically rent a CTO for startups and things like that and run my own product startup providing a B2B solution for FMCG companies. Now in all of this security has been something that I have been a part of or a lead for at various organizations and that's kind of where this thought process comes in from. So Amazon I was reviewing applications that were going out for production and this thought framework really helps us ensure we get a good coverage across our application. So before we go deeper into that right life in this Stone Age or life before internet security was easy you had to physically lock down things provide access cards and that was about it no internet nothing life was easy then came web 1.0 and this was the era where I kind of grew up where suddenly things were available on the internet people sitting anywhere could access anything thankfully this was still the day and age of your server rendered HTML browsers were dumb useless and annoying but you still had the first set of attack vectors you had things like XSS and CSRF which were still dealing with today and that was it browsers were dumb there weren't that many attack vectors you did the bare minimum security was okay and data wasn't fundamentally online not enough data was so it is still okay by the time we started figuring these out web 2.0 happened browsers became better JavaScript engines became better and like this comic puts instead of pearl or regex I now have JavaScript and that's just increase the number of problems I have I love JavaScript but it is a pain sometimes right what happened basically we started saying everything that we could do on the server there everything that we used to do on the server let's put it on the client it's faster he doesn't have to make a server call I can do validation there I can start doing business logic there I can start doing access control there right and that's the path towards hell you start doing everything that was the domain of the server on the client fair enough maybe it's still faster a better experience for the user but when we start doing these things solely on the client that's where the problem really starts of course it wasn't enough that we just had this JavaScript explosion of things that you could do on the client you also had this explosion of frameworks I remember JS for a few years back where everyone I talked to was either an angular developer a react developer a backbone developer and there were really very few people who were JavaScript developers or front-end developers back-end developers are not around anymore God knows what happened to them right and you had people who spend time using getting used to frameworks and over time suddenly this responsibility of security who was responsible for security kind of disappeared front-end developers were focused on getting their features their UI things shipped back-end developers were focused on giving the API's and no one really was talking or thinking about security of course unless and until something blew up unless and until something was so critical that it was boiled in from day one but otherwise security is the last consideration we have if it is a consideration at all right so let's take a step back let's take a very standard client server architecture as basic as it can be you have clients web Android iOS making server calls multiple servers running you have a database very very simplistic right where are all the threats where do you consider yourself to be at threat in a setup like this if you talk to a security developer you say every single line every single box everything is a threat which is true anything could potentially could be under attack but I would put to you that the real threat is when we start copy pasting code really stop understanding what's happening really start focusing on getting features out rather than understanding how it works rather than understanding the true setup underneath right and that's where we start going wrong so going back to possible security exploits right it's very easy to say okay let's look at the OWAPS top 10 let's look at this list of security holes that were exploited in the last one year but I would put to you that this is a non scalable model it's very hard to keep on top of every single security exploit especially considering the fact that there's a new security exploit every other day so how do you deal with this how do you build an application that is secure while still allowing yourself to be set up for success while you do the bare minimum threat assessment and it all starts with trust if there is one thing you can take away from this talk is that you need to keep thinking about trust all the time when you're building your application when you're updating your application when you're adding a new feature if you can think about trust you'll go a long way to securing your application trust is a tricky thing so let's do a quick exercise how many here show of hands would trust a guy that looks like this no one really trust shady character okay good for you guys but what about Batman how many here would trust Batman all right quite a few comic book folks Batman is trustworthy you can always trust Batman right but what if Batman was really Superman and it's happened in the comics right even the most trustworthy character even the most trustworthy user in your system may not be trustworthy right if there is one thing you can do as a security developer or as a JS developer who thinks about security be like Madhai Moody constant vigilance don't trust anyone don't trust anything because if you don't trust anything it's hard to go wrong it's very hard to be betrayed lose data have a security exploit how does that work in real life right it's easy to go about being paranoid I'm pretty sure I could get a fake eye and attach it and walk around like Madhai Moody but does that really work so instead I say don't look at security exploits look at attack vectors trust of course being the most critical one and this goes across all the attack vectors you'll see that in some way or the other most of the attack vectors come back to trust but then with that context with that hat of trust or a tin foil if you will think about transmission when data is being transmitted is it secured when and where data is being stored is that secure are you hashing signing cryptographically hashing data correctly and we'll talk about each one of these as we go along what about the credentials and notice here we're not in the domain of JavaScript as such some of it is part of JavaScript some of it is outside but to be a complete developer you need to think about all these things libraries it's in this day and age there's a library getting created every six seconds probably not a true fact but close enough and audit log so we'll talk about each one of these but again the fundamental rule of security don't trust especially your user especially the guy you're building your application for don't trust him because that's where most security exploits start and when he gives you data trust that even less question every single data element where is it coming from who's the originator is it somebody from my company some external user how is that transmitted has it been transmitted securely where all has it been stored and how has it been stored when in doubt don't trust it and at the end of the day while you can do all these things on the client and we'll talk about some of these on the server it is as critical that the server trusts the client even less than you do so role-based authorization user-based authorization access control is a must again not trusting anything that the client sends the flip side of that is convenience and who here hasn't actually shipped something for the sake of getting a timeline agile programming we all know it somewhere agile programming has become let's ship things every quickly every week every day God knows what happens to security it rarely happens that that bug that you said that nobody will ever use that code pad that no one will ever touch that fix that you added for just one week till you ship the next thing it rarely disappears and it'll rarely be the case that it'll save mankind so don't rely on that either so let's talk about trust right and there are a lot of talks today and tomorrow which cover different aspects of this talk specifically going into security authentication identity my role here is to be an MBA talk about everything without actually going into details of anything right so let's talk about trust the source of the data right where is it coming from has it been mutated or is it pristine has somebody changed it where all has it been stored and most importantly even if you don't know any of that right what is the impact of trusting it what could happen because of trusting that if you think about these things you'll end up with what we call trust boundaries supremely trustworthy data I've never seen anything that is supremely trustworthy somewhat trustworthy data and completely untrustworthy user input completely untrustworthy so you'll do everything in your application to secure it make sure that it can't go out of its zone to access data identity in the web apps relying on the client on the user to tell you who is is like accepting this ID card who here would accept this ID card just out of curiosity right login is fundamentally the only time we ever asked the user who is if you're relying on the user or the client or the browser to tell you who they are by themselves you're doing it from post log in you're relying on the servers own hash something that the server only knows to reliably identify the user and even after that right it's very easy to forget when the user says perform this action check out add this item to card place an order or view the order details you need to make sure that one the user is who he says he is to the user has access to that resource that he wants to act on and three he can actually do the action on that resource that he's wanting to act on and if any one of these three are missing God save you again don't believe the client when he says I want to check out this order that's where most security holds start so don't trust again going back to that same philosophy do not trust the user then we come to transmission secure transmission in web apps I've seen quite a few web apps while I'm auditing while I'm browsing which do this crazy thing of saying I'm gonna make my application so secure that I'm gonna encrypt the JSON payload do some cryptographic hashing send it to the server the server will then decrypt it and it's so secure really what you're doing is just reinventing HTTPS and probably in a really really bad way just use HTTPS don't reinvent the wheel or use secure web sockets if you're using web sockets but use accepted standards rather than trying to reinvent the wheel for the sake of security secure not just the transmission but also the cookies also who can access that right so when you're talking about data being transmitted make sure that only the client or the server are the two parts that can access that information and no one in between every non-secure transmission is a leak waiting to happen you don't know where all your hops are from your router to your ISP to finally your server any one of them being compromised is your data being compromised so don't do it if you're not on HTTPS Rome would anyway cry so that's a mood point but use HTTPS then it comes to storage and storage you need to think about of course how what data is stored where is it stored is it stored on my database is it stored on my client and what parts of data are stored your standard thing you store it in the database make a call fetch it send it down to the client well what about on the client do you cash it you store it in local storage if so what data do you store what is the impact of someone else accessing that computer you need to be able to think about all these things when you start thinking about storing the data and it's not just your database if it's stored forever it's it stored for a particular time and here also just like trust boundaries you have different criticality levels of data highly critical data payment information user information versus maybe some cash on product listing and the like which might not be as critical and the way you deal with each kind of data is very different so you need to be able to think about these things you assume that this data is going to leak if it's stored there and then think about what would happen and if you're okay with that it's probably not critical data and if you're not okay with that you need to rethink how secure you're making that data of course in the end who has access to that data whether it's your database whether it's in your cash whether it's on the local machine or the phone who has access to how can they access it can somebody else some other browser some other client some other user some other website access the same data and what would be the implications of that so data is not as simple as get the data render it cash it and move on think about what you're caching where you're caching how long you're caching it for as well cryptography is the last thing as front-end developers we usually think about but if you're using it if you're abusing it don't reinvent the wheel just like HTTPS use accepted tested validated libraries use open SSL metal things like that rather saying I have figured out how to cryptographically hash I now I'm going to build my own RSA algorithm for doing public signing don't do it use secure tested libraries credentials and access if you're AWS credentials database credentials if you have access to them or if your code needs access to them think about where they're stored are they checked in are they in your code are they coming from configuration and who has access to the philosophy of credentials is that they're never checked in never available searchable it's need to know basis and nobody needs to know ever except for that one guy maybe so credentials rotate them keep them secure don't check them into your code base please don't check it into get libraries who here keeps their libraries that they're using up to date keeps updating their versions how often how does it monthly who does it every six weeks anybody do it once a year at least right two out of 700 not too bad maybe it's hard it's annoying and especially so if you keep waiting till you have to do it node if you're using node has come out with this nice way to check which libraries need to be updated because of security and PM audit but make it hygiene update your libraries especially if they're a minor version upgrade keep doing it don't wait for too long and keep an eye out for security disclosures which no one ever will so just keep updating assume that the libraries that you're using are updated with the latest and greatest smaller regular updates are always easier finally audit logs assuming you've done all of this which you won't assuming you've made your application super secure which you won't be able to you will need to be able to always later deep dive and see what happened post facto and that's where audit logs come in and you need to be able to know exactly what happened in your application who did what and by the time you need it if you don't have it it's too late so think about logging audit logging from day one and make sure it's comprehensive make sure that every action is taken care of whether it's client side calls whether it's server side actions whether it's database mutations so on and so forth make sure all of this you know what is happening with your system who is doing what and make sure it's trustworthy the worst kind of audit logs is someone who can go in and change it as well if a hacker gets access to your system they shouldn't be able to mutate your logs so think about immutable audit logs whenever you can so taking a step back right we covered a whole bunch of different attack vectors not all of them are applicable to each and every application but fundamentally think about these things if the only thing you keep asking after this talk is do I trust X do I trust why that's good enough right do I trust the data from the server from the client and remember you can't trust data just because it's coming from your database how did it get into the database who was the originator of that information if I'm Amazon Amazon marketplace data that were created by Amazon employees would be more trustworthy and third-party seller listings so the source of that data becomes important as well do I need the entire data the worst thing you can do is just say here's my database here's my entire data send it down to the client think about do you really need to send all parts of this information down to the client can that data be cached can that data be used should it be persisted and then is it secure in all aspects while transmission storing it and are you using the latest and greatest libraries if you can do all of that you'll be one step further in the fight against security exploits thank you any questions at this point so I'm interested in knowing what are the laws by government agencies like to nail down the people who might have attempted to break such securities would you just repeat that one more time I'm interested in doing the laws the audit logs yeah the security laws against the people like the attackers or hello yeah so security logs itself right so think of it there are no great out-of-the-box solutions for audit logs itself like at restock for our own product we created our own system which tracks all mutations at the database level we have a separate system to log all server calls to see who did what at what point and then we have a system running on top of that which is basically looking for deviations from the norm so we have a norm line saying these are the kinds of actions expected and any deviations from that gets flagged so we started with very basic logging manually checking and then we built a automated system on top of that to flag out deviations very very custom inbuilt I haven't found a great out-of-the-box solution for it anything else hello I'm Pradeep I have a question about most of the JavaScript code resides in the browser right so could you share some details about the browser the way it helps or something best practices we can use inside the browser to make it secure so the browser already does a lot to make your application secure so cross domain requests are blocked by default unless you enable course so you're kind of guaranteed that request to your domain are generally coming from your own domain other than that you still have the whole glut of XSS CSR of attacks that you will need to protect that you will need to do some frameworks if you use them automatically do that for you but what it really comes down to is knowing thinking about so XSS itself right you trust the data if you do trust the data XSS is not an issue if you don't you need to make sure you're using a framework to protect against that cross-site request for three again different domains should not be able to make the calls should not be able to embed things like that so browser does a lot it's doing a lot but it's upon us to make sure we know what other things can go right it will not protect you with identity or access control that's completely up to the developer to take care of in their own application so you need to be able to define that boundary of what is being taken care of by the browser and what in my application I need to take care of over and about anything else hello can you suggest your open source tool just to a one-stop solution kind of thing to test everything out I mean I know this is kind of quite like not I've not found a great free tool for that but let's discuss after this yeah sure I'm just trying to understand like as a developer like maybe things that identified are at a later stages by the queue or something especially on the security perspective so I'm just trying to understand if there is any tool which can cover maybe which is also updated on the security box that happens there are there are a few open source tools I can't remember the name for them but starting at the OS top 10 itself starting from there will give you a list of each one of them comes with a tool for testing it there are a few paid libraries and frameworks which give you complete testability and all that but usually paid I think we were primarily focusing on the web application so when we come to mobile applications say it is a different ballgame right so many things reside inside the mobile itself so what are the main things that you would look for in case of security in mobile applications it doesn't fundamentally change right so you still have just like when I this is an application security so you're still looking at what data can I store on the client whether the client is a browser or a mobile app doesn't change much so if I don't want to necessarily store my users credit card information on my mobile even if it is encrypted because I might be encrypting it down on the client itself access control the problem still don't change so a lot of these attack vectors still remain whether it's the browser or the Android or an iOS device yes each device has its own special technicalities of what can be accessed or not but going by the rule of thumb don't trust keep it minimal you won't so you said don't read when the wheel when it comes to cryptography when it comes to using so what are what is your thoughts about using that in conjunction with some of your own custom logic so the question is what are you trying to do with the custom logic right what additional benefit does it offer over the existing cryptographic libraries and the security that you get of transmitting it over HTTPS or WSS or something like that I'm specifically talking about the cryptography let's say you're using hash or something right or not not hash in general let's say using RSA or something but you know that RSA could have its own set of exploits that can be done on it so I think if you use some custom logic with that you might eliminate that possibility so the question is would you as one developer or 10 developers be able to do more than a framework that is being contributed by so many developers over so much time if it gives you peace of mind go for it when you say trust is the main point so trust is the main thing where we have to check and check the boundaries from the customer angle what is the specific domain related or product related thing we should include in terms of security and if you are including it at what point is it during the stage of requirement or how are you checking those so could you just repeat the first part I got most of the last part yeah first point is you said trust is the main point right so we have a lot of technical things where we can take it off but main thing is from a customer angle it may be specific domain related functionality related there can be some security that can be implemented so that kind of instances are something you have seen like that so again trust right when I say don't trust the client it's not that don't trust and don't take his input or don't deal with him at all it's take his input but do whatever you can in your application to validate and secure that data right so when you take input from the user and have to display product listings in HTML make sure you're secured against excesses attacks it's also how that data will be stored how will it be used when it comes to trust so it's scary that if you take data and directly display it later in some other part without securing it that's untrustworthy but for the most part taking the data from the user if you're not rendering it as HTML and things like that must be fine so trust boundaries really comes down to saying I can take data but it has to be treated in a certain way when someone uses it and anyone who is a user of that data later should be aware of where that data came from and how it can be used so that's really where the trust boundaries come in