 My talk is called Safety Not Guaranteed. It's based on the title of a movie that I really like. Movie is about time travel. And I highly recommend that you go watch it, even if you don't like the talk. I'm only going to talk about what's on the client. I'm not discussing anything on the server side at all, which makes sense. This is a JavaScript conference, but there are a lot of Node.js fans. The whole point I'm making, I'm making an assertion that safety is not guaranteed. Guaranteed when? I'll come to that. And it's important that you should think about it. I keep saying that because that's what I do. Okay, so I'll explain how I reached here, maybe in the first five minutes, and then discuss more technical things. So there are a bunch of these model view, star or model view, whatever, frameworks. They're there. The first time I heard these things, it just seemed very, very complicated. And we are going to talk about Ember just once, angular, and maybe underscore. I'll show you one example of view. I don't know if you've used it. This is just based on my references. What they do is basically they provide templating, data binding, routing, and I don't know, something else. But most of these frameworks and libraries, and I'm not making the distinction that libraries don't do enough, frameworks do enough, because I think that part you already understand, and you already have the idea of which is the framework or the library that you want to use, which makes sense for you. I'm the outsider here. I'm not a JavaScript programmer. So when I started looking at MB star, JS MB star frameworks, this is exactly what I felt like. I felt like this person who's outside trying to look in and it's already too late. There were just too many options. There's just too many things. And if you notice the image, I'm outside the glass wall. And there were just so many people talking about so many different things. And I just felt I've kind of missed the bus. Where do I start? So I actually started reading this person. I don't remember the name. I think it's called Funny Ant or Craig. And I started reading his blog about which is the best JavaScript framework and which framework you should choose. Just to get an idea what are they talking about? What are the different attributes? What are the ways people evaluate and benchmark frameworks? And this is what I felt like. I talk about application security everywhere, wherever I get a chance. I do this as a part of my living. And the whole thing was so complex for me to wrap my head around that I just felt like I don't understand these things. Because in the end, all they do is make web requests in most times. So eventually that's what I like to do, see how getting posts work and what you can do on the server side. And this was new to me. I work closely with the security community called Null. And there are also not many people talking about these things. We had Nafiz talk about NodeJ security yesterday. Continuous security with that. So he's one person I regularly talk to and understand what's happening. And this is how I started to deal with it. First of all, I reached a point where I realized I know some things. I thought everyone else knew a lot more, which is quite possible. But there were some parts that I am aware of and there's an overlap. So let's see if I can come here, make an assertion about the JavaScript frameworks and libraries that you've been talking about in the past two days. And can we reach a conclusion? At the very least, can you ask these questions at the end of the talk? So how do I start learning about all these JavaScript, MVC, MVStar frameworks? Google. So that's where you start. And I just Google for JavaScript MVC security. What does it do? What does it take to understand security in this sense where data may not go back to the server? If it's not going back to the server, what can I trap? What can I see? What kind of interaction is happening? And data just looks like some kind of JSON or some other serialized format or something for me. So I ended up with these things. The first result being Mustache security, which is a Wiki dedicated to JavaScript MVC security pitfalls. So if anyone has not heard of this, and if this is going to be your single take away from this 15-minute presentation, please go look at this. You may not like some of the things they say about your frameworks, but we might as well address them now, then get hurt later. So one of the interesting things they have done, Mustache security people, there's mostly one person Mario behind it, but maybe there are contributors, they have created some six qualifiers. These qualifiers help us estimate a framework's security level. We don't have time to talk about all six. But the interesting ones are our template expressions executed without using eval or function, because some of the modern browsers, the newer versions, will complain when that happens, especially if something called CSP is enabled. The one that I'm going to mention now or go in a little more detail is Sec5F. Does the framework allow or encourage safe CSP rules to be used? So if you've not heard of CSP, and this was the resulting matrix they created, this matrix is basically around seven to eight months old. Okay, this is not the latest data. So the versions may not match, but they just looked at a bunch of these frameworks. Is there any framework that you use which is not in this list? Anyone? So Backbone uses underscore basically for a lot of stuff, right? That's how they explain it, or that's how I understand. Maybe it's time to update the wiki. But it's a very simple matrix to look at. Even if the data is not updated, these are some of the security concerns that you might want to think about. So SecF talks about does the framework allow or encourage safe CSP rules to be used? And obviously, yes is a pass. What is CSP? Is everyone aware of CSP? Okay, I'm just going to go ahead and talk about it. I have the slides. So what is CSP, content security, policy? It's a policy, okay? The application, the people who build the application think about this policy, and it is for the content on a web page. That's where the policy gets applied. And what is it for? We need to look at what is SOP and XSS, okay? Same origin policy. I think a lot of you will be aware of this. Because you didn't like SOP, you wanted cores, right? Okay, that was a joke. All web clients need to follow SOP unless there's some additional work done from the server and the client so that they can enable cross-domain, right? SOP basically means that if I have my website, mybank.com, if the code loads from there, the data on the browser of mybank.com is the only thing that's available to me, okay? That's what SOP says. There is an attack in web application called cross-site scripting, right? Injecting scripts across sites, which bypasses SOP, which is why it's a little problematic. It is technical nightmare. All data that loads from the server, including the attack code, is trusted by the web clients, right? Because the attack happens before the client gets that. And if it is already injected, the web browser or the client is going to trust it because there is no way for the client to figure out that, oh, this particular script SRC was not meant by the original developers. This was injected by an attacker, right? So cross-site scripting allows for third-party code to be executed and has many bad technical consequences, starting with stealing of data, session IDs and all that. So CSP basically, it's a policy to allow white-listing of trusted content sources, right? What does that simply mean? First of all, it's a header. How you implement it, the server needs to send that header. Earlier, there were multiple implementations. Firefox had a different one, a different header. Chrome had a different one. Everyone except IE supports this now, okay? I don't really know why they don't, but maybe they have a different idea about web security. The content security policy header, where you say script source can be self and can be a trusted site. You can have multiple of these things. You can have multiple different content types, right? Images, fonts, other sources, things like that. So if the framework that you use for whatever reason is not supporting it, supporting CSP, it's a big deal. Why is it a big deal? Let's search for security issues with some of these frameworks on Jithub, okay? So it's pretty straightforward. And this was the next part of my journey. When Mustache Security says these are the six qualifiers and these frameworks have problems, I wanted to go see, have the frameworks address this. What are the frameworks saying about it? Otherwise it's just someone, you know, one person's view of the world. This is for underscore. There are multiple people who have faced this, multiple developers, because of the browser supporting CSP, right? So they have raised issues and marked them as tag them as security where they say the new function needs to be replaced in order to let underscore work with CSP, be more CSP friendly and couldn't use Mozilla mobile platform, right? The ones which are marked in X actually refer to problems. The browsers disallowed some code to execute because of this CSP being enforced. So it's almost like that the developer is not a fight against browsers. That's been true forever, right? But now there are security elements. Now it's not only about that different types of JavaScripts will do different types of things on browsers, right? In underscore, this problem is actually solved, okay? The good news is it's solved in underscore. What the developers say you need to compile and create your template on the server side and then send it, which is great. But if you really look at the documentation, if you really look at the awareness, unless someone has encountered this or considered this to be a problem, they will not know about it, right? And that's the point I'm making, that safety is not guaranteed when you use these frameworks. The other issues are cross-site scripting issues in templates. Oh, okay. I just have two minutes. Mustache security, Wiki, gives you these code samples. You just have to copy the code, paste in your browser, any modern browser, and see if it executes, okay? For some of the versions, like Angular, this is not going to work. The older version will work. So you just need to go figure out which is your framework, go to this Wiki, right? And copy the code, create an HTML file, see if it executes, right? So you can get some kind of a sense that is your framework really thinking about security, and you could do this for yourself and, you know, other codes. Frameworks are making changes. That's what's happening because now someone's talking about it, there's more awareness. Maybe they were already aware it was not a priority, which usually happens. Security, usability, performance, business reasons, all of that comes in place. Some, you know, even responding to ensure that security tests are reproducible. I'll show you an example of this after this next slide. Ember has set up a dedicated mailing list for security. So if you go to that mailing list, they will only post to it if they feel there's a security issue they need to reveal about. There are five issues, all of them closed, right? Which means that's a good mature way to look at it. And in my personal discovery so far, Angular and Ember seem the ones who are really doing a good job and thinking about it, okay? It's quite possible other frameworks are doing that as well. I am not aware of it. Maybe you can help me out. This is Angular's response tool to the security Wiki. This is a Google Doc. Anyone can go and have a look. It's a really good reference for, you know, understanding what these security issues are. Sometimes security people also tend to go overboard, right? They want security first, which means like plugging off your computer and not being on the internet. But it's good discussion. It's an open document. So people have added their comments as well, right? You can do that in Google Docs. And I recommend that you go through this. And they have basically fixed some of these things, which they think are a problem. For everything else, they clearly claim that CSP takes care of it, right? So if you're using Angular and if your app, you know, has some data and if you're not using CSP, it's time that you think about it, okay? This was my assertion. And this is about the movie. It's got a really high IMDB rating of 7.1. I think you should go check it out. It's about time travel. And these are some of the sources that you can follow. I'll add the Google Doc link as well and I'll post it on Funnel so you can go from there. And anyone else with security issues that you have encountered and have solved? I'm done. 15 minutes. Thank you.