02:40 - Justin Collins Introduction

03:40 - Brakeman & Static Analysis

04:02 - Common Security Vulnerabilities (and Definitions)

08:57 - The Inspiration for Brakeman

09:47 - Getting Brakeman Working (Process)

10:41 - Learning About Security

13:01 - Security and The Rails Core Team

15:19 - Should Brakeman be integrated into Rails?

16:29 - Running Brakeman On Your CI Machine

17:43 - Are there specific types of vulnerabilities that are hard to find with static analysis?

19:18 - Rails Engines

20:56 - When building an app, is security something you should focus on from the get-go?

25:32 - Code Schools Teaching Security

26:17 - Translating Lessons Learned Into Brakeman

27:24 - Handling Security and Data Breaches

32:28 - Crowdsourcing Security (Security in Open Source)

34:54 - The Technical Side of Brakeman and Static Analysis Tools

37:34 - Data Tracing, Limited Data Flow Analysis 

40:52 - Future Brakeman Features

43:29 - Supporting and Contributing to Brakeman

48:23 - PhDs

Picks

"Why didn't you [just]..." and "Did you consider..." Parley Thread (Avdi)
Object Thinking (Developer Reference) by David West (Avdi)
Web Design - The First 100 Years (Avdi)
Brighton Ruby Conference (Avdi)
Email (Avdi)
The Twitter Mute Button (Avdi)
git - the simple guide (Saron)
I Love My Campus (Saron)
LoneStarRuby (Saron)
React Rally (Jessica)
Livecoding.tv (Jessica)
Remembering the Apollo 11 Moon Landing With the Woman Who Made It Happen (Coraline)
Showgoers (Coraline)
AngularJS Kurs (Chuck)
Hire Thom Parkin! (Chuck)
RethinkDB (Justin)
Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age by Michael A. Hiltzik (Justin)
The Search for General Tso (Justin)

Special Guest: Justin Collins.

 

We're discussing the count of David Brady's remaining teeth.

[Chuckles] Wait, how many are there?

Just the one.

Hey everybody and welcome to episode 219 of the Ruby Rogues Podcast. This week on our panel, we have Coraline Ada Ehmke.

Hello from New Hope, Pennsylvania.

Jessica Kerr.

Good morning.

Avdi Grimm.

Hello from Tennessee.

Saron Yitbarek.

Hey, everybody.

I'm Charles Max Wood from DevChat.TV. And we've got a special guest this week and that is Justin Collins.

Hello.

Do you want to introduce yourself?

Sure. I'm Justin Collins. I'm known to most of the internet as President Beef and author of Brakeman, the static analysis security tool for Rails. And currently, I split my time between working at SurveyMonkey as an application security engineer, and working on Brakeman Pro.

Why President Beef?

So, that is something that I never explained.

Yes, exclusive! [Laughter]

No, I'm still not going to explain.

Oh, no! [Laughter]

Okay. I tried.

Okay, well more importantly as President of Beef, where can I find the best brisket? [Laughter]

I usually brisk at Korean BBQ places. So, that's where I would go.

Oh, that sounds really good. Alright, well, so Brakeman. Do you want to give a brief introduction of what that is?

Sure. So, Brakeman is a static analysis security tool for Rails. [Chuckles]

Okay, so it basically looks at your code and tells you what you did that was unsafe?

Right. So, the idea behind static analysis is basically anything you can determine about a program without actually running the program. So, it's looking at the source code of your program and then looking for potential security vulnerabilities.

Can you give us some examples of common vulnerabilities?

Sure. Cross-site Scripting, SQL injection, mass assignment, open redirects.

Wait, aren't most of those covered by Rails? I mean, Cross-site Scripting is turned on by default, or Cross-site Script... yeah, anyway, the forgery checking, is turned on by default. And SQL injection, I guess you have to deliberately use that. But...

So, Rails does give you a lot. However, there are a lot of holes in what it gives you. In fact, if you check out Rails-SQLi.org, a little website I put together that points out all the areas where Active Record, you would expect it to be protecting you from SQL injection but it doesn't.

Okay.

So, why doesn't it? Is it just being sloppy and careless, or are there reasons for not doing that?

I suspect there are reasons. You would have to ask the Rails core team why those reasons exist. In some cases, I think they expected people to use it in a different way than most people use it. So, there are places where you can pass in SQL fragments or hashes of arguments where most people aren't going to do that. They're just going to pass in a single integer. That's what they expect to happen. So, I assume when they were designing the API, they just had different use cases in mind than what people end up actually doing.

Well, I know when I was first programming in Rails, this was back version 1.1 or 1.2, and I'm not sure if the bad examples came off the internet or from coworkers who were newish to Rails, too. But we would interpolate into a string and then tell Active Record to go find it. And so yeah, we were wide open to SQL injection. And then as I got a little more experienced and my friends got a little more experienced, then we realized that that was probably not smart. So, a tool like that that said, “Hey, that's not smart,” would have been nice.

I think that is a lot of the value of Brakeman, is when people run it and they don't really know what it's going to find, and then it points out problems, and then they say, “Why is that even a problem?” And then they go dig into it and it ends up being a learning tool that way, as opposed to just a 'point out the problems' tool.

Right. So, let's assume that we have new people listening to the podcast. Do you want to just briefly explain what SQL injection and Cross-site Scripting and some of these others are?

Sure. The way I like to look at it is that SQL injection, Cross-site Scripting, command injection, other injections, [laughs], but they're all forms of injection where you're taking untrusted input and you're handing it to a parser of some kind. That parser could be an HTML parser. It could be a bash command line parser. It could be a SQL parser. And when you're handing it that input, you're expecting it to be treated as data. But instead it's being treated as code and being executed.

So, for Cross-site Scripting, you're usually talking about JavaScript being executed in the browser. But you didn't expect it to be executed as JavaScript. You thought it was going to be displayed as text.

For a SQL injection, you're passing a value into a SQL query and you thought it was going to be treated as data, but instead it's being treated as SQL and executed. So, all those fall under this broad category of injection attacks.

Now, are those the only ones that Brakeman finds or are there others that you're looking for too?

No. So, there's quite a few. So, mass assignment is one. I think everyone's kind of aware of that now because of GitHub being hacked by Egor Homakov and all the drama that came out of that. [Chuckles]

So, most people are like, “Oh yeah, mass assignment. I know that one.” So, it will look for those. It looks for a lot of specific things, like... it's still Cross-site Scripting, but when you're creating a link_to tag, you're calling link_to create a link tag, when you pass... well, so depending on the version of Rails, older versions of Rails, either parameter to link to the text to put in the link or the link itself were both vulnerable. But now, the text is safe but the link is still vulnerable because it doesn't care what protocol you use in the link. So, you can pass in 'javascript:' and execute that. So, that's not really something that's happening in the template. That's something... well, it is in the template. But it's an issue with Rails being unsafe in that way.

And I also mentioned open redirects earlier. So, when you're using redirect_to, by default it will redirect to wherever you want. And there really isn't a good way of saying, “I only want you to redirect to somewhere within my own application.”

What inspired you to start with Brakeman in the first place?

So, Brakeman was actually an internship project at AT&T interactive. And what happened was I went in for the interview for the internship on the security team not really knowing anything about security. And we were talking about Cross-site Scripting and whatever. And I said, well you know, what if you just had a tool that would look at the inputs and the outputs of your program, and if an input went all the way to the output without being escaped, then it would warn you about that. And they got really excited and they said, “Oh, do you know a tool that does that?” I said, “No. But it can't be that hard to build it.”

Famous last words, right?

[Laughs] Exactly, exactly. Five years later, here we are.

But I assume it didn't take five years to get it working, right? I think you're on version 3 is what I saw?

Yeah, that's true.

So, how long did it take to get that proof of concept?

Basically the length of the internship. So, the end of the internship it was open sourced. And I don't recall what at all was working. But I know the first thing I worked on was Cross-site Scripting. And at the end of the internship, it was released. And then I didn't work on it because I had no reason to work on it. And then AT&T Interactive hired me back and then I started working on it again. And since then, most of the companies... well, I worked at AT&T Interactive and then I worked at Twitter, and in both cases working on Brakeman was part of my job. So, that kept me going. Otherwise, as just a regular person, I don't really write Rails apps and I have no reason to work on the tool.

So, what have you learned about security over the last five years writing Brakeman?

Basically everything I know about security [laughs] I've learned in the last five years working on Brakeman.

What was the thing that probably surprised you the most?

I think what tends to surprise me is that I started working at SurveyMonkey recently and so it was a change of company and a change of the set of developers. And I never know what other people know. And you want to assume that people know what you know. And it turns out most people don't know what you know. And when it comes to security, a lot of people, maybe they have a vague idea, but no one wants to dig into the specifics of things. And they tend to assume that their tools, their frameworks, are doing the work for them and that they're safe if they use the framework, use Rails. I'm using Rails so it should protect me from SQL injection and from Cross-site Scripting.

But without understanding how they're protecting you, it's easy to make a mistake and do something that's unsafe. So, I guess the thing that tends to surprise me is that people don't know about security. But it really shouldn't be a surprise, because I didn't know either until I started doing it.

Are there good ways to start beefing up on security if you're a Rails developer?

Yes. I would recommend using Brakeman. [Laughs] The Rails Security Guide is actually very good. In fact, people outside of the Rails community will point to it as an example of where to learn about web security. So, it's a very good guide. It's getting a little outdated now. But it's still pretty good. There's also the Rails Cheat Sheets from OWASP which has a lot of the same information. And then if you just start looking through the OWASP guides in particular, there's a lot of good information there.

OWASP, for those who don't know, is the Open Web Application Security Project. It says project in the name, but really it's a global non-profit organization that's really dedicated to just getting information about web security to developers. So, they put together a list called 'The OWASP Top Ten' which through some magical process they come up with a top ten most important web vulnerabilities. And that's a really good place to start looking.

Cool. You mentioned that in some cases security problems have emerged because the Rails core team did not anticipate what people were going to do with the functionality that they provided. How important do you think that that security is to the Rails core team? Do you think they spend enough time and energy thinking about it?

So, my very personal opinion is no. I think there's a lot of work that could be done there. The presentation I did at RailsConf this year listed out a bunch of things that I think Rails could be doing better. And when I gave the presentation, no one in the room, at least no one in the room admitted they were a Rails core committer or there were none there. And from things I hear from other people who are in the Rails security world, trying to get Rails security issues fixed usually takes quite a bit of time and sometimes some convincing to get them to actually fix things. So, it's nothing against the Rails core team. I think they're all wonderful people. But I don't think that the focus on security has been what it should be.

Can you give an example of something that you think they could do better in Rails core?

Sure. I gave the example already of link_to. There's no safe way of using it. redirect_to, there's no way of safely using it that's built-in. There's no... I mentioned the website where I put together all these examples of using Active Record unsafely. And quite a few of those, I think they could really just change the API. Rails 5 is coming out. Just get rid of the backwards APIs that probably no one's using, right? But Rails 5 would be a good time to break that functionality if people are using it.

I also think, I talked about this in my presentation, but I think there are certain things that are provided by gems that really, maybe they should start being built into Rails, like having an authorization framework, having account and session management built in so that it's just there and it's ready to go. Almost anything built on Rails, you're going to have user accounts. And you need some way of managing them. And everyone I think comes up with their own way which may or may not be safe.

So, is the larger I guess goal or vision for you and Brakeman to get it eventually integrated to Rails, in Rails? Is that important to you?

No. So, because Brakeman is a static analysis tool, it really shouldn't be run with your code, which is an issue that I have with Bundler and people putting Brakeman into their gem files. And there really, there isn't a good solution for this as far as I know, because people want to declare the dependency on Brakeman so that they can have Brakeman available and run it, which is great. But if you put something in your gem file and then you run it via Rake, Rake will load up all of your Rails app and then start running the rake tasks. So, you have Brakeman dependencies which are totally unrelated to your app dependencies. And yet they have to work together, which doesn't make sense. So, I don't think having Brakeman part of Rails makes much sense. However, I think anyone who is using Rails should be using Brakeman as well. But it doesn't make sense as a source dependency. I don't know how that would work.

So, do you just run it on your CI machine or is it fast enough to run it when you run your tests?

So, I think CI is the best place to run it. There is a Brakeman plugin for Guard which will run every time you change your code. And it uses some Brakeman goodness to incrementally scan your application. In fact, it's the only plugin that does this. So, any other tool that tries to only scan the files that have changed is actually not using Brakeman well, because Brakeman needs to see the entire application. So, you can run it as files change. You can run it as part of your tests. It's generally fast enough to do that, except for large applications.

I usually say, if Brakeman takes longer than five minutes to run, you should probably file a bug and let me look into it. But in the end, I think CI is the best place for it, because it's out of the way. And as a security person, I think it's important not to get in people's way because then they get grumpy about security [chuckles] and don't want to deal with it. So, I think the CI server is the best place for it.

I also wonder. Are there specific types of vulnerabilities that are hard to find with static analysis?

Yes, for sure there are. Anything that doesn't have a specific pattern to look for. If you're writing your own code to do something, there's no way really to know that that's going to be dangerous or not. And really, the reason I think that Brakeman has been successful is because Rails is so focused on this convention over configuration and things are generally in the same place. And you can make a lot of assumptions about what the code is doing. And then you have the whole Rails API with all the stuff built in. So, you can build that into a tool. So, you can say, “I know what this method call does because it's a standard Rails API.” So, I can tell if it's safe or not just from knowing it's a Rails method. But when you start venturing outside of that, it's very hard to determine what's going on.

Plus, there are whole classes of vulnerabilities that you just can't find, because they're logic problems. You were mentioning before the show you were working with payment processors. Well, there's no way I can detect that your inner action with some external API is wrong. Maybe when it returns the response from the API you're not treating it correctly. And you're allowing a sale to go through that shouldn't go through. There's no way to detect that statically unless you know everything about the API and all the calls that you're making, and can figure out that logic.

That leads me into another question, and that is, so I've worked on some applications that had certain amounts of shared logic that were put into Rails engines. If you're not familiar with Rails Engines (I'm sure you are, but I'm just saying for the audience), Rails Engines are essentially plugins but are usually packaged up a gems or put in a Git repository and treated as gems anyway. Does it look into those kinds of things as well, or do you need to run the static analysis against your engines as well?

So, that's a very good question. Right now, it doesn't work very well if you try to run it on the engine alone, unless that engine is pretty beefy, and there's a lot of stuff. You know, you have a lot of controllers and everything going on in there. But if it's very narrow and you're just adding one little piece of functionality, it doesn't work very well because it's hard to tell that it's actually a Rails app. However, if you can add your engine either to the engine's subdirectory, which is I believe where they used to go, but maybe not anymore, or if you can point Brakeman to your engine directory, so if it's in source control and maybe it's in the same repo and you can point Brakeman to it in addition to your main app, then it will work. It basically just treats it as if it's part of your application.

But there actually is some work to do around that to make it a little bit better. I believe there's an open issue for Brakeman around that, if someone wants to look into it. So, I would say it's supported but not super well.

Gotcha.

So, when is the right time to start thinking, I know the answer to this question, but if you have advice for people who are just getting started with an app, is security something you should be thinking about right from the get go?

Absolutely. So, like most things in software engineering, the earlier you do it the better and the easier it will be. Trying to retrofit security into legacy applications is just miserable, right? Just like retrofitting changes into any legacy applications can be hard and difficult and you don't want to break things and maybe it relies on certain behavior that is like, “Well, if I change this I break my app but if I don't change it, it's not safe.” So, if you do things safely from the beginning your life will just be that much easier, plus you'll be secure from the beginning as opposed to being not safe for a period of time and then trying to go back and fix things.

I heard an absolute horror story. Here in Chicago there's an incubator, a tech incubator, where there tends to be a lot of idea people looking for technical co-founders. And these technical cofounders tend to be people straight out of code schools. So, there's one particular project that was aimed at a very noble goal of helping people on welfare understand what their benefits were. And they were collecting personal information in the form of Social Security numbers and addresses and storing them unencrypted. And apparently their API had a hole in it so that it was possible with some URL manipulation to get a plain text dump of personal information for all the site's users.

Oh my goodness.

It was pretty horrifying. It's a shame because it was a great project with a noble goal but there were very inexperienced developers who barely know how to write a Rails application let alone a secure Rails application who were in charge of doing it.

So, where do people like that get started then? Because you're saying we should be paying attention to it from the beginning and I completely agree. But a lot of times people get hung up on, “Well, I don't know anything about security and I don't know what I don't know about security. And so, I'm just going to hand-wave over it for a little bit,” instead of at least taking that first step and going, “Okay, well at least I know SQL injection,” or, “At least I know cross-site scripting,” or, “At least I know maybe one or two other things.” Where do people go to get that kind of education?

So, I would point back to the OWASP Top Ten that I mentioned before, because I totally agree with what you're saying, because when you're writing app, when you're writing any software, what's the first priority? It's just to get it working. [Laughs] Right? What do I have to do to get it working, to get the functionality that I imagine in my head? Now I need to get it working in code. So to me, of course it would be great if everyone had all this security knowledge. But of course, that's unrealistic, just like it'd be great if people knew about all these libraries and all these great APIs you can use. And no one can keep all that information in their head.

So, for developers I think what's important is just to have that awareness, right? If you don't know what cross-site scripting is, you should probably look into it just to understand that there's this thing called cross-site scripting and what it is. You don't have to know all the ins and outs and what are all the defenses and what are all the ways that people can get around those defenses and all of that. But just be aware that it exists. And I think that's why the OWASP Top Ten is so useful. It says, “Okay, here's a list of ten things that you should be thinking about, that you should be aware of.”

And then using tools I think like Brakeman to help you with, “Well, I'm using Rails, for example, and

I want to be security conscious but I don't know what is safe and what's unsafe in Rails.” So, Brakeman can help you with that side of it. However, I do think that there is a responsibility on the side of the framework developers, not just Rails but any web framework.

And you know, new web frameworks come out all the time. And I think there's a responsibility there to have these basic protections built into the framework itself. So, escaping output by default, having safe ways of interacting with the database, having cross-site request forgery protection built in and on, and all of those built into the framework. Because as you mentioned, there are things that are hard to detect statically. There are things that are hard to get right. And the more things that you can get right by default without having to worry about it, the better off everyone's going to be, including people who are brand new and they're just trying to write an app and get things working.

Do you think that code schools should be teaching security?

It seems like a good idea. And again, security is a huge topic. And it's getting larger all the time. So, my suggestion is really to just cover those basics, just to have an awareness of the things that could happen. And I think that goes a long ways towards when you're writing the code, understanding even if maybe initially you write it in an unsafe way, understanding the possibilities of what can go wrong can help you go back through and go, “Oh, wait. I wrote this API and if someone did this, then this bad thing would happen. And I wouldn't have thought of that if I wasn't aware that these things could happen in the first place.”

So, you've done security for AT&T Interactive, Twitter, now SurveyMonkey. I'm wondering what kinds of security issues did you see in those roles and how many or how much of that did you translate over to Brakeman.

So, that's a good question. As much as possible any time... I'm going to answer your question backwards. So, any time I see something new or I find out about something new, I'm always thinking, “How can I get it into Brakeman? Is it possible to detect this? And if so, let's get it into Brakeman.” In terms of the kinds of things that I saw, they tend to be the same things that you see everywhere. You have cross-site scripting. You have SQL injection. You have people forgetting to add cross-site request forgery protection to a particular endpoint. So, as long as these really surface-level well-known vulnerabilities continue to exist in our apps, it's almost not worth talking about the more complicated weird stuff that can go on deep in your code. And of course, I can't talk about specific issues I've seen. [Laughs]

I am curious. One other thing, since we're talking about security, is let's say that I build an application that does have user data or other sensitive data in it, what do you do when you actually have a breach?

What do you do when you have a breach?

Yeah, so what if somebody finds a way through SQL injection or some other exploit on Rails or on something that I'm using in my Rails app, they find a way in and they take that data and I figure out that somebody's been in there. What should I do in order to mitigate the damage? And I think for a lot of people, the tendency is to just go and hide it. But I don't know that that's necessarily very helpful.

Right. So, data breaches have become a big topic, even in mainstream news cycles. And in the security community, I think most people are pushing towards notify people as soon as possible, make sure you understand the scope of what happened so that you can be very specific in what information was accessed, how many people were affected. And from there, it determines what you do.

So, if you say, “Well, actually all that was accessed were people's email addresses.” Well, that's not extremely sensitive information. So, what do you do? As a user, there's not really much you can do unless you want to change the email address you gave to a particular site. There's not a lot of action to take there. If you say however, “Well, your Social Security number was accessed and your home address was accessed,” now people should probably be going and talking to credit companies and putting protections around that information so that they're not victims of identity theft.

And depending on your company and what you handle, you may have different obligations under PCI regulations or HIPA regulations. And those tend to include notifying your customers. Anyway, the feeling in the community, the security community, as I'm aware of it is notify people as soon as possible and be very specific about what was accessed, and what that means for the users of your service. Because if you just say, “Well, there was a data breach and some people were affected but don't really worry about it,” people get very suspicious. [Laughter]

These are not the Droids you are looking for.

Yeah, just, “Something happened. But don't really, don't pay attention to that. Everything is fine.” People assume the worst. So, the more specific you can be, I think the better. And having that quick response. More and more people are expecting that if something happens to you securitywise, you better tell them right away. Because people tend to find out. And then stuff is going on in social media and they're like, “Well, the company hasn't even made a statement yet.” And if you wait a week, oh, it's game over. People are really mad. On the other hand, you don't want to say anything prematurely.

So, for companies, that's a tricky position to be in. You don't want to say, “Okay, they only accessed this information,” and then you find out actually they accessed more than that. So, that process and being on that end of it inside the company dealing with that kind of a situation is very stressful. [Chuckles] You're running around like, “Are they still in the company? What could they access? What is the worst-case scenario here?” First you're thinking, “Oh my gosh, the sky is falling.” But then sometimes you find out, “Oh, well actually, it wasn't that big of a deal. We're okay.” So, it's not easy being the company that's having a breach either. [Chuckles]

Yeah. I've always wondered what the user response or backlash is to that. Obviously you have to be honest, you have to be transparent, you have to let the users know what's going on. But in your experience, how forgiving have users been? And what determines whether they say, “It's okay.

Don't do it again,” [chuckles] or they just leave?

Charlie Miller who's a well-known security researcher, he gives this talk. And he basically went through and he looked at companies that had breaches. And he looked at their stock price around the time of the breach. And what he found was the stock price dipped and then went right back up. So, the market in that sense [chuckles] is very forgiving. However, these are going to be large companies that are public. And I think the smaller you are, the bigger the impact is going to be, the less forgiving people are going to be. If you just have some little startup and as Coraline was mentioning, there's a breach, it's very easy for your 500 or 1000 users to say, “You know what? I don't trust you. I'm out of here.” Whereas if you're Target, well people are probably going to keep shopping at Target, right?

Yup.

Yeah.

I have a question, Justin. I saw a talk at Open Source Bridge by a woman named Terri Oda. She was talking specifically about security for open source applications. And she emphasized the role that crowdsourcing security can have and the importance of having distinct communication channels for reporting potential security risks, like a specific form or an email address. Do you have an opinion? I know Brakeman is a static analysis tool. But what about crowdsourcing security? Do you think that's an effective tactic?

So, I'm a huge open source fan. And I think in open source, of course the opportunity for people to find stuff is greater, because the source is available. And if the source is not available, the likelihood of someone finding stuff is lower. And I do think that it's valuable to have people looking at the code. And I don't know how much people go and look for security issues in open source code. But I think of course it's wonderful if they do. And I do think you have to start considering, when you're an open source project, what do you do if there's a security issue in your code? Because I think you have a responsibility to your users to protect them.

So, what do you do when someone wants to report a security issue? Like you mentioned, well ideally you have some private way of communicating that to the maintainers. I don't know that many projects are big enough to require that. It seems like a bit of overhead when you don't know. You know, it may never be used. So, I don't know. I have mixed thoughts on the private communication channel. Of course, it's great if you can do it. But I don't know if it makes sense to say, “Hey, every open source project should have some private way of reporting security issues.” Maybe it makes sense to have an organization in charge of that that can accept those reports. That might make sense.

However, in terms of crowdsourcing security, it's a great idea. And you just have to be careful about what is your response. Of course you want to fix it. But then as soon as you patch it, right, people are going to know if you push it publicly. So, just being responsible about notifying people, “Hey, there is a security fix in this release. You should update. And here's the new update,” I think is really important.

Makes sense.

I have some questions about the technical nitty-gritty of Brakeman and how it does the static analysis. I was wondering if you could just explain at least at a high level, if you're looking for a cross-site scripting vulnerability, what patterns are you looking for in the analysis?

There's many ways the static analysis tools do this stuff. The way Brakeman does it is it works on the abstract syntax tree itself. And so, when you're talking about cross-site scripting for example, the way that, as far as I'm aware, all Rails templating languages work is that they actually compile to Ruby code. And in that code there will be different method calls depending on whether they're escaping that output or not. So, that makes Brakeman's job relatively easy because it can look at, it will actually use the libraries, compile the templates to Ruby code, and then uses Ryan Davis's ruby_parser to parse that into an abstract syntax tree.

And then it knows, so this is a Slim template, this is ERB, whatever it is, these are the method calls that are safe and these are the ones that are unsafe. And at that point, it's easy to detect. However, I will say one thing that Brakeman does and I think maybe people are less aware of is that it's only going to warn you about cross-site scripting if it actually thinks there's a dangerous value being output. If it doesn't know where the value is coming from though, it doesn't know it's dangerous and it won't warn you about it. So, that's to avoid people getting annoyed with false positives. But it may also lead to some false negatives. So...

What is it looking for to identify a dangerous value?

Right, so in Rails again, this is just because Rails is so standardized it makes these things a little bit easier, so if you see a call to params, you know that it's a query parameter. And that's dangerous. So, it looks for params. It looks for cookies, even though people don't usually output cookies, but it looks for that. It looks for session variables. And then it also looks for, are you outputting an attribute from an Active Record Model? And that one I think is the most controversial because people, well for one thing it's hard to tell if it's actually a database-driven attribute. But also people, a lot of people are like, “Well, stuff in my database is safe, right?” And it's like, “Well, no. Maybe. It may be safe, may not be safe.” So, those are the main things that it looks for.

And are you doing any kind of data tracing, or is it pretty much just like one remove from the parameters or some other unsafe source?

Right. So, Brakeman does do some, what I like to call limited data flow analysis. And again, this is one of the reasons why it works well with Rails. And when people ask me to make it work on other things, I say no. [Laughs] Which is that you know in Rails, this is a controller. It's going to be setting values. And then it's going to be rendering a template. And it's going to be rendering this template. It's very easy to determine which template's being rendered. So, what Brakeman does is it will look at your before filters. If you set any instance variables there. And then it will look at the controller action and the values that are set there. And then it will look at the template. And if you're using values in templates that were set in a controller, it will generally trace those values through.

And then there are some other things that it can do. Oh, I'm sorry. I skipped the main part [chuckles] which is that it does local data flow analysis, so within a method or within a template it will trace assignments through to their uses. However...

That's pretty cool.

I agree. [Laughter]

It's also one of the things that tends to set Brakeman apart from other static analysis tools, because a lot of times they don't do that. However, I...

Was that really hard to code or was it super hard to code? [Laughter]

First of all, thank you for that acknowledgement. So, where it gets tricky. It was actually... so yeah, most of the complexity in Brakeman is in that analysis. The hardest part was... this is maybe why you should not read stuff on the internet, but I was working on Brakeman and I was about to release 1.0. And then I saw this post in a mailing list and it said, “Oh yeah, Brakeman's okay. But it can't even detect this.” And they had this simple if statement where they were assigning things and because of the way the data flow analysis worked, it didn't understand this if statement.

So, right before the 1.0 release I'm like, “Oh, well I can deal with that.” And I implemented handling branches inside the code. And it totally ruined the performance of that release, because when you start dealing with, “Well, the code could do this or it could do that,” you end up with just tons of possibilities. And the way Brakeman handles that is basically by unioning the possibilities values that something could have. And those unions tend to go out of control. So, there's a lot of code around, “Okay, well if I'm unioning these two values, let me look at them. Do I only need one or the other or can I combine them somehow? Or is this just getting too big? I'm just going to stop doing this.” So yeah, there was a lot of complexity around that. And also the way Brakeman does it is much different than a lot other tools would do it. And that leads to complexity and weird output sometimes.

What sort of features do you have on the horizon for the next release?

So, I've actually been re-writing a lot of Brakeman internally. So, early on one of the things I did was when ruby_parser builds the S expressions and the abstract syntax tree, the names it uses for some of the nodes, I didn't like them. [Chuckles] So, I thought, “Oh, I'll just replace them with names that I like,” which seemed smart at the time. But then what happened was later on in the code, I would have to go, “Oh wait, it may be using the name that I gave it or it may be using the original name because I didn't actually process this node and change the name.” So, one thing I've been doing is pulling out that and going back to the original names.

However, there are some things I'm working on. Right now, Brakeman doesn't look at mailers at all. And really, mailer templates end up being a lot like regular templates in Rails. So, I want to work on that. Let's see, what else? There's some work to be done around HAML. Sometimes you'll get this output from HAML templates that Brakeman doesn't quite handle properly. So, there's internal methods that are being called that it should be treating as internal methods. But instead, it says, “Oh, there's cross-site scripting here,” which is not entirely correct. And then another thing I've been working on is supporting the helper methods inside of controllers. Actually, I think I already fixed that. There's always stuff to be changed and fixed. And yeah, [laughs].

Have you ever considered taking your experience with static analysis and building other kinds of tools with it?

Other kinds of static analysis tools?

Yeah, looking for stuff other than security.

Not really. I basically have my time filled up with working on Brakeman. What I have done though is I've given a couple of presentations which I hoped would explain the choices that I've made with Brakeman and how to apply it to other languages so that people can build these kinds of tools. I don't know how successful that has been. But I do feel like I got that information out there. So, if you wanted to build a similar tool, you could. But yeah, personally Brakeman is enough of a hassle that I don't really go looking for other things to do.

Gotcha.

Is there a way for people to support the project?

To support Brakeman itself?

Yes.

So, I've always felt very strange, you mean monetarily? [Chuckles]

Yeah, monetarily, code, documentation, just general help. Any of that.

Ah. So yeah, I mean...

But I know there's a monetarily in there, so...

[Chuckles] So, yes people are always welcome to help. For me, the biggest thing, the biggest help, is when people can say, “I tried to run Brakeman and it didn't work,” or, “I saw some output that I wasn't expecting,” or, “I'm using a different templating language. Are you going to support it?” Because that gives me stuff to work on, stuff to fix. I will say that Brakeman is not the easiest code to work on. And it has nothing to do with the complexity of doing static analysis. It has everything to do with, I started working on it five years ago and I hope I'm a better programmer now than I was then. So, contributing code I realize is difficult. And there isn't a lot of documentation around it. So, contributing just by opening up and issue and saying, “I tried to run it and it didn't work,” is very useful.

Documentation, I wish people would help out with that. That would be great, especially around using the tool and understanding the tool. I don't have a good sense for whether people find it hard or easy to use. A lot of times I ask people and they're like, “Oh yeah, I just used it. And it was fine,” and like, “Okay, so I guess it worked.” [Laughs]

Financially, I've always thought it's a little bit strange because generally I've been able to work on it while I'm actually at my day job. And so, things have come up where, “Oh, you should apply for this open source grant or this sort of funding over here,” and I'm like, “Well, I already get paid to work on it.” So, I'm not worried about it. And I don't want to take that away from projects that do need it. That being said, if you want to pay me to work on specific features, I will take the money, for sure. However, I believe your question was leading towards the existence of Brakeman Pro.

Yeah, we talked about that at RailsConf, so I was curious to see where that was at.

So, we are in the middle of the beta, the closed beta. So, if you are interested in trying it out, you're welcome to go to BrakemanPro.com, sign up for the beta. There isn't really a screening process. [Chuckles] We just send you an email with the links. So, we are working on it. And by 'we' I mean myself, Neil Matatall, and Jim Manico. And we're plugging away on it. Brakeman Pro is going to be actually a desktop application. So, I think everyone expects it to be software as a service. And if you're looking for Brakeman as a service, as I like to call it, there are a bunch of providers out there. Just google for it, or actually on the Brakeman GitHub wiki there's a list of providers. And I don't recommend any over another. I don't play favorites but there are lots of providers out there.

So, Brakeman Pro is going to be a tool, a desktop application. And it's a way to one, present the information in a different way, a new way that's easier to navigate, easier to consume. As well as being an opportunity for me to put in the functionality that really doesn't fit in the open source project. So, for the open source project it's really about being fast and giving relatively low amounts of false positives. So, there are features that I don't implement because I know it's going to add a lot of overhead or it's just going to generate mostly false positives. However for the Pro product, I think there are a set of people that they want all that information. So, that's where the Pro version is differentiating itself as well as having a nice UI.

And to be honest, I forgot that the open source version doesn't have this nice UI. And I was using it at some point and I was like, “Oh yeah, I got to use this ugly HTML report. And oh, it's kind of hard to deal with. So, if you feel like you want to contribute to Brakeman and you're like, “Well, I don't know if I can dig into the code and I haven't really run across any bugs,” feel free to go and redesign the HTML report and make it much more beautiful.

So Justin, you went and got a PhD and did your research in something completely unrelated to Rails security. Why did you get a PhD? [Laughter]

Why did I get a PhD?

I think almost everyone who's in graduate school is wondering that same question. [Laughter]

So, just personally when I was finished getting my Bachelor's in Computer Science at Seattle University, I feel like a lot of people have the same feeling. I went, “Wait, I'm about to graduate. I don't feel like I know enough.” And so, I was interested in graduate school. I'd done some research in undergrad and I thought, “Well, this is kind of fun.” And then I thought, “Well, maybe I'll go get a Master's.” And then again, this is just a totally personal thing, but I was like, “Well, but why stop at a Master's? If I'm going to go, I should just go all the way.” And that is the wrong attitude, by the way. That is not a way to have... [Laughter]

That is not how you should decide whether or not you should get a PhD. However, I don't regret it, even though I think I took a very non-traditional route. I worked for the last three years. Three years? No. Maybe it was the last three years? No, wait. I'm sorry. I can't remember how time works. [Chuckles]

But I had full-time jobs working at AT&T Interactive and Twitter while I was finishing my PhD which was a totally wrong thing to do. I also got married while I was doing my PhD. And right when I finished my final defense, my adviser, he shook my hand and he said, “You know, the two biggest reasons why I see students not finish their PhD is they start working full-time jobs and they get married. So, I'm very surprised that you actually graduated.”

Yeah so, and a lot of people are surprised that I didn't do it in security, I didn't do it in... Brakeman wasn't my PhD project. And that's because I started Brakeman as an internship project after I was already in the middle of my PhD. So, that's why it ended up being totally different. And my PhD was on mobile ad hoc networks. And so, there's a question of “Well, why didn't you do security for mobile ad hoc networks?” And I will tell you that I didn't do it. I actively did not do it because it is an incredibly hard question. [Laughs] And I wasn't interested in solving that question.

Cool. So, are you glad you have your PhD now that it's done?

So, [sighs] I'm glad I did it. Honestly, I wouldn't have built Brakeman if I hadn't done my PhD because the classes I took on static analysis and compilers was during my time at UCLA doing my PhD. But I don't know that actually having the PhD is that valuable. [Laughs] But it's... I actually read a comment and it said, “I don't think anyone who's gotten their PhD has finished without some kind of permanent brain damage.”

Oh no. [Chuckles]

I don't know that brain damage is the right term, but it's definitely an emotionally challenging process to go through. And there are a lot of people that, it's very damaging. So, it's not something to do lightly. So, I don't know. I don't know what to tell people, because on one hand, I think it was worth doing for me. But if the goal is, “Well, I'm going to have a PhD,” it's not really worth that much. When I was working at Twitter, everyone at one point, every team except our manager had a PhD. So, when you're like in a field, in a sea of PhD's, no one cares that you have a PhD. [Laughs]

Gotcha.

Do you make people call you Doctor?

I tell people not to call me Doctor. [Chuckles].

I don't know. Doctor Beef? That sounds pretty cool.

I prefer Doctor President Beef. [Laughter]

Very nice.

Yeah. Before we get to picks, I want to take some time to thank our silver sponsor.

Avdi, do you want to start us with picks?

Sure. I've got a bunch of picks but I'm going to keep them all short. So, starting off, we haven't had a best of Parley pick in a while and I've got one. We've got a thread going on Parley right now that sprouted off of episode 216. And it's talking all about nice ways of bringing up issues in code reviews, ways of saying, “I'm not sure I would do it that way,” but in a really non-threatening way. And it's a really neat fruitful discussion. I'm learning stuff from it.

Next pick. I have finally finished the book 'Object Thinking' by David West. It is the most important book about object-oriented programming I have ever read, period, full stop.

Wow.

Next pick. There's a great long article. It's actually a talk that was turned into a transcript article by, I do not know how to pronounce his name correctly. I'm just going to pronounce it as if it were in English. Maciej Ceg_owski. I'm sure I butchered that. But he's been one of my favorite writers on the web for a long time. He writes great stuff about travel and he writes great stuff about tech. He's the guy behind Pinboard. And he's got an article called 'Web Design: The First 100 Years' that's fantastic. It basically says that web design right now is kind of like where the space program is, where if you look back, we really expected more of it and it's kind of grounded itself in a way we didn't expect. But that's actually a good thing. So, fascinating article, and as always with him, very, very funny. Next up, I...

Yeah, plus one that.

Yeah. I just got back from Brighton Ruby and that's a Ruby Conference in lovely Brighton, England. I had a wonderful time. Fantastic conference. Andy Croll did a great job putting it on. Great location. I definitely want to get back to Brighton. I understand that he's already planning another go around next year, bigger and better. And yeah, if you want to go to a conference in the UK, you can definitely do far worse than this one. I'd love to get back to it again.

Next up. I just want to pick email, which seems like a weird pick, especially anybody who follows me knows that I regularly tweet about how full my email inbox is. But mostly I complain about all the stuff that forces me to make decisions. Lately as I've been stepping away from social media, I've picked up some email threads with people where I've just started sort of regularly emailing back and forth with someone and having these really long extended interesting conversations. And I hadn't really done much of that in a long time. It's been wonderful. I really realized how much I missed having this long, relatively deep, relatively slow-paced conversations with people. So yeah, email. It still exists and it's kind of awesome.

And finally, I will pick the Twitter mute button because it's not your responsibility to give consideration to every random thing that somebody says to you. And the alternative to considering it and trying to rebut it is to simply mute them and let them happily natter on to themselves with no...

Amen.

Yes.

With no need for either of you to take any further action.

Yes, plus one. [Laughter]

That is it for my picks.

Awesome. Saron, what are your picks?

Sure. I have three picks. I'll make them pretty quick, too. So, one is a Git tutorial that someone sent me. I can't remember who it was. Somebody in the CodeNewbie community sent me that I really, really like. So, I'd done these online Google Hangout intro to Git sessions live and made it really interactive. And after doing I think about four or five them, someone said, “You know, you should send this out as a follow-up.” And it's really great. It's called 'git – the simple guide', really simple. It has big fonts and big letters and really simple commands and simple explanations. And it's just simple all around. So, I love it a lot and I would definitely recommend anyone take a look at it. And even if I assume a lot of our listeners are very familiar with Git, but it's also just a really good example for how to write tutorials and documentation. Everything from the style and the format to the wording to the order. So, if you're interested in making educational material and tutorials and all that, definitely look at this as a template. It does a really good job.

The second one is more for fun. So, I've done, I used to do this more often but I really like 3D art stuff. And I found one that I love. And this one is called 'I Love My Campus' and it's really cool. I'm not going to tell you any more about it. But you should look at it. And it's awesome. It's really cool. And the last one is LoneStar RubyConf. So, I'm going to be keynoting with Avdi and Dave Thomas from Pragmatic Programmer. Avdi, I'm so excited to get to meet you in real life, by the way.

I know. Me too, me too. [Chuckles]

So, that's in two weeks. So, if you are in Austin, Texas I would love to meet you and get to hang out with you. So, that's my final pick.

Awesome. Jessica, what are your picks?

Okay, okay. One quick pick, I guess I should pick React Rally, which is a conference in Salt Lake City because I'm going to be speaking there on August 24th. Which is interesting, because I've never used React and my JavaScript is terrible. But I totally know what I'm going to speak about and it's how functional programming and data flow is important and how React and then Elm embody that in JavaScript. So, that'll be interesting.

But my other pick is Livecoding.tv which is a site where you can watch people code. And that sounds strange, but then again, people like to watch other people play video games, so why not watch them code? It's a very new site. It's only been live since June. And my sister and I tried it the other day when we were pairing. Why not throw it out there on the internet? And while there were some technical difficulties, no fewer than three admins jumped into our channel and tried to help with those and get our settings just right. So, it's a good time to, if you want to try it, it's a good time for that. There's a ton of support. And you know, if you're learning to code, why not listen to someone think through how to solve these problems? It seems like it could actually be useful. So, we're trying that out. Livecoding.tv. That's my last pick.

Alright. Coraline, what are your picks?

I have a couple of picks today. My first one is Margaret Hamilton. There's a picture making the rounds on Twitter of a woman standing next to a stack of printed and bound source code that's almost as tall as she is. That woman's name is Margaret Hamilton and she was a pioneering software engineer at NASA. She's most well-known for her work on Apollo 11's on-board flight software which is what was printed out in that picture. So, she's been profiled on a recent Time magazine article. The article touches on the importance of testing, which was vital to her work back then on the Apollo program. And also hints at her work on what she calls preventative software. So, she's an amazing woman and amazing engineer. And it's worth learning ore about her.

My second pick is something called Showgoers. So, because of my conference speaking and travel, I have friends all over the world. And sometimes, I like to get together to watch movies with them on Netflix. Lately it's been a lot of 1980's John Hughes movies like Pretty in Pink which I'm not embarrassed about. There's this Chrome extension called Showgoers that synchronizes your Netflix player with other people's so you could co-watch the same movie on different computers and stay in sync. It's a matter of sharing a URL. And then when you pause or play or seek to a specific spot in the movie, it sends out a ping to the other people who are synchronized with you so their players automatically sync to what you are doing, which is a pretty cool experience. And it makes for nice movie nights with people who are remote. So, Showgoers is my last pick.

Sounds good for long-distance relationships.

Absolutely.

Alright. I've got a couple of picks here. The first one is, so just to preface these first two, when I did the Rails Clips Kickstarter campaign, I offered people at a certain level some favors. And so, I'm just going to pick a couple of things because they look cool and because I told folks that I would. So, the first one is if you're in Switzerland, one of the backers has an Angular course. So, if you're interested in Angular and you're in Switzerland then go check that out. That one is done by Daniel Egger. So anyway, I'll put the link in the show notes and you can go check it out.

The other one is Thom Parkin. Now, he actually a while back did interviews with all of the Rogues at the time. And he's actually looking for a job. So, he's been coding for, he said before the releases of the original Star Wars. And he's been doing DOD government contracts but he wants to break out of that. And he's been spending his time working on open source and writing technical articles. So, I'll go ahead and put some information about him in the show notes as well. So, if you're looking for an experienced programmer then go ahead and reach out to him.

And I think that's about it. So Justin, do you have some picks for us?

I do, yes. So, the first one is open source database called RethinkDB. And I picked it not because I think we should all be using it as our document store distributed database, but because it's an excellent example of writing software, particularly open source software, in a way that I think people should emulate. The fact that you install it and then you run one command, no options, just one command you get your database, you get a really nice-looking admin UI, and it all just works. And I think they just did an excellent job on making software that is easy and straightforward to use as well as having really nice documentation around using the different drivers. So, my first pick is RethinkDB.

Then my next two picks are related, even though... not related to RethinkDB but related to each other. So, the first is a book called 'Dealers of Lightning' which has the awesome subtitle 'Xerox PARC and the Dawn of the Computer Age' by Michael Hiltzik. And it's an amazing look at basically what Xerox PARC was doing in the 70s. And basically everything you think of with modern computing probably came out of Xerox PARC, including laser printers and touch screens. [Chuckles] So, it's a really fascinating look at the history of computing, and also some of the driving forces behind it, as well as a great look into Allan Kay. Which having met him in person a couple of times, it totally fits what he's like.

And then my third and final pick is a documentary called 'The Search of General Tso' which my wife happened to be watching on Netflix the other night. And it's actually very related to 'Dealers of Lightning' except that it's about Chinese food in America. And the relationship is that while I'm watching it, I get these moments where I'm just like, “I can't believe that's what happened and that's why the world is the way it is now,” where some restaurant somewhere came up with some dish and now it's everywhere. And, “Wow, that didn't exist 100 years ago.” 100 years ago, Chinese food was like some weird thing that those weird foreign immigrants eat. And now, it's something that everyone in America pretty much enjoys eating and you see it everywhere. And just tracking that change through history, it's a really fascinating documentary and it's available on Netflix. That is it for me.

Awesome. Well, thank you for coming, Justin. It was fun to talk and it was really interesting to go into some of the security stuff around Rails.

Thank you for inviting me.

Alright. Well, I think we're done. We'll go ahead and wrap up the show.