Recently my team was working to implement Brakeman in our CI processes to automatically scan our codebase for security vulnerabilities. Among a few other issues, it identified a handful of similar XSS vulnerabilities of a similar pattern:

<script type="text/javascript">
  var FOO = "<%= raw whatever %>";
  ReactDOM.render(<Blah
    foo={window.FOO}
  />, document.getElementById('some_place'));
</script>

This is a pretty straight forward vulnerability, since passing "; alert(1); " for whatever will result in the code being rendered as var FOO = ""; alert(1); ""; which isn’t good.

The fix, isn’t so simple. I’ve searched high and low, and couldn’t find a single source that had the correct solution to the problem. So here it is…

(AKA: “Thoughts on code smells” and how “high brow” they have become)

We have a habit of talking about “code smells” to indicate patterns and practices that our experience has shown can be problematic. Many of these “smells” are backed by a lot of data and really are legitimate problems to avoid. These are constructs and tools that often have few legitimate uses. But many so called “smells” really aren’t significantly bad. Let’s dive into some of the nuance here and talk a bit about why our word choice matters.

I have been building a computer. Not assembling components, but actually designing and wiring it from scratch onto prototyping breadboards. I’ve decided to start writing about the project here on my blog. I have no idea how many posts this will wind up being, or if there even will be others. Let me start by telling you what I’m building.

I’ve been thinking a lot about change lately. Things finally resonated to me after listening to Uncle Bob Martin on No Capes. He made an amazingly interesting point about change and different methods for minimizing the risk over time of change.

I want to share some of what I’ve been thinking about along those lines. What follows is a collection of some of my evolving thoughts relating to change and complexity. Let me know your thoughts in the comments.

Lately I have been playing around with a few experimental projects. The current one started when I tried to make a templating engine. Not just an ordinary one, but one that understood the context of a variable so it could encode/escape it properly. Imagine being able to put a variable in a JavaScript string in your template, and have the engine transparently encode it correctly for you. Awesome, right? Well, while doing it, I went down a rabbit hole. And it led to something far more awesome.

Developers as a whole suck at API design. We don’t suck at making APIs. We don’t suck at implementing them. We don’t suck at using them (well, some more than others). But we do suck at designing them. In fact, we suck so much that we’ve made entire disciplines around trying to design better ones (BDD, DDD, TDD, etc). There are lots of reasons for this, but there are a few that I really want to focus on.

There’s one skill that I learned in College that I wish everyone would learn. I wish it was taught to everyone in elementary school, it’s that useful. It’s also deceptively simple. So without any more introduction, let’s talk about Dimensional Analysis:

I learned something rather disturbing yesterday. CodeIgniter 3.0 will support PHP 5.2. To put that in context, there hasn’t been a supported or secure version of PHP 5.2 since January, 2011. That’s nearly 4 years. To me, that’s beyond irresponsible… It’s negligent… So I tweeted about it (not mentioning the project to give them the chance to realize what the problem was):

I received a bunch of replies. Many people thought I was talking about WordPress. I wasn’t, but the same thing does apply to the project. Most people agreed with me, saying that not targeting 5.4 or higher is bad. But some disagreed. Some disagreed strongly. So, I want to talk about that.

I have the honor today of writing a guest blog post on Igor Wiedler’s Blog about Compilers. If you don’t know @igorwhiletrue, he’s pretty much the craziest developer that I know. And crazy in that genious sort of way. He’s been doing a series of blog posts about Stack Machines and building complex runtimes from simple components. Well, today I authored a guest post on compiling code to run on said runtime. The compiler only took about 100 lines of code!!!

Check it out!

An interesting pull request has been opened against PHP to make bin2hex() constant time. This has lead to some interesting discussion on the mailing list (which even got me to reply :-X). There has been pretty good coverage over remote timing attacks in PHP, but they talk about string comparison. I’d like to talk about other types of timing attacks.