Web Components Can Improve Security

It’s been a very busy month: I presented twice at our internal technical conference, recruiting trips to a couple of universities, and we’re working hard to redesign our site to use web components and some other nifty features.

Every year at our internal training conference I try to present on one technical topic and one management topic. Here’s my technical presentation:

Did you know that using web components can lead to a more secure site, but that you have to be mindful of how you use them, or you don’t get the benefits?

I plan to publish my management presentation, as well as some new things I’ve learned this time recruiting on campuses, in the coming days.

Learning A Codebase

Responding to my post on internships a student asked me:

Q. Reading Code

What’s the best way to learn a new codebase?

A. Read With Purpose

Good question.

Identify a simple modification you would like to make. Learn enough to make that modification.

If you can’t make the modification after an hour of reading code, stop. Come up with something simpler based on what you have learned so far. Repeat this process until you successfully make a predictable change in the system.

Now that you have a grip on the code base start leveling up. Identify a slightly larger change. Give yourself a small deadline for achieving it. No longer than one hour. Keep leveling up the modification you are making until it gets to a level that is useful.

Remember:

  • Don’t start with a small useful modification — just a small observable modification.
  • Keep yourself on a tight leash. If you miss your short deadlines, make smaller tasks with shorter deadlines. Simplify until you gain purchase.

Above all, reading code is like any other skill. Do it more and you get better at it. Stop doing it and your skill erodes.

I hope that helps you.

Curiosity Installs the Root Kit

I’ve been reading Future Crimes and it is… sobering.  It details all sorts of documented cybercrime and makes some predictions on what kind of crimes we can expect to see more of.

I was perfectly primed to actually read the recent KnowBe4 newsletter when it popped into my inbox. It recaps how Comcast users were targeted with a double whammy that root-kitted their machines and stole their credit cards.

Where does it all start for the mark? Clicking on an interesting add. Read their newsletter for details.

Happy Holidays! 😉

Universal JavaScript

Presented to a small but packed room on “Isometric JavaScript.” Apparently I put a typo in my proposal and it made it all the way to presentation day.

It’s actually about isomorphic JavaScript. I like the name universal JavaScript even better.

For what it’s worth, here are the slides, and a link to the demo code at github.com/tylerpeterson/isojs:

 

XSS and How to Escape

Some time ago I wrote on cross-site scripting and proper escaping in EJS templates. I expanded the topic and presented on it today at the Salt Lake City Front End Users Group + Donuts.js. Here I stripped out the getting to know you slides and uploaded it to SlideShare.

The examples are in EJS but the ideas are universal.  Hopefully, this is one step closer to a perfect presentation on the subject. The topic can be tricky even though the solution is simple.  There are just so many attractive wrong ways to do it.

The presentation has several GIFs in it that really just add some fun. You can get all the meat by viewing the slideshow online. Or download it and have a laugh. (Check out the presenter notes if you do download it.)

“How to Make a Performance Budget” an article by Dan Mall

My last post on performance budgets emphasized back-end service latency. Dan Mall’s brief article “How to Make a Performance Budget” does an excellent job giving concrete examples of making a performance budget for asset sizes: HTML, CSS, JS, Web Fonts, images, etc.

(Via. Jakob Anderson)

Will EJS Escape Save Me From XSS? Sorta

If you’ve never had your website reported for cross-site scripting (XSS) vulnerabilities then you’re missing out. Of course, it’s great to get it right the first time. But it’s hard to beat that sense that you’re wide open for attack, it’s your fault, and everyone knows it thanks to some white-hat hacker.

This raises the question how to generally protect against XSS. Of course, there are a lot of ways to screw up. Here’s one of them.

Here’s Your Broken Code

You have a value on the server (like locale) that you want accessible on the client. You realize that you’re building the whole page in EJS anyway so why not plop a script tag on the page and pop a var into it? So, we render it right into some JavaScript like this:

var lang = "<%- locale %>";

Here’s the problem: What if locale‘s value is en"; doEvil(); "throw away string literal? Now we render into a JavaScript execution context the following code

var lang = "en"; doEvil(); "throw away string literal";

Which is valid AND EVIL code.

Does <%= Do the Necessary Escaping? Erm…

What if we use the escaping capability of EJS? Are we safe? Sorta.

Let’s bust out the REPL.

$ node
> var ejs = require('ejs')
undefined
> var locale = 'en"; doEvil(); "throw away string literal'
undefined
> ejs.render('var lang = "<%- locale %>";')
'var lang = "en"; doEvil(); "throw away string literal";'
> ejs.render('var lang = "<%= locale %>";')
'var lang = "en&#34;; doEvil(); &#34;throw away string literal";'

You see that using the back fat arrow (<%=) does prevent the evil from running in this case. But it isn’t really a safe technique in general.

What if you had a number instead of a string? What if you wanted to do the same thing to it? Continuing in the REPL the sample attack would look like this:

> var onServer = '6; doEvil();'
undefined
> ejs.render('var count = <%= onServer %>')
'var count = 6; doEvil();'

Notice that the escaping doesn’t help because there are no quotes in the attack string. In order for escaping to really work it would have to escape semicolons, too.

So, you’re kinda safe as long as you are using strings OR at least match the untrusted string with a RegEx like /[^;'"]*/ and use the matched text instead of the full text.

My Tools Have Betrayed Me!?

Why is EJS so broken? Why doesn’t escaping help you escape?

It isn’t broken. The problem is that back fat arrow is an HTML escape and you are rendering text into a JavaScript execution context.

For escaping to be reliable you have to match data context with escaping algorithm.

In this case the context is JavaScript and the algorithm is HTML. Close. But missed it by that much.

What’s the Right Way?

The Right Way™ to do this is to render it into a meta tag like this:

<meta name="lang" content="<%= lang %>">

Notice that here the escaping algorithm (HTML) matches the data context (HTML).

Then you get the value using code like this:

var metas = document.getElementsByTagName('meta');
var i, l = metas.length, lang;

for (i=0; i < l; ++i) {
  if (metas[i].getAttribute('name') == 'lang') {
    lang = metas[i].getAttribute('content');
  }
}

Looking at the Right Way™ it’s no wonder that we take shortcuts.

But seriously, the Right Way™ is much less XSS error prone.

For other ideas on how to get meta data from the DOM using JavaScript you can always Stack Overflow.

Merge Pull Requests Like a Legendary Project Maintainer

If you haven’t written code on GitHub then stop what you’re doing and make something out there. (You really should have a portfolio on GitHub.)

When you’re working all by your lonesome it doesn’t come up much, but add another person to the mix and pull requests can get stressful and laggy real fast. If you’re ready to upgrade your workflow then read about the better way to merge pull requests.

If you don’t learn how to use the hub command line tool then you’ll often find yourself having to decide how bad the request has to be before you’ll throw it back for polish.

Git OCD types will be particularly gratified now they can easily tweak pull requests before merging them. Now you can fix little problems here and there while still giving proper props.

Thanks to Jamis Charles for posting this link.

Column Mode versus Slow Mo’

Sublime Text’s column mode makes it really easy to create multiple cursors and make repetitive edits. This comes in handy all the time. 

On Mac, Sublime Text’s default key-binding for entering column mode conflicts with the system’s default key bindings for the “slow-mo” version of mission control.

I like mission control. I hate slow mo. Apparently you can’t have one bound to ctrl-up without the other bound to ctrl-shift-up.

Luckily it’s pretty easy to modify the sublime text shortcut from ctrl-shift-up (and down) to ctrl-alt-up (and down).

Just add the following bindings to your user key-bindings:

{ "keys": ["ctrl+alt+up"], "command": "select_lines", "args": {"forward": false} },
{ "keys": ["ctrl+alt+down"], "command": "select_lines", "args": {"forward": true} }

Of course, take care to get the line-ending-commas right if you already have bindings in that file.

I hope that helps you.