Detect global JavaScript variables with iframes

This post assumes you know about global variables in JavaScript and the basics of iframes. This post is meant for browser-based JavaScript, not other environments like Node.

It's pretty easy to accidentally leak global variables in JavaScript. Even the best of us accidentally find ways to fill the window object with variables we didn't intend to.

There are a lot of fancy tools that help you find these variables, but if you're looking for a simple oddball solution, you can use iframes.

Here's the finished, annotated code:

(function () {
  // Create an iframe and put it in the <body>.
  var iframe = document.createElement('iframe')
  document.body.appendChild(iframe)

  // We'll use this to get a "pristine" window object.
  var pristineWindow = iframe.contentWindow.window

  // Go through every property on `window` and filter it out if
  // the iframe's `window` also has it.
  console.log(Object.keys(window).filter(function (key) {
    return !pristineWindow.hasOwnProperty(key)
  }))

  // Remove the iframe.
  document.body.removeChild(iframe)
})()

In short, this looks at all the global variables on your window and compares it with the "pristine" window inside an iframe. If you have anything the iframe doesn't, it prints it out.

This is a bit of a hack and might not work in every weird edge case, but I've pasted this code snippet into the console and it's been useful!

Parse URLs with <a> tags in JavaScript

I've needed to use JavaScript to parse URLs while working at Braintree. In Node, this is easy; just use the built-in URL module. Before I started at Braintree, I thought browser-based URL parsing would require pulling in a third-party library or writing some tricky string parser. It turns out that there's an easy way that's built into browsers.

You can use <a> tags to parse out various attributes of a URL. For example, to get the hostname of a URL, you could do something like this:

var a = document.createElement('a')
a.href = 'http://evanhahn.com/parse-urls-with-a-tags/'

a.hostname  // => 'evanhahn.com'

You can grab things like hostname, protocol, hash, and much more. Take a look:

var a = document.createElement('a')
a.href = 'http://user:pass@evanhahn.com:8080/p/a/t/h?query=string#hash'

a.hash      // => '#hash'
a.host      // => 'evanhahn.com:8080'
a.hostname  // => 'evanhahn.com'
a.origin    // => 'http://evanhahn.com:8080'
a.password  // => 'pass'
a.pathname  // => '/p/a/t/h'
a.port      // => '8080'
a.protocol  // => 'http:'
a.search    // => '?query=string'
a.username  // => 'user'

This is really useful as a lightweight way to parse URLs!

How to transfer Android Neko Atsume saves using adb

This post assumes you have adb installed on your computer and can use it to communicate with your Android phone. You should have basic familiarity with a command-line terminal.

I've been playing Neko Atsume for months. It is almost frustrating that someone else discovered such a charming concept that could be so simple.

I recently got a new phone and couldn't find an easy way to back up my in-game spoils, so I did a little searching and found that you can use Android's adb tool to transfer your save between two Android phones by doing a simple backup/restore. And it doesn't require root privileges!

Here's how I did it:

  1. Install adb.
  2. Open up a terminal.
  3. Plug in the phone that you want to take data from.
  4. Make sure USB debugging is enabled on both devices.
  5. Run this command, which creates a backup file in your home folder:

    adb backup -f ~/back.ab -noapk 'jp.co.hit_point.nekoatsume'
    

    Some people have found problems with the single quotes around jp.co.hit_point.nekoatsume. If things don't work for you, try removing the quotes.

  6. When that's done, unplug the first phone and plug in the next one (the one you want to transfer your save to).

  7. Make sure the game is installed on this phone. Launch it to make sure it runs, then close the app.

  8. Run this command to transfer your backup to the new phone:

    adb restore back.ab
    

That's it! Your nekos should be safe. If this doesn't work for you, try out similar instructions on this Reddit comment.

This should, in theory, work on many apps. I only tried it on Neko Atsume but I'm sure it will work with many other apps.

Disable ESLint for a file

I love ESLint but sometimes you want it to completely ignore a whole file. Add this to the top of your file:

/* eslint-disable */

It needs to be in /* this kind */ of comment, not // this kind.

And ESLint won't complain about your file any more!

The CSP module is the largest part of Helmet

This post is aimed at people that have some familiarity with my Helmet Node.js module.

Helmet is a Node.js module that helps you secure your Express applications by setting various HTTP headers. It sets headers like X-Frame-Options to help prevent a kind of attack called "clickjacking" or X-XSS-Filter as a basic protection against cross-site scripting attacks. If you're writing an Express app (or a Connect or Koa app), I hope you'll give it a look!

The bulk of the module is pretty straightforward: just set nine HTTP headers. Some of the headers are set every time no matter what, while others have a small amount of logic associated with them. Eight of them are simple and one of them is a beast: the Content Security Policy (CSP) module. I'll spend this post talking about why that module is so much bigger than the rest.

Expect this to be boring.

Stats

I certainly feel like the CSP part of Helmet is the biggest. I spend the most time working on it and it's the hardest to wrap my head around. But how much bigger is it?

cloc is a cool program that counts lines of code. I used it to see which module was the biggest, and made sure to exclude node_modules, package.json, and test files. To see how big each module was, I ran this command in each directory:

cloc --quiet --exclude-dir=node_modules,test --not-match-f='package\.json' --include-lang=Javascript,JSON .

It gave me the following stats:

You can think of it this way:

  • CSP code: 223 lines
  • everything else combined: 226 lines

Why is it so big?

In short, the size of the CSP module comes from browser sniffing.

Every browser supports a slightly different variation of Content Security Policy (or don't support it at all). The simplest example is the name of the header. Newer browsers call the header Content-Security-Policy and older ones choose X-Content-Security-Policy or X-WebKit-CSP. There are loads of other browser differences that are much more difficult to deal with.

The CSP module has to inspect user agents to figure out what headers to set and how to set them. This is a nightmare. Without browser sniffing, this module would probably be about 30 lines; with browser sniffing, it's almost 200!

In my opinion, that's the real differentiator of Helmet. The rest of the library could be rewritten from scratch in a pretty short amount of time, but the amount of code and research that went into CSP-related browser quirks is pretty unique. It's the most frustrating to deal with, but it's the most important!