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…

Don't Worry About BREACH

Last week at the BlackHat security conference, a new attack on SSL secured content was unveiled. This attack is called BREACH, and has been generating a lot of buz on the internet. Tech blogs have been plastering their sites with articles about how there’s no fix, and how you can try to defend against BREACH. Well respected security people have been writing about it.

And I’m here to say don’t worry about it.

XSS - Web Application Security - Post 2

In the first post of this series, we looked at some fundamental concepts of Web Application Security, and introduced the concept of Filter In, Escape Out. In today’s post, we will be examining the single most prolific vulnerability plaguing web applications today: Cross-Site Scripting (otherwise known as XSS). Not only is it prolific, it’s also commonly under-estimated and is often just a low priority after-thought. In reality, XSS is a formidable threat and needs to be treated as such.