benv.ca

You are probably misusing DOM text methods

2012-10-04T00:00:00Z

This is a public service announcement.

element.textContent and document.createTextNode are dangerous DOM methods. They can easily lead to XSS vulnerabilities in your application.

We’ll find out how by looking at two common – but flawed – applications of these methods: stripping and escaping HTML.

Stripping tags with element.textContent

What does element.textContent do? (element.innerText in old IE) From MDN:

Gets or sets the text content of a node and its descendants.

Here’s an example:

var div = document.createElement('div');
div.innerHTML = 'Hello <a href="http://bob.com">Bob</a>!';
console.log(div.textContent);
// Hello Bob!;

Many developers use this method to strip HTML from a string, as I’ve just done here.

But what most people don’t realize is that this will also convert HTML entities into regular unicode characters:

var div = document.createElement('div');
div.innerHTML = 
  'Hello <a>&lt;script&gt;alert(&quot;!&quot;)&lt;/script&gt;</a>!';
console.log(div.textContent);
// Hello <script>alert("!")</script>!

My purpose here was to strip the <a> tag from this string. But in the process, I created wholly new tags. Possibly malicious ones.

If you were to ever use element.textContent to strip previously-escaped user content, and insert that seemingly-HTML-safe content somewhere else, you’ve just introduced an XSS vulnerability (example).

Now if you’re smart, you probably recognize that this should be escaped a second time. But I suspect many people are unaware of this vulnerability, and probably didn’t. I’ll be the first to admit it – I’ve made this mistake before. I suspect you or members of your team have too.

Here’s a modified helper function from Stack Overflow which escapes the final “stripped” output:

function strip(html) {
   var tmp = document.createElement("DIV");
   tmp.innerHTML = html;
   return escapeHtml(tmp.textContent||tmp.innerText);
}

Note that this function is not guaranteed to preserve the input. By placing the content in a DOM element – even temporarily – the browser will attempt to be helpful by “fixing” incomplete entities. If you want this to be perfect, you’ll need a pure HTML parser.

I’ve left the escapeHtml implementation blank for now, but you can imagine what it does: convert dangerous characters used in script injection into harmless HTML entities.

But wait a minute. Did you know DOM text nodes can also be used to escape HTML? Let’s find out more.

Escaping HTML with text nodes

We just looked at how accessing element.textContent returns the text content – without tags – of an element and its children.

But what if we do the opposite, and assign a string – with tags – to element.textContent?

var div = document.createElement('div');
div.textContent = '<span>Foo & bar</span>';
console.log(div.innerHTML)
// &lt;span&gt;Foo &amp; bar&lt;/span&gt;

Cool! By assigning HTML to element.textContent, it escaped the < > and & characters.

The same can be done by using document.createTextNode:

var div = document.createElement('div');
div.appendChild(document.createTextNode('<span>Foo & bar</span>'));
console.log(div.innerHTML)
// &lt;span&gt;Foo &amp; bar&lt;/span&gt;

It almost seems that the browser knows what characters are safe and which aren’t. Which is why many developers have taken to using this technique to escape their user strings.

Here’s an example implementation pulled from the web:

function escapeHtml(str) {
    var div = document.createElement('div');
    div.appendChild(document.createTextNode(str));
    return div.innerHTML;
};

And here‘s that function in action:

var username = '<img src="herp:/" onerror=alert("derp")>';
var profileLink = '<a href="/profile">' + escapeHtml(username) + '</a>';
var div = document.getElementById('target');
div.innerHTML = profileLink;
// <a href="/profile">&lt;img src="herp:/" onerror=alert("derp")&gt;</a>

In this situation, escapeHtml is effective. It prevents the malicious img tag from being inserted.

But if you paid close attention, you’ll notice that it didn’t escape every character. Both double-quotes and single-quotes were left untouched. And not escaping these characters can lead to XSS vulnerabilities when assigning a value to an attribute:

var userWebsite = '" onmouseover="alert(\'derp\')" "';
var profileLink = '<a href="' + escapeHtml(userWebsite) + '">Bob</a>';
var div = document.getElementById('target');
div.innerHtml = profileLink;
// <a href="" onmouseover="alert('derp')" "">Bob</a>

Congratulations – you‘re fucked.

I took that implementation from an article called Foolproof HTML escaping in Javascript. In that article, the author refers to this technique is referred to as “the best way to escape HTML in JavaScript". Unfortunately, it’s probably the worst.

He‘s not alone, of course. Here‘s a bunch of articles and Stack Overflow questions in which this technique is suggested, all by different authors.

Choice quote:

If you are using createTextNode, you are safe.

Use jQuery? The same vulnerable technique is also possible using .text(), and is endorsed in these jQuery solutions. A few Stack Overflow users mention the vulnerability, but their comments are buried.

There’s even several JSPerf entry that compares this same technique against other more tried-and-true methods of escaping HTML.

Now – there’s a counter argument here. Which is, if you know the context in which you are injecting the value (i.e. not attributes), then this method is safe. My argument is that developers don’t understand those contexts well enough, and sooner or later they will get it wrong.

If you want to escape HTML, use the tried and true method: string replacement. It’s boring, but it works (provided you always use quoted attributes and specify charsets, that is).

function escapeHtml(str) {
    return String(str)
        .replace(/&/g, "&amp;")
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;")
        .replace(/"/g, "&quot;")
        .replace(/'/g, "&#039;")
        .replace(/\//g, "&#x2F;")
}

This is a simple implementation. There are better ones out there.

NOTE: This also escapes forward slashes, which is recommended practice by OWASP. My understanding is that it is to handle cases where you are embedding user values inside a <script> tag.

Fight the good fight

In summary, HTML is scary, and DOM text methods present some very easy ways to get bitten. Worst of all, there is plenty of literature on the web which endorses their use in potentially vulnerable situations.

So if you’ve made it this far, I’ve got two things to ask of you.

First: it probably goes without saying, but audit your codebase to see if you’re messing around with element.textContent or document.createTextNode. They might be indicative of an XSS vulnerability. It can’t hurt to read OWASP’s XSS cheat sheet either.

Second: if you come across these anti-patterns – on Twitter, on Stack Overflow, or on the web in general – please do your part and shout/vote them down. You’ll be doing the web a favour.

Good night, and good luck.

Subdomain tunneling with jQuery and document.domain

2011-03-07T00:00:00Z

The problem: you’re serving part of your web app on a subdomain (sub.example.com), from which you want to make AJAX requests to your app’s base domain (example.com). You can’t just make AJAX requests between those domains, because of the browser’s same-origin policy.

Now, you can solve this by converting all your endpoints to support JSONP, or use a cross-domain messaging library like easyXDM. Definitely two solid options.

But! There’s an even simpler solution: host a bare-bones HTML file on your base domain that includes jQuery, and serve the page via an iframe from your subdomain. If you set document.domain equal to ‘example.com’ on both pages, your subdomain page can reach inside the iframe, grab the base-domain-friendly jQuery object, and make AJAX requests at your leisure.

Not anything new

Nope, not new. But, I thought you might find it neat that you can wholesale replace the subdomain’s instance of $.ajax with the base-domain-friendly copy from the tunnel. This means your subdomain’s JS can be entirely ignorant of the cross-domain wackiness happening in the background.

What it's like to live in San Francisco

2011-01-31T00:00:00Z

Background: In Spring of last year, I moved to San Francisco from Toronto to join Disqus, a commenting startup. More here.

Living in San Francisco, I often meet up with Toronto startup folks who are in town on business. Inevitably the conversation goes from industry news, to what’s going on back home (“Rob Ford is ruining everything!”), to settling on “How do you like living here?” I get the impression startup people in Toronto are genuinely curious: is San Francisco all it’s made out to be?

After 9 months here, I feel like I can comfortably generate an opinion on the matter. Short answer: it’s a great place, and I’ve definitely enjoyed my stay here — but like any city, it’s not without its faults.

For the long answer, please consult this jumble of thoughts I’ve put together:

Pros

San Francisco attracts people from all over the US — and the world. I feel like Disqus and other SF startups host a pretty diverse-crowd of non-locals; even our small roster of 15 people includes folks from roughly 9 US states and 4 countries. You won’t feel like an outsider, because everybody is.

The meetup scene here feels unparalleled. On any given week, I can go to a Ruby meetup, a GitHub meetup, our own JS Pub Nite, and countless others. They’re well attended, and the crowd is pretty incredible. It’s nice to rub elbows with employees from all your favourite Bay Area start-ups and companies.

There are no shortage of visitors. San Francisco hosts so many conferences, business meetings, and just straight-up tourists, that it’s common for me to meet up with friends and acquaintances 2-3 times a month.

San Francisco has a terrific food scene. It’s a little more on the expensive side, and I miss my cheap Toronto Chinatown eats, but otherwise I can’t complain. The city’s Mission district hosts some of the best Latin-American food I’ve ever had. And if you’re a real foodie, “neighbouring” Napa Valley also hosts some incredible Michelin-starred restaurants.

The weather is always mild. Right now it’s late January, and the temperature’s a comfortable 15 degrees. And it will be like that all year, basically. Some people tell me they find the lack of season change boring, but after 20+ years of snowy winters, I can make that sacrifice.

Wash

Industry talk dominates the city. You’ll hear it on public transit, inside cafes, and just walking on the street. It’s a surprising change coming from a finance-dominated city, but can sometimes feel tiresome. For me, at least.

The transit’s okay. Subway coverage is very light, which isn’t surprising for a city with a history of earthquakes, so you’re largely dependent on buses and streetcars. On the plus side, all the transit authorities are well connected, and getting up-to-the-minute schedule information via your phone is easy.

Cons

The rent. I’m not a big fan of commuting, so we’ve chosen to live in San Francisco’s SOMA district, which is home to a huge collection of start-ups and the Disqus offices. But, you sure do pay for it: 1 bedroom apartments here start at $2100/month. And there’s no rent control either; landlords are free to arbitrarily raise your rent after your lease is up.

The city itself is reasonably safe, but there are areas that are really uncomfortable to walk through. Toronto has its share of rough neighborhoods, but the upside is that you’d never want to go there — whereas in San Francisco, the Tenderloin and Mission districts are in the middle of the city and host some great restaurants and bars.

Cabs are cheap, but also scarce; a confusing economic situation. In Toronto, you can’t walk a block at night without being hounded by a cab or three. Here you’ve got to get lucky or wait 20-30 minutes. I’d rather pay the extra $3-4 I’m used to than sit on a creepy street corner alone at 2 AM.

There is a terrible homeless problem in San Francisco. I recognize it’s common of many West Coast cities, but I’ve been to Vancouver and Seattle, and my anecdotal experience says that San Francisco has it worse.

Set JavaScript breakpoints programatically

2010-08-08T00:00:00Z

When I’m debugging JavaScript, I’ve sometimes commented on how quicker things could be if I could set breakpoints programatically from the console, instead of fishing around in FireBug’s slow script browser.

Turns out it’s not that difficult to do. Here’s the code:

Appreciate any feedback, thoughts.

Belated project announcements: Malt, CouchDB-xd

2010-07-18T00:00:00Z

Malt.js

Last year I released Malt.js, an asynchronous JavaScript dependency manager. It’s basically a packaging system that lets you declare modules and include them on-demand.

Here’s an example:

Malt.module('facebox', 'js/facebox.js', 'css/facebox.css', function() {
  // initialize facebox
});

Malt.require('facebox', function() {
  // execute after all resources loaded, initialized
});

I think the syntax is particularly nice and minimal, but, admittedly, I haven’t used this library on any production apps. I came to conclude that it’s more beneficial to front-load cached scripts before a page renders than to load them as-you-go — at least for the kind of web applications I’ve been building. It would probably fit in better with a single-page application (i.e. GMail); if that’s your game, I encourage you to take a look.

Aside: If you’re just interested in loading scripts asynchronously, I recommend looking at LABjs. It’s a project that has basically figured out the optimal way to load scripts in parallel, adjusting for every browser.

CouchDB-xd

CouchDB-xd is a cross-domain AJAX library for CouchDB that provides a standard CRUD interface for Couch’s database and document APIs. It basically gives you the power to read and write to Couch databases from JavaScript, anywhere on the web. I think it makes for some interesting application possibilities, made easier with Couch.io and other “cloud” Couch hosts around the corner.

Aside: CouchDB already exposes a JSONP interface for its records (which is largely undocumented), but unfortunately, you’re limited to GET queries, which makes modifying records a no-go.

How do you sync your dotfiles?

2010-07-06T00:00:00Z

Idea: symlink and sync bashrc/profile scripts via Dropbox. Anyone doing this? — @bentlegen

@bentlegen I have a private Github repository for my .* config files (gitconfig, bash_profile, etc.) — @bleikamp

@bentlegen I use svn to manage my rc scripts, since I find I need them places where I can't install dropbox. — @mendel

@bentlegen No I just use homesick http://github.com/technicalpickles/homesick — @j_dan_williams

@bentlegen I keep all dotfiles in git because I like history and submodules. — @bretthoerner

@bentlegen shouldn't be too hard, and you can sync app preferences too: http://bit.ly/bePSt7 I just do the github+dotfiles thing, though. — @rtlechow

A new morning, changing weather

2010-04-08T00:00:00Z

This past week marked the end of a huge, important chapter in my life. After 3 fantastic years working at FreshBooks, I find myself moving on. Not just to a new employer – but to a whole new city, new country, and in some ways, a whole new life.

The story goes something like this. While wrapping up her PhD, my long-time partner was extended an amazing opportunity to work full-time as a researcher at Stanford University. We’d often discussed how fantastic it would be to live in another city for a few years, so it seemed like a perfect situation: a world-class university located right in the Bay Area and Silicon Valley. Needless to say, she took the gig, and I followed suit, which leads to my next announcement.

Starting this Monday, I’ll be the newest team member at Disqus, the web’s favourite commenting platform. I’m pretty excited: it’s a product I use personally and enjoy, it’s backed by a terrific team and world-class investors, and the technology has some pretty demanding JavaScript requirements that I’m eagerly looking forward to contributing to.

So, wow! Pretty crazy stuff. On one level, I’m certainly sad to leave Toronto, and all the friends and acquaintances I’ve made over the years. More so than I thought I would be, given the furious past few weeks of well wishing and goodbyes. But on the other hand, I’m really amped to touch down in San Francisco, and take up the adventure ahead. Wish me luck!

Update: Daniel at Disqus writes about my joining the team on the official blog.

Five tips for better JavaScript applications

2010-01-24T00:00:00Z

Last Fall I gave an Ignite presentation at Refresh Events on “5 Tips for Better JavaScript Applications”. If you’re not familiar with the format, an Ignite presentation is 5 minutes, 20 slides, with 15 seconds per slide. That’s not much time, but I thought it would be fun to try to present complex technical material under such tight constraints.

Long story short, it took some good ‘old fashioned fast talking, but I like to think the presentation was a success. The slides are located on Slideshare, but viewing them on their own without my stumbling narration might not do you much good. So I thought I’d summarize them again here:

1. Embeddable JavaScript Templates

I really dislike mangling together strings in JavaScript to produce markup, so I’ve taken to using templating libraries instead. Think erb, Liquid – but in JavaScript. My favourite solution so far is JSON Template, which has the upside of being cross-platform, but there are plenty of other choices: Pure, EJS, and jTemplates are just a few worth looking at.

One problem with JavaScript templates is choosing where to store them. Storing templates as JavaScript strings isn’t really any better, and individual files (fetched each time) seems overkill. My trick is to embed templates directly into HTML by hiding them inside a <script type="text/html"/> tag. These tags are ignored by the browser (since text/html is an unsupported script type), so they can live happily in the page until you need to render them. Credit to John Resig who mentioned this technique on his blog.

2. Classical Inheritance Libraries

JavaScript is a prototype-based object-oriented language, but with some clever manipulation, it can also be made to support classical inheritance as well (think Java, Ruby, etc.). I like using classical inheritance in my apps because it’s a well-understood pattern that any of my server-side-inclined colleagues can follow, quickly.

There are a handful of libraries that will help you get started. I’ve used both Dean Edwards and John Resig’s solutions, but Google’s implementation, as part of the Closure library, is worth a look too.

3. The Debugger Keyword

Did you know you that the “debugger” keyword will automatically set a breakpoint in any active JavaScript debugger in your browser? I find it’s a real time saver; instead of hunting down code in your debugger, you can set breakpoints from your editor. It’s even more helpful when you’re debugging across multiple environments; all the major browser support it.

I threw this into my original presentation as a one-slide means of saving time, but it’s still a great tip, and to my surprise, not exactly common knowledge.

4. Custom Events

You can trigger your own events in JavaScript, and bind to them as well, just like you can regular UI events (i.e. onclick). It’s a helpful tool in reducing coupling. Instead of calling a function directly, you trigger an event, and then other parts of your application can bind to that event and act accordingly.

If you’re a plugin developer, this is an ideal way to expose hooks to your plugin. Instead of having to inherit some base class and override an existing method, try triggering events people can bind to instead.

5. Preserving the Browser’s Back Button

Preserving the back button is easier than it looks. The jist of it is this: give your various application states a unique URL prefixed with the pound sign (#), then implement a “router” that can restore to these states when the page is loaded or the URL changes. That last part where it gets tricky – and where a plugin like jQuery history will help you out.

Other browser history libraries worth checking out: ReallySimpleHistory and jQuery Address.

merb_has_json_flash: JavaScript accessible Flash for Merb

2009-10-12T00:00:00Z

Several months ago, I began using Michael Ivey’s merb_has_flash gem on Guestlist. The gem, which provides Rails-like flash accessors to Merb, works as advertised, until I wanted to manipulate the flash contents via JavaScript. The use case: setting a success message and then reloading the page, all client-side. It was difficult because, although the Gem stores the flash contents in the user’s cookies, it’s stored as a Ruby serialized hash that seems unreadable via JavaScript.

The solution? A fork called merb_has_json_flash, which instead of serializing the flash in Ruby, does so using JSON. Now you can set the success message in Ruby or JavaScript, and the behaviour is identical. The only downside is that the flash store is no longer obfuscated, so it’s user-readable – not a big deal.

Here’s an example, using the jQuery cookie plugin:

<script type="text/javascript">
  $.cookie('flash', JSON.stringify({
      notice: 'Ticket successfully saved.'
    }), { path: '/' }
  );
  window.location.reload();
</script>

Anyways, that’s it. I hope someone else finds this useful – although it seems like Merb users are far and few between these days.

Blog now powered by Jekyll

2009-10-08T00:00:00Z

Huzzah. I’ve successfully migrated this blog from an ancient version of Mephisto to Jekyll, a static site generator written in Ruby. Since it’s statically generated, I don’t need a fancy hosting platform anymore, so I’ve cancelled my $20/mo Slicehost account and begun hosting the content out of a cheap Dreamhost account. Yeah, that Dreamhost.

If you’re thinking of making the move yourself, I’ve got a couple tips. First off, New Bamboo has an article that goes over the migration process. After that, the biggest pain is preserving inbound links because Mephisto and Jekyll generate their pretty URLs differently. I followed New Bamboo’s lead and forked my own version of Jekyll that patches this.

As for the deploy process, I’ve got it down pretty simple: I build the entire site locally, then rsync the result to Dreamhost. I’ve read about some complicated setups that use GitHub post-commit hooks to have your server check out the latest version and build it in place, but I think rsync does the trick just fine. It also means my Dreamhost account doesn’t need Ruby, the latest gems, nothing – just a dumb folder system where I can dump static content. So far, pretty happy about it.

Now, just to do something about this design …

FreshBooks.rb now maintained by Ben Curren

2009-04-04T00:00:00Z

I’ve been late to announce this, but Ben Curren (of Outright) has been maintaining the canonical copy of FreshBooks.rb for a few months now. He’s improved the library ten fold, so if you’re a FreshBooks/Ruby integrator, I encourage you to take a look.

Revised date, datetime helpers for Merb 1.x

2009-01-31T00:00:00Z

I’ve expanded on both mine and Jamie Macey’s original date helper code to support Merb 1.x, and added a datetime helper to the mix.

Usage:

<%= form_for @person %>

  <%= date_field :birth_date :label => 'Birthdate' %>

  <%= datetime_field :birth_date_and_time, :label => 'Birthdate and time' %>

<% end =%>

You’ll find the code here, via GitHub. I generally name this file date_field.rb, and stick it in app/helpers.

GitHub Pages for project docs, demos

2008-12-29T00:00:00Z

Have you seen GitHub Pages? As of mid-December, GitHub now hosts complete web pages that are backed onto GitHub-hosted Git repositories. To start, just define an alternate ‘gh-pages’ branch for your repo, add your web content and push, and it will appear at yourname.github.com/repo-name. It’s perfect for small one-off project pages, or even complete blogs.

I’ve already migrated my project documentation pages over (see: Abbreviator, Labelize). I like the idea that these pages are accessible at the same location as their corresponding source code, with complete revision history, even if my blog is down or – dare I say it – long defunct.

Abbreviator: a jQuery plugin for fitting chunky content

2008-12-22T00:00:00Z

Inside FreshBooks (the application), there’s a few places where we abbreviate long-ish text with ellipses to make it fit inside small table cells. This is done in PHP by a single function, whose two parameters are a string and the desired character length.

Of course, not all characters are made equal. We estimate appropriate character lengths as best we can, but it doesn’t always work. If users have a penchant for typing in capital letters, or use text zoom, our little abbreviating function can fail. And of course, every design change to these areas require new character length settings – a task that is easily forgotten.

So, after some sanity checking/brainstorming with my co-workers Taavi and Justin, I put together a little jQuery library for accomplishing this feat in Javascript. It’s called Abbreviator, and it adjusts for font size, browser rendering differences, padding, and more. Take a look at the project page for more.

That’s it for me for the year – Happy holidays!

Labelize: a jQuery plugin for making big honking labels

2008-08-21T00:00:00Z

Labelize is a handy jQuery plugin that lets you give input-containing elements <label/> like properties, so that clicking on the container activates the input inside. The goal? To improve usability by giving hard-to-click input elements like radio buttons and checkboxes generous target areas. Surprisingly, this can’t be done with a <label/> element alone — if you want it supported in IE6, that is.

Say we have the following markup:

<div class="myLabel">
  <input type="checkbox"/>
</div>

To make the “myLabel” div become a label-like container for the checkbox its holding, we simply do the following:

<script>
  $('.myLabel').labelize()
</script>

That’s it! Now if we click anywhere on “myLabel”, the checkbox is clicked — and its onclick() event is fired too. Huzzah.

If you’d like to see the plugin in action, I’ve whipped up a quick project page with some working examples. Please have a look and let me know what you think.