 So, hi guys, I'm Nafiz. So today's talk, the whole theme of JS for this time is delivering quality products at a faster rate, right? So the quality we are going to talk about here is security. Now about me, I work as a product security engineer for Citrix. I am very much interested in browsers, their same origin policy hacking into JavaScript. I recently published few articles on how ECMAScript 5 can break existing JavaScript secure deployments and things like that. You can, I blog at this URL, so okay, what do these resemble to you? So you have three different logos, right? So how about now? So what comes to your mind when you see these, Travis and CircleCI, right? So we are talking about continuous integration. So this is a pretty good way to explain the rate at which continuous integration code is deployed, right? So if you think about the normal waterfall model, you have like even months or years before a new change happens under protection. Compared to continuous delivery, you have like few hours, every hour, like people commit code. A normal product delivers like 30 to 40 pushes, pushes code like 30 to 40 times a day. Now this is very important when we talk about security, right? So in general, development and security has no history of working well together. And add this factor of continuous delivery, right? It's the proper enemy of security. Why? Because when code deployments becomes instantaneous, your security team or your experts of security or developer who is taking care of your security doesn't have enough time to take a look at what kind of codes are being pushed, what happens when someone pushes an insecure code, which you never get to look at. So and with the constant evolution of how we do testing and how we do a lot of things in the modern workflow, think about one common example of A-B testing, right? You might have a security engineer working for your product, but there might be a small team inside your product who without any notice might go ahead and push in a new feature for A-B testing. So let's say that you have a chat application, they tried a new MeteorJS chat application, who knows what kinds of vulnerabilities that specific code has. Even though it's short-lived, it's going to have a lot of security implications if you don't do a proper security check. So what I want to come to is talk about the uniqueness of security. When you compare it with other engineering approaches, right? So when you talk about defense, so when you talk about defense, it's all about the developers trying to prevent attacks against the attackers. This defense has one specific property which everything else doesn't have, right? So or to put it another way, everything else has one property which defense doesn't have, which is you think about your testing, you think about your performance, you think about your scalability, usability, your user experience, or even you think about attack. All these things, you really know when it actually works, right? An attack, you write an attack and it exploits something, you really know whether it works or not. But with defense, you really don't have an idea until unless it breaks. So you can never be sure about putting something online and say I'm all secure. Another interesting aspect is in spite of this constant pushes and constant evolution, the speed, you have your A, B usability tests, your air catches, like you have things like error reception, Rakesh Bhai is here if he's, yeah. So errorception, airbreak.io, you spend a lot of resources on that to make sure you don't break anything in that area, right? And even benchmarking, you write them. You have specific people writing test cases and benchmarking stuff to make sure you're up to date with everything. But when you think about security, how much effort have you really given to it, right? To talk more about it, I would like to talk about the tradition of how security is generally done and how we haven't evolved with the continuous integration thing in place. So normally what you do is you have security engineers, you go and do design reviews before something goes out. You probably do a penetration testing with an external guy every two months, things like that. But with the constant code push, this model is not going to work. Your security, you're not going to be sure about how safe you are on the web. And another interesting aspect is today attacks are becoming very complicated. And there are many tools which easily aid someone in completely doing an end-to-end attack, right? And as you might have a website online, you think you might not get hacked. But your website is already being pentested, but you're just not getting the reports. So to add to this problem, when people think about development, they start with a very simple access control policy, right? Let everyone can access everything and go ahead and stop fixing those holes one by one. No, there is no secure by design right from the beginning, right? You just go ahead and think, when you become big, you change your design in a way or try to fit in security somehow. Or maybe you're talking about front-end. You have never designed your front-end. You have never even thought about any kinds of cross-domain attacks. And you say cross-domain attacks, things like cross-site scripting, cross-site request for framing attacks, lots of bunches of stuff. So there is a lot of thought that you can give into even designing your front-end, which can scale well with security, right? So the point I really want to make here is you just need to consider, and it should be considered as a first-class requirement, right? Just like how your usability codes are and your functional tests are. Now, as I said, again, it's very interesting. You show a code to someone, you can tell whether your code is performant. You can actually tell whether the code looks good, things like that. It's very hard to say again that your code is completely secure. It's pretty unique, and we need to tighten the gaps as much as we can. So since it's a crisp stock, like I have only like 15 minutes, I'll just talk about one way of doing things, how to tighten up a certain attack vector, and how we can build on top of that, right? So today with continuous deployment, we can take advantage of the code commits. So you know whenever there is a code commit which happens, you have the infrastructure already in place to actually get the divs of what's getting added. So what if you could do analysis on this code commits with respect to security, like insecure patterns and behaviors, which is very specific to your frameworks and the app that you're using, which only you know. So just to give a how to of how to come up to this point, let's try doing that to a repository on GitHub, right? So you can do it in three simple steps. Use any source code control is going to have something known as hooks, right? Pre-commit hooks and post-receive hooks. So you basically take post-receive hooks in GitHub provides you a web hook which alerts you on a post on a commit which has been done. And you basically get all the commits, you see the div, and shut it across all your security tests. So now when you think about it, what are the kind of tests that you can do? Because these are very specific. This is not like you giving an IP address, hey, scanner, go ahead and scan this. It's very specific to your app. And it's very specific because these are just certain pieces of code. So traditionally you do static and dynamic analysis. When you think about static analysis, ways of introducing cross-excripting, right? You introduce a way of, some developer introduces a framework which is vulnerable, someone tries to do an unsafe function of doing things or someone can introduce something which can do remote code execution. Someone takes a user input and does an eval on your server side. Think about it in Node.js, right? Or even dynamic analysis. Today, one of the problems with security scanning is the coverage that it has to make, right? You have a lot of different scanners, web app scanners doing scanning, but the problem is pitering. You really don't have an idea about the real web application and its whole bunch of endpoints and what parameters would actually yield results, right? If you can actually have an idea, because you own the app, you have a lot of things. You have a lot of things which the attackers don't know, right? One of the things is your routes. Whenever a new route gets added, you could actually scan them, which makes more sense because you just concentrate on one URL endpoint and do all kinds of tests. And it's just done. Until there is some new change, you don't have to do it. So you don't have to repeat the test again and again. And how about state-changing requests being added? Think of someone introduces CSR vulnerability, cross-site request, forgery. And you have a framework in place which takes care of it. But someone introduces a get request and you can detect all these kinds of things using dynamic analysis. But I'm not going to go more deep into that. But this is a bare-bone framework, I would say. You can use to actually build something like this. It specifically concentrates on security tests. You can write security tests by taking as input the diffs and the report function, right? So, all right. Let's talk about solving this one prevalent problem, cross-site scripting. Who here doesn't... I haven't heard about cross-site scripting. Ha ha ha. Security guy. All right. So, yeah, it's basically... You have a vulnerability in your web app wherein you allow someone else to inject JavaScript code in your web application. So, this is how I put it. The implications of cross-site scripting is if you allow someone else to control your JavaScript code, it's not your web app anymore, right? They could do all sort of stuff that you want. And with the way that we're moving forward, everything is on the client side. It's going to be pretty hard. Now, solving this has been a problem. This has been haunting the whole web for the past almost two decades, right? So, with cross-site scripting, we talk about contexts. You have contexts like HTML context where if someone can inject a script directly in HTML or an attribute context or even a JavaScript context like this. So, just imagine this context, right? You have a script which tries to assign a variable A, which is taken from a user input, but it's inside double quotes, all right? And you have a lot of finished. And your expectation is that nobody should get out of this context, right? Are you guys with me? So, what should you do to prevent this specific attack here? Like someone else, from how would you securely make sure that you filter the user input here? Probably encode or filter out or strip out the double quotes that work. So, as long as someone cannot have double quotes, they cannot come out of it, right? And you don't have a way to do JavaScript injection, right? So, make sense, guys? Yeah, so, think about an input like this. So, we all know JavaScript, right? So, we are assigning a variable A equal to some stuff inside the double quotes, okay? It's not outside the double quotes set. What do you think will happen? What would be the output of this? Two, I mean, of course, it has to be the non-obvious one because it's JavaScript, right? So, let's try that. So, his JS filter, hey, it seems to be proper. But, yeah, so, as you can see, I'm trying to do the same thing here. This would technically alert an box of one. How many of you agree with that? Okay, how many of you agree? It's a lot of two, great. So, you're right, why? But it's inside the double quotes, right? If you say A, it should give you the value of A. Exactly. You're right. So, how many of you know about this fact before? The hashyml, it's a very well-known fact, but if you look at the tokenization of hashyml-5 specs, it basically says that your parser has preference over your JS, your hashyml parser has preference over your JS parser, right? And we cannot blame the browsers here because they have to do it this way and add to it things like in Firefox, you have things like speculative parsing in Chrome, you have things like preload scanning, performance guys. You cannot talk anything over there, right? So, this is one problem, right? Now, there are various different other problems with respect to cross-excripting. The browsers, the different browsers behave differently. You can do CSS injection in IE brace browsers, things like that. But let's, the way we try to approach with this problem is, try to reduce the entry point to one. There is, make sure that there is only one way that you could do cross-excripting, right? So, you, since I don't have much time, I'll just go through it fast. So, make sure that you use client-side templating a lot. For some people, they use client-side templating a lot because everything else is irritating, but I would say client-side templating makes a lot of sense if you need to completely eradicate cross-excripting. Make sure the only way someone can inject CSS into your web app is using something like this. So, in most of the templating, you have something like less than a percentage minus or something like this, which can inject code without, which doesn't encode your output, in which case you can have cross-excripting, right? So, this works until someone who properly does, starts committing code to production. I mean, who, but if you have someone new or who doesn't understand your code, this can become problematic, this can break, right? So, we need to look out for things like this. You reduce the entry point to one and make sure that nobody else can do stuff other than this. So, in the git watchdog, you can basically write a simple function like this. You export scan function, which takes different report. The report takes care of how do you want to report. If someone pushes a code which has this insecure template usage, you're basically going to be alerted, right? So, you stop the code commit right there. So, I planned a lot of things about how to prevent cross-excripting, if necessary, cross-exquest forgery and various other things, but you don't have much time. But with Express, you could actually, I found that you could use this pretty interesting thing called app.router.stack, right? So, in Express 4.0 and above, it basically gives you the current routes which are registered. And for every commit, if you could do a simple integration test which runs your Node.js program and takes the app reference and runs this, you get all the endpoints. And you can compare it to your old endpoints and you basically know what are the new endpoints which are being added. And you can do specific tests based upon that. I think with that, my time is over. Let's discuss more. Please tweet me at scripting.squarefetch if you'd like to know more. Any questions? Hello. I would like to know any vulnerability checking tool which can check XSS Tome injection particularly? So, most of the XSS tools out there right now just do black box testing. They just simply send payloads. But I would suggest there is no XSS tool which does checking specifically to your content. So, it's a good idea to basically integrate that as part of your functional testing or integration, whatever testing you have. That's the whole takeaway from this. Don't believe in the XSS can as they are made generically. They are made like scan once in once a while. But make sure that you can integrate testing as a first-class requirement and security testing as first-class requirement and check for all these kind of things. And yep. Thank you. Probably the last question we have. Yeah, can I use webhooks for AngularJS code scanning? Webhooks for AngularJS code scanning. So, AngularJS, you're talking about the client side and yeah, you basically if someone pushes a new AngularJS, you know, it creates a new controller with all these templates and everything and does something insecure. Yes, of course, it's possible. Okay, it's as long as it's going to your source code repository, everything can be scanned. Yeah. Thank you guys. Thanks for your time.