Tag Archives: security

So You Want To Keep Your Cookies Secure

At Social Tables, we have this Koa app that needs to read and set a session cookie. We don't want to send that cookie over an unencrypted connection, though.

We use koa-generic-session for session management. That library uses the cookies library under-the-hood, and luckily, there's a simple configuration option to avoid sending cookies over an unencrypted connection!

But it's not that simple.

Turns out that the cookies library inspects the request and will throw an error if the app tries to send a secure cookie over an insecure connection.

This is all fine until you start getting fancy. Fancy, as in, the app is behind an SSL-terminating load-balancer. Which means that the app thinks the connection is an insecure HTTP request.

Now, there is a configuration option for Koa:

app.proxy = true;

This tells Koa that when determining whether a request is secure it may trust the headers that the load-balancer adds to each request.

And, again this is just fine until to start getting even fancier. Fancier, as in, the load-balancer actually points to an nginx proxy that serves static assets and points other traffic to the Koa app.

Now, you can find pointers for how to configure nginx behind an SSL-terminating load balancer.

And that's fine until you start getting ultra-fancy. Ultra-fancy, as in, the load-balancer is configured to support PROXY protocol. I'm not going to get into the reasons why we ended up being so ultra-fancy that we wanted to enable PROXY protocol on our load-balancer. Truth is, we don't need it. But the upshot of why this causes problems is that the headers added to each request are different. And not just different. There is literally nothing in the proxy headers that indicates that the client request was made via https vs. http.

So... luckily our app is hosted on Amazon AWS in a VPC that is not reachable from the internet. In other words, there's no way a request could reach our nginx process other than via an https request that hits our load-balancer. Which means, we can just -- gulp -- hard-code it.

The relevant configuration in the nginx config:

server {
  # ...
  # This is empty because of PROXY protocol
  if ($http_x_forwarded_proto = '') {
    # So we hard-code the protocol as https, i.e., "secure"
    set $http_x_forwarded_proto https;

  location @node {
    # ...
    # This is the header Koa will rely upon
    proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;

By the way -- and I hope this isn't burying the lede too much here -- but if your app only relies on reading those secure cookies, you don't need to worry about this michegas. A user's browser doesn't know or care about what's behind your SSL-terminating load-balancer using PROXY protocol to talk to nginx proxying to your node app. All a user's browser knows about is the https request that hits the load-balancer. Only if you need to set a secure cookie do you possibly need to know about this.

Hope it helps someone.

Twitbin Fails Basic Password Security

UPDATE: FIXED. See the comments below.

A couple weeks ago, I installed twitbin, a Firefox extension that loads twitter in a sidebar. But, I just happened to be checking my browser cookies, and I noticed that my twitter username and PASSWORD were stored in my browser cookies in plaintext! This is not even a session cookie -- it is persistent, with a one-year expiration.

Are you kidding me?! Twitbin -- uninstalled.

"[I]t is never appropriate for cookies to contain plaintext user names and passwords." [The World Wide Web Security FAQ]

Scheduled Tasks - Running Tasks Without A Password

For XP Pro: Go to Start/Administrative Tools/Local Security Policy/Security Settings/Local Policies/Security Options
Accounts: Limit local account use of blank passwords to console logon only. This is enabled by default, disable it.

For XP Home: (Keith Miller) Go to Start/Run/Regedit and navigate to this key:

Value name: limitblankpassworduse, Type: REG_DWORD, Data: 0 (disabled) 1 (enabled)

For Home: Run Scheduled Task without a Password (Line 67)

Windows XP FAQ