Prevent XSS Attacks Quiz

[00:00:00]
>> Mike North: So, companies are even starting to treat cross set scripting as a future, which is pretty terrible. And Xfinity, you're setting a bad example. This is a user visiting Reddit without HTCBS and Xfinity has injected a script to do the service to their user of saying, you're approaching your limit for your quota on your home internet connection.

[00:00:21]
They should not be, this scares me when I see this. Xfinity should not belong on Reddit. It shouldn't be able to inject its script here and Reddit should be upset about it, and they are. So if you see this kind of thing, take five minutes, write an email, saying like, Jesus, stay out of my, don't eavesdrop.

[00:00:40]
Don't tamper with my traffic. This is a good reason to support net neutrality, an ISP should not be doing this. And they do this today as a regular practice.
>> Mike North: So cross-site scripting questions you should ask yourself. One is, how confident are you in the, your libraries. Are they bulletproof?

[00:01:04]
Are all of the cross-site scripting vulnerabilities patched? One thing that you should look for in libraries that you use, particularly a view library is, you wanna see that there is a procedure for resolving security issues. They should have an email address that sends stuff to a subset of their core team or whoever it is, where you can support specific security issues.

[00:01:28]
You wanna see that they basically have planned the procedure, if something is found, to address it promptly and to make sure that it doesn't just get reported as a GitHub issue. That is not the appropriate way to report this kind of thing. You open that ticket. Anyone who's watching knows that there's an issue, there's a problem that can be exploited.

[00:01:46]
So you wanna see that there's a procedure in place. If you're using a library that doesn't have this procedure in place, one they just, they might don't have gotten around to it yet like don't use the stick, use the carrot. Encourage them to get that in place but it does mean that they've either never found an issue like this or they are not thinking about this kind of thing.

[00:02:12]
So one step better than that would be some sort of recorded set of cross-site scripting vulnerabilities that they know are not possible. Just like an insurance policy, you want to see that they cover this, they cover this, they cover this, they cover this. And they may even list a couple of things saying like, we're not responsible for this, this, and this.

[00:02:34]
Ember, for example, they don't support browsers older than, like Ember 1.x supported IE8. IE9 is what Ember 2.0 supports. So if you start filing
>> Mike North: Attacks that would only be possible on IE 6, the framework is probably not going to worry about it. It's not going to insulate you from.

[00:02:58]
So look at browser requirements as well. This is a good reason where if you see it's advertised that this thing, it works on most of the browsers I need and I just tested it, and it works on one version older as well. Be careful. It's not just about whether you have boots and render stuff on the screen, it's also about what the project is taking on in terms of assuring you that your users will have a secure experience.

[00:03:26]
So another thing to consider is how many people in the room have a browser plugin of some sort? Chrome plugins, yep, me too. And how many of us look really carefully at the permissions that those plugins ask for when they join? For every single one? And do you look at the code in the Chrome plugins?

[00:03:48]
>> Speaker 2: No not in the code, usually it's, is about to modify the page or something like that.
>> Mike North: Yup.
>> Speaker 2: So you just keep those.
>> Mike North: So, I think what we're likely, even if you're vigilant. There is skeptical, and then there is vigilant. If you're skeptical, you would say, wait a minute.

[00:04:08]
This is just, this is like a social media plugin. It has no business, it's asking for permissions that go beyond the scope of what I would expect for this particular thing. So that's suspicious behavior. But if you installed the plugin that was for, it's a dev tool and it's designed to work on any domain.

[00:04:31]
I don't know anyone that will heavily scrutinize the source code of that. So know that when you install a browser plugin, and it falls into that category, and it says it can modify content on all of your pages, it can cross-site script anything at all. Over HTTPS, over HTTP, it can do anything at all.

[00:04:53]
So this is the reason when you do your online banking and stuff like that, incognito tab and if you really trust something. For example, I allow one password to Chrome extension in my browser. I already trust one password. It's already keeping all of my secrets, right. And so in that situation, yes, I'll trust that.

[00:05:12]
I did actually take a look. It is a signed extension so no one can tamper with that code without having their private code signing key. I know it genuinely is from that company. I already trust them, but I have no other extensions that are allowed in in cognito mode.

[00:05:29]
Even if it's a community sourced thing like ReactDevTools or the Ember Inspector, anything like that, don't let it in incognito. And use that for things that are particularly sensitive, where you have Social Security numbers or banking data, anything like that. Because a browser plug-in can do basically anything.

[00:05:50]
In fact, these day it's probably the most easy way to get into someone's machine. It just sits there, you can make it where it has no icon, people just forget that it's even there, and it can just gather data for months. Really, really nasty way to get into someone's machine.

[00:06:06]
Also, if Cross-Site Scripting happens, what's your exposure? So, this is a good thing to think about in terms of limiting what web applications can do. And another lesson we can learn from the recent Equifax hack where we like, there are reasons to restrict what is possible through your UI and through your API.

[00:06:26]
Therearesome things that you just shouldn't be able to do. Like, I realize if you have a team that works remotely or something it might be convenient to allow a database dump to happen through some secret URL within your app. Don't do it, don't do it. That is just asking for someone to take advantage of it.

[00:06:41]
You're more protected if the public facing app that is available to your users is limited in terms of what it can do. Right? Don't let something return as many rows as possible. Don't build a secret query pram in there that's for advanced users and dumps the content of a whole table.

[00:06:59]
This is just asking for trouble. And then finally, what could you do if you escalated a successful cross-site scripting attack? So this would be a difference where For Frontend Masters, maybe you can get access to a bunch of video courses. For IOHealth a cross-site scripting attack to potentially allow people to see private health data from other people.

[00:07:24]
That's clearly more severe. For Experian, now you have Social Security numbers and credit card numbers and that is at the catastrophic level. What's your exposure? And that will help you prioritize, right? You've got a fixed amount of time, and features and bugs and tech to pay down and security issues.

[00:07:44]
If the consequence of risk is high, this should increase priority of addressing these kinds of things proportionately.