Protecting Against XSS In RAILS - JavaScript Contexts

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…

Disclosure: WordPress WPDB SQL Injection - Technical

Today, a significant SQL-Injection vulnerability was fixed in WordPress 4.8.3. Before reading further, if you haven’t updated yet stop right now and update.

The foundations of this vulnerability was reported via Hacker-One on September 20th, 2017.

This post will detail the technical vulnerability as well as how to mitigate it. There is another post which deals with the background and time-lines.

Disclosure: WordPress WPDB SQL Injection - Background

Today, a significant SQL-Injection vulnerability was fixed in WordPress 4.8.3. Before reading further, if you haven’t updated yet stop right now and update.

The foundations of this vulnerability was reported via Hacker-One on September 20th, 2017.

This post will detail the background on the vulnerability as well as why I publicly threatened to Fully Disclose. There is another post which deals with the technical vulnerability.

Ponderings on Odoriferous Syntactical Constructifications

(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.

Trust

Stop and take a moment to think about how much trust is required to live your everyday life. Every single aspect of your life is built up on layer after layer of trust, it’s nothing short of staggering. Different aspects of life will contain different levels of trust, with some being very guarded and some being very lax. We don’t often talk about this trust and we often make the blind assumption that trust is inherently a bad thing. That’s most definitely not the case. Let’s explore why.

All About Middleware

Last week, a proposal to standardize middleware for PSR-7 was introduced to the PHP-FIG. The general concept of middleware is not a new one, and has been in use in the PHP world for many years. Several people have raised significant concerns with the proposal, which have gone completely unheeded by the author. Let me go through the most major of these concerns, as well as show what a better proposal might look like.

*Note: All code that will be used in this post is real-world code found in the wild (and linked to) with one exception (X-Powered-By).

Simple, Easy, Risk and Change

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.

Tries and Lexers

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.