video transcript

Bad news/Good news time.

The bad news: you're probably gonna mess up sooner or later and add an XSS vulnerability to your code.

The good news: I'm gonna show you how to blame other people for it.

Hello, world. I'm Jesse from Chef Secure, and you need more code reviews.

Code reviews are the key to pushing responsibility onto others when you make a mistake.

Think about it. If you do something wrong and no one else is involved, all the pressure, and blame and shame fall entirely... on you.

That's a lot to deal with.

But if you can get others involved, and let them be the ultimate authority in approving your code before release. It's now their fault.

Why didn't anyone think of this sooner?

You know how sometimes you're in a rush to write new features as quickly as possible, and you don't have the luxury of double checking your code to make sure it's secure?

Mmm, hate that.

And what's worse is when someone finds a vulnerability in your code and they expect you to fix it, instead of giving you a bonus for creating new job opportunities.

So you gotta put down writing your ultra-performant code and pick up some obsolete, two-month old junk that you don't even remember.

Draining up to 40% of your productive time according to the American Psychological Association

https://www.apa.org/research/action/multitask.aspx

Not to mention the cost of unexpected interruptions which is estimated around 650 billion dollars a year, by the New York Times.

https://www.nytimes.com/2008/06/14/technology/14email.html

I'm sure you've all been there, so I'm gonna help out and show you how to prevent XSS vulnerabilities with code reviews.

Code reviews are where you write some code and have others look at it for bugs, completeness, style and security vulnerabilities.

Once reviewed and all the comments are addressed, the code can move forward in the release cycle.

On top of spreading the blame if something goes wrong, it's also a wonderful opportunity for mentorship and learning for everyone involved.

Making security discussion part of every code review will also reinforce the association between security and coding so that security becomes an actual part of the coding process, rather than just an afterthought.

To address XSS in code reviews, you need to ask if there's any untrusted data being delivered in the response.

If so, figure out all the contexts involved. It could be HTML content, HTML attributes, URLs, JavaScript strings, JavaScript regular expressions, JSON, CSS or some other combination of those.

Next, determine what escaping needs to be used, and if it's performed properly. And, remember, you may need multiple layers of escaping in a particular order, like with inline event handlers.

If there's no untrusted data, make sure you're not escaping anything that could break the page, such as escaping your own server-defined HTML from a helper method.

Frameworks with automatic escaping also have methods to turn off escaping to output raw data. Most of the time, these are used for good reason, again, like in helper methods, but the problem lies in the fact that untrusted data can sometimes sneak in.

You can also extend your code reviews to existing or legacy code. One way to do this is to set aside time every week or month to go over part of your application and try attacking it.

On top of finding potential security vulnerabilities, you can also have a better understanding of the scary old code that everyone's afraid to touch.

You can then add one more layer of security, by finding an automated code scanner that looks for XSS vulnerabilities.

There are many different options for the different frameworks out there, or, if you hate them all, then you can, at the very least, build your own simple script to look for dangerous functions being used in your code.

grep -r "dangerousFn" *

It might take a good deal to mark all false-positives as safe, but if you can stay strong, you can have a very effective tool that will add an extra layer of defense, in case a vulnerability slips by.

Afterward, in your build process, you can set it up so that, whenever someone pushes code, your scanner will run and if it finds a potential security vulnerability it will fail the build requiring the developer to either fix the issue or mark it as safe.

Which, by the way, is another perfect topic to bring up in a code review.

With ongoing communication, both new and experienced developers can learn to be proactive in securing their code as a natural extension of the development process.

And, most importantly, you have the perfect framework for blaming others for your mistakes.

Seriously though, people make mistakes, and everyone needs opportunities to learn and grow no matter how experienced they are.

So here's a tip: don't be an abusive, unlikable jerk.

Code reviews are best served with empathy and compassion.

OH! And don't forget the ice cream and cookies!