I’m cofounding a new startup, called Resources.co.

It will be a new platform for interacting with data and APIs.

Currently it has a visual JSON editor. If you go to Examples > Pokemon on desktop or paste request get https://pokeapi.co/api/v2/pokemon/bulbasaur into it on mobile, you can see the JSON editor. It will soon be able to make any kind of API request, like Postman.

I’ll post more about it later!

A while ago I got systematic about organizing the files on my computer. It started with a ~/github directory that mirrors the structure of GitHub itself. If I’ve cloned visionmedia’s commander.js, I know I can find it in ~/github/visionmedia/commander.js. This has helped make things easy to remember. Since then I’ve added an archive directory, a src directory (which contains most of my code), and a projects directory (which contains the code I’m currently working on. A few days ago I added an apps directory.

What does my ~/apps directory contain? It contains credentials and configuration for web apps, which I don’t want to store in my code repositories. For the fluxnote project I’m developing, it contains a script to set my environment variables to mirror what I require on Heroku:

export GITHUB_CLIENT_ID=7f2264d71eb1dfbc2611
export GITHUB_CLIENT_SECRET=copied_and_pasted_from_github
export SESSION_SECRET=a_long_hard_to_guess_session_secret
export GITHUB_USERNAME=benatkin
export COUCH_URL=https://therystillonleamoldescle:hahahahaha@bat.cloudant.com/fluxnote/

(Side note: Cloudant has clever auto-generated usernames. The username and GitHub Client ID are real; the secrets and password are not.)

If I run source ~/apps/fluxnote/config, the environment variables from the above script are loaded into my shell. Then I can run npm start to start my server. (After I add my Procfile I’ll also be able to run it with foreman start.)

I like it, because I have my credentials in one place, that I know not to give to anybody (and that would be hard to steal because I use full drive encryption).

During the last few years, while working as a web developer, I’ve seen awareness of the potential for XSS increase. I’ve also seen frameworks and open source applications come with better tools for avoiding XSS. There is still work to be done, though.

The most common way to avoid XSS is to have a very convenient way to put the escaped contents of a variable into HTML. What this does, is instead of inserting the HTML, <script>, it inserts the text, <script>, using the HTML, &lt;script&gt;. In Ruby On Rails and Django, variables are now by default escaped. In Django if you want a variable to not be escaped, you either need to mark it as safe in the python code, or include the template tag “|safe” in the template code. In mustache, you have double-mustaches for escaped ({{name}}) and triple-mustaches for unescaped ({{{html}}}). These encourage using the escaped option. With WordPress, using standard interpolated PHP, you have to be more careful. The simple <? echo $name; ?> will result in an unescaped value. To get an escaped value, the slightly longer <?php echo esc_attr($name); ?> or <?php esc_attr_e($name ?> can be used.

The above methods work for values inside and outside of tags, as they escape, at a minimum, <>"'. The angle bracket escaping deals with variables inserted outside of tags, and the quotes deal with data inside of tags (such as attributes).

There is one important case that they don’t cover, though: sometimes attribute values can do bad things. An href attribute can be set to javascript code, and if the users click on it, it will run. This is a security problem.

This means that, assuming the data isn’t validated first, the following mustache code is insufficient:

<a href="{{url}}">{{name}}</a>

Before it gets rendered, the URL must be sanitized to remove the javascript: URL scheme if it’s present.

Different tools have different ways of dealing with this:

  • Django doesn’t appear to have anything built-in, but the Bleach library covers this in its sanitization of HTML, at least partially.
  • Ruby On Rails has a built-in HTML sanitizer.
  • mustache, while extremely convenient for escaping HTML, doesn’t solve the URL problem, and so developers using it will need to look elsewhere. Google Caja would be one option.
  • WordPress has my favorite solution of all of these: the esc_url function. Running a full HTML sanitizer is overkill when using templates. I think it got a nice solution out of necessity: WP can be set up so users that aren’t logged in are allowed to comment and leave a link to their website, and malicious users could easily submit a link with a javascript: URI scheme. I took a look at the source for esc_uri and the functions it calls and it seems to handle a lot of cases, including a value starting with javascript:javascript: and the URI scheme being in upper case.

Most of these aren’t commonly known, and yet many, many apps provide ways to add URLs. Because of this, I think this must be a very common way of doing XSS attacks. It’s frustrating that I don’t have a quick way for developers to get up to speed on this, no matter what tool they’re using.

A better solution

I’d very much like a JSON test suite and a list of recipes to run the test suite in various languages, with extra recipes for languages where there is a framework or a library that makes the code shorter.