Brakeman (a static analysis security vulnerability scanner) - useful for Elixir?

Chat / Discussions
1

Is something like brakeman for Ruby useful for Elixir? I read it in the http://devonestes.herokuapp.com/ruby-vs-elixir-projects-people-edition/ as a reason that someone did not use elixir. What exactly does brakeman bring to the table and is it truly useful for Elixir and what could it do at all for Elixir?

2 Likes
2

I guess it depends on what vulnerabilities it helps you spot? Is there a list of what Brakeman actually looks out for?

3

Brakeman is for a specific framework (Rails), it is not a general Ruby security tool. The correct question is should Phoenix have such a tool? ( My answer would be yes. )

4

I have a tool I’m working on that aims to be a “brakeman for Phoenix”. It’s currently in review, but will hopefully have an initial release this week.

As of now, it checks for some configuration issues, XSS, directory traversal, and a few other things. It’s already been super useful for me, and I’ve been able to uncover a number of critical vulnerabilities in the larger public Phoenix applications. For example, I used it to find the ElixirStatus vulnerabilities (https://griffinbyatt.com/post/file-read-on-elixirstatus) in just a few seconds!

9 Likes
5

I’ve literally been setting up brakeman across our ruby builds on our Jenkins server for the last 2 days so I’ll give my impression.

What I’ve seen it do so far:

  • Cross reference out of date dependencies against known security alerts and tell you what to update to
  • Monitor variable paths from user input and look for dangerous unsanitized use, including SQL injection, redirects and converting strings into class names
  • It knows what methods are risky and monitors their use for these cases
  • Is overprotective rather than under so it may generate false positives (it can follow a variable but can’t identify logic around the variable that may already be accounting for these things). Because of that it has an interactive mode where you can review each vulnerability and tell it to ignore false positives, letting you add a note as to why it’s a false positive. The knit generates an ignore file that can be committed to your repo which you can tell your build server to use.

It also rates the confidence / severity of the issues.

Very solid tool. I’m guessing it would actually be a lot easier to build for Elixir.

6

Very cool! So yes it is something Phoenix (specifically) projects could use! Looks like a good list, looking forward to your version @griffinbyatt. :slight_smile:

1 Like
7

And here’s the initial release :slight_smile:

And this is what it looks like:

https://asciinema.org/a/c9utphy34c8remqlsvfbkjnf9

5 Likes
8

Oh that is looking really cool! Do you have the ability to mark a section of code to ignore a certain warning? Like in your screencast being able to change the avatar function to be:

  @sobelow {ignore: DirectoryTraversal}
  def avatar(...) do
     ...
  end

Like you can with Dialyzer to have it ignore certain issues?

9

Glad you think so! That’s something I’ve been considering, but it could potentially cause issues for consultants or security researchers looking at the repository. For example, if it is marked ignore but it is actually vulnerable, then an initial scan by third-parties may cause them to miss something worth reporting. Of course, it could always be triggered with a flag or something…

All that said, I’m definitely considering it! I’m just looking to see how it is used in practice before implementing these kinds of features :stuck_out_tongue:

In the mean time, there’s the less fine-grained option of:

mix sobelow -i Traversal

2 Likes