DEV Community: Andreas Tiefenthaler

Awesome Ruby Security Resources

Andreas Tiefenthaler — Mon, 05 Nov 2018 22:09:38 +0000

A New, Curated List of Ruby-related Security Resources:

https://github.com/pxlpnk/awesome-ruby-security

I just started out collecting them in one place, so it is far from complete or perfect. Everyone is invited to help out and submit more useful links so we all can build secure apps.

Also, make sure to check out the node.js list we have been working already: https://github.com/lirantal/awesome-nodejs-security

dev.to Show us your octocat alter ego

Andreas Tiefenthaler — Thu, 18 Oct 2018 07:25:13 +0000

GitHub released an octocat builder. I was waiting for this for many years and I am super excited.

I am curious how dev.to would look like if we all where octocats.

This is me as an octocat

Please post yours in the comments.

What security updates should one follow?

Andreas Tiefenthaler — Tue, 16 Oct 2018 12:05:39 +0000

I am trying to figure out what RSS feeds, mailing lists, twitter accounts, blogs, etc one should follow to get good updates on security issues and vulnerabilities.

Any framework, language or platform is good.
I am currently following:

NodeJS Security: https://groups.google.com/forum/#!forum/nodejs-sec
Wired security: https://www.wired.com//category/security/
AWS security bulletins(quite a lot and noisy): https://aws.amazon.com/security/security-bulletins/

What are you following, and why?

Maybe we can get a nice list going that helps a bigger audience.

Securing your Ruby and Rails Codebase

Andreas Tiefenthaler — Mon, 24 Sep 2018 08:09:55 +0000

When writing software you want to avoid introducing functional bugs or security issues.

For functional bugs, we usually write unit tests and try to cover edge cases. Integration tests then make sure that things work together.

In this article, we will walk through how we can secure a Ruby, Rails, or Rack-based app.

No matter if it is a new codebase, or we are adding it to a 10-year-old project, in the end we will have a decent level of security testing.

For this article we will be using open-source software tools to secure our codebase. We will also consider some hosted and already configured alternatives.

Our toolbox:

bundler-audit
brakeman
rubocop (has some security rules)

The tools can be categorized into Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools.

Static analysis scans your codebase and looks for certain kinds of patterns. It will not execute your code and cannot detect problems in generated code, or at runtime.

The results will usually show the line of code the issue is detected. They will also alert you to the type of issue identified (with a severity), and sometimes an advisory on how to fix the problem.

In contrast, software composition analysis will check the dependencies you are using for vulnerabilities.

The report usually includes:

The package name of the affected dependency.
Severity on how bad it is. This usually spans from none to critical.
The next safe version to upgrade to.
Some more references that explain what the problem is and more details.
In some cases an identifier that leads to a vulnerability database.

To run the security tools, you do not need a CI pipeline but it is generally recommended to have one in place.

We will install the tools in a ruby/rails project. You will also learn how to enable the rake tasks and run them.

All the tools also have normal executables and can be used one by one, or in a shell script.

Bundler Audit

Bundler Audit will detect vulnerable dependencies in your codebase

First, add the bundler-audit gem to your Gemfile:

gem 'bundler-audit'

and install your bundle.

Now you can run a

bundle audit check --update

This will update the local database first, and then check your project for vulnerable dependencies.

Keep in mind that bundle audit does not update the dependencies automatically. I recommend you to always update them before each run to ensure you get the best and most up-to-date results.

To enable the rake tasks, add the following to your project Rakefile:

require 'bundler/audit/task'
Bundler::Audit::Task.new

A rake bundle:audit will now update the data and perform the checks.

If you found any vulnerabilities at this point do not freak out. You can look into fixing them by updating the version to the next safe one.

In case you can not update, you can use the --ignore $vulnerability-id to suppress it for now.

For example:

bundle audit check --update --ignore OSVDB-108664

The output looks something like this:

$ bundle audit check --update

Updating ruby-advisory-db ...
From https://github.com/rubysec/ruby-advisory-db
 * branch            master     -> FETCH_HEAD
Already up to date.
Updated ruby-advisory-db
ruby-advisory-db: 322 advisories
Name: omniauth-oauth2
Version: 1.0.2
Advisory: CVE-2012-6134
Criticality: High
URL: http://www.osvdb.org/show/osvdb/90264
Title: Ruby on Rails omniauth-oauth2 Gem CSRF vulnerability
Solution: upgrade to >= 1.1.1

Name: rubyzip
Version: 1.2.1
Advisory: CVE-2018-1000544
Criticality: Unknown
URL: https://github.com/rubyzip/rubyzip/issues/369
Title: Directory Traversal in rubyzip
Solution: upgrade to >= 1.2.2

Vulnerabilities found!

Brakeman

Next, we will add Brakeman as our first static code analysis tool.
Brakeman will look for known insecure patterns and configurations in your code base. It will also check if you are using a known vulnerable rails version.

Brakeman works not only for Rails, but it also covers Sinatra and any kind of rack application.

First, add the dependency to your Gemfile:

gem brakeman

and install it:

bundle install

Then you can run it for the first time in your rails root directory.

brakeman

This will invoke Brakeman and output some lengthy report. Here is a gist with a sample report: https://gist.github.com/pxlpnk/4a829b6101abe5fc0102d358d8dd028d

If your app is safe and you get no findings run it, first of all good job!

But then you want to see how it looks like, so you can try it with OWASP/RailsGoat.

If you run Brakeman for the first time on any older Rails application you might get a lot of findings.

To make things easier, you want to start with more severe issues and work down to the less critical ones.

To do so, use brakeman -w3 and it will show only high, -w2 will show high and medium, -w1 will show all other findings.

Approaching it level-by-level usually works the best and is the most efficient.

If you plan to use rake, you can install the RakeTask very easily.

Running a

brakeman --rake

will create a task file in lib/tasks/brakeman.rake which can be run with:

rake brakeman:run

To customize it and use more advanced options see the documentation brakeman as a library/.

RuboCop

While rubocop is known as a linter and formatter, it comes with some security rules and can be extended with some community extensions.

Let us get started with installing RuboCop first. Add the following to your Gemfile:

gem 'rubocop', require: false

Then run our old friend

bundle install

Once this has finished, you can execute the rubocop command.

If you have not used rubocop before you might see a lot of output and warnings printed out in your terminal.

For this post, we are not so much interested in the linting and formatting rules. Instead we make sure we only run the security relevant rules.

We will be using the following .rubocop.yml configuration to start out.

AllCops:
  DisabledByDefault: true

Security/Eval:
  Enabled: true
Security/JSONLoad:
  Enabled: true
Security/MarshalLoad:
  Enabled: true
Security/Open:
  Enabled: true
Security/YAMLLoad:
  Enabled: true
Bundler/InsecureProtocolSource:
  Enabled: true
Rails/OutputSafety:
  Enabled: true

We are disabling all the style and linting rules, and enabling only security-relevant ones. This is only done for simplicity in this blog post.

Running the rubocop command now should be way less noisy.

This is how it looks like on the RailsGoat repository:

 $ bundlex exec rubocop
Inspecting 121 files
............C....................
Offenses:

app/controllers/password_resets_controller.rb:6:20: C: Security/MarshalLoad: Avoid using Marshal.load.
    user = Marshal.load(Base64.decode64(params[:user])) unless params[:user].nil?
                   ^^^^

121 files inspected, 1 offense detected

Not too impressive yet, but we are getting some relevant security info already.

Now we will add some more security rules.

Add the following to your Gemfile: gem 'rubocop-gitlab-security' and run bundle install again.

Now add the following to the configuration file rubycop.yml:

GitlabSecurity/DeepMunge:
  Enabled: true
GitlabSecurity/JsonSerialization:
  Enabled: true
GitlabSecurity/RedirectToParamsUpdate:
  Enabled: true
GitlabSecurity/SendFileParams:
  Enabled: true
GitlabSecurity/SqlInjection:
  Enabled: true
GitlabSecurity/SystemCommandInjection:
  Enabled: true

Those curated rules by the GitLab team add tremendous value to our security setup.

Now we need to require the new modules when running RuboCop:

Either by running:

 bundle exec rubocop --require rubocop-gitlab-security

or add this to the rubocop.yml:

require: rubocop-gitlab-security

We can now find more security problems in the RailsGoat repository. Here is a gist with a sample report:https://gist.github.com/pxlpnk/958c500aab22f90b54918d6d9573251d

To configure the RakeTasks add:

require 'rubocop/rake_task'
RuboCop::RakeTask.new do |task|
  task.requires << 'rubocop-gitlab-security'
end

to your RakeFile and run it: rake rubocop

Fixing Findings

To not drown in findings I recommend you configure and enable one scanner at a time.

Start with high severity findings and filter out the rest.

Some of the results will be false positives or are no danger at all for various reasons. They can usually be ignored and added to a list to not be noisy.

Once you have fixed or muted the findings and it behaves as you would like, move on to the next one.

When you have reached the point that you feel happy and comfortable with your setup, enable these tools to fail your CI builds and run them on every code change you commit.

Now you will always know when something is not up to your security standards.

Hosted Services and Other Alternatives

In addition to the open source tools that are available, there are also a set of commercially available tools.

GuardRails runs all the tools from this article. The service will post a comment on your GitHub pull request when they detect something. It is a zero-configuration security tool that does a bunch of heavy lifting for you and filters out all the false positives.

You also have companies like Snyk that focus only on your dependencies, and will alert you when they detect new vulnerabilities. GitHub and GitLab also provide this as part of their offerings.

Open Source Security Tools are Great

The ruby community has put massive effort into creating those tools. They are free for everyone to use and should be supported!

If you can afford it, send them some money or other support so they can continue and improve the tools in the future.

How do you secure your codebase? Let me know at andy@occamslabs.com.

TIL#2: patches in GitHub gists and reasons why jekyll won't generate my pages

Andreas Tiefenthaler — Mon, 24 Sep 2018 00:00:00 +0000

Patchfiles Syntax highlighting in GitHub gists

Someone sent me gist today with a patchfile in it. To my delight, I noticed that they are highlighting the changes nicely.This improves the readability of a patch tremendously.Check out this patchfile: https://gist.github.com/pxlpnk/357a32e789b63d5d809a40d886bc9337

It is important that the filename ends in .patch.

Jekyll and future dates

This morning I spent around 15 minutes trying to figure out why a post using jekyll would not show up.Some furious google searching resulted in a case of This makes a lot of sense, but why?

It turns out, that jekyll will not generate anything that has the date set to a future time.In my case, the date was set for today, but one hour into the future.

Here is what I learned on why it might not generate posts:

The post is not placed in the _posts directory.
The post has an incorrect title. Posts should be named YEAR-MONTH-DAY-title.MARKUP (Note the MARKUP extension, which is usually .md or .markdown)
The post's date is in the future. You can make the post visible by setting future: true in _config.yml (documentation)
The post has published: false in its front matter. Set it to true.

Big thank you to StackOverflow and their users for helping me out one more time: https://stackoverflow.com/questions/30625044/jekyll-post-not-generated

TIL#1: Working efficiently with GitHub Apps and using jekyll-compose

Andreas Tiefenthaler — Fri, 21 Sep 2018 00:00:00 +0000

I want to document more what I have been learning throughout my days. Even as someone who writes code for 10+ years there are many new things every day that we stumble uppon.

I want to share some of those with the great dev.to community.

Here we go, two rather unrelated things:

GitHub Apps

Working with GitHub apps can be cumbersome. You have to set up a local tunnel and trigger the outgoing events using their user interface. Even though some tunnelling provider (is this a term?) allow you to replay it through their interface it can be tricky.

Today I learned that every GitHub app has a log with the full outgoing requests. Those requests include headers and body.

The request are found in your app settings under the advanced tab.

Now I can replay things with curl and no tunnelling setup from a local file.

curl -X POST "Content-Type: application/json" -d "@githubwebhookpayload.json" 'http://localhost:8080/webhook'

jekyll-compose

If you run a static website powered by jekyll jekyll-compose makes your life easier. Work on blog posts and pages becomes more natural as you handle the drafts away from your actual posts.

Create a new draft:

$ bundle exec jekyll draft "Today I Learned #1"

This will create a new file in the _drafts folder. Once you finished writing and editing you publish the draft:

$ bundle exec jekyll publish _drafts/today-i-learned-1.md
Draft _drafts/today-i-learned-1.md was moved to _posts/2018-09-21-today-i-learned-1.md

That's it for today, keep on learning new things every day. 🤓

You have an idea how to make this better? Let me know: hello@an-ti.eu

The Agile and the Beast

Andreas Tiefenthaler — Tue, 24 Apr 2018 00:00:00 +0000

Most security analysts have the same mindset, they want to reduce and avoid risk at any cost. They think in attack vectors, vulnerabilities, access rights and how to minimize the threat.

The security team is a nag.

They won't allow us to ship it like this.

Why is the security team always saying no?

This works perfectly fine in a development process where the waterfall model.
There the security analyst can take care of risk, plan accordingly and in the end have a penetration test and assessment to ensure everything is done in a secure way.
But then agile, scrum and sprints start to happen.
The code is released faster to production, from many months for a release too many releases within a month.

The process becomes faster, the company starts living and breathing agile, the security analysts and security engineers start to rotate and losing the grip on their perfectly secured applications and processes.

The Panic

Everything goes so fast, the development teams release 3 new features and a selection of bug fixes during the two-week penetration test.
Two findings that where reported are fixed by accident in the meanwhile. What is the report worth now?
How can the security analyst even do their job in this environment and protect the assets?

Times have changed my friend, next the analyst falls into a crisis and a breakup phase.
The 5 stages of grief:

denial:
They won't be doing this forever, once the product is released and stable they will go back to the old way.

Most likely not, and they will be striving for even faster releases.

anger:
Why are they not following my processes, they are mandatory and there to ensure the safety.

They also slow down the developers, reduce velocity and give chance to the competitors.

bargaining:
If you follow my processes, I make them a bit easier and say less no to you.

They are already faster than you, you would enter their world at a stage when they already shipped and moved on to the next thing.

depression:
I can't do my job, everyone is working against me, I am always too slow and they won't fix my vulnerabilities I put into their backlog.

This is the time where the analyst should either consider looking for alternative employment options or start un-learning and re-learning what they already know.

acceptance:
The dev team won't change what they are doing, and the rest of the company is on the agile train as well. What can I do?

The Relief

This is the point where the security analysts and teams can start being part of enabling the business to strife, and turn from a nag and no-sayer to an enabler.
But how does one approach this? Everyone is talking about shifting to the left.

There are two obvious starting points, technology, and people. While many would start putting effort into the technology first, they should go and talk to the people.
Put some technology into the development lifecycle, add some code analysis into the build pipeline and make sure nobody can release until the security checks are all passing.
Going this route, will result in frustrated developers that can not make their goals anymore and hit tricky roadblocks set up by the security team (Why do I have to update a database dependency when I am just fixing a frontend bug?).
At this point shortcuts will be taken, technology removed, people might even leave the company.

The nag is back.

People First

In order to do make sustainable changes, the people who work on the codebase, the infrastructure, and the product come first.
The analyst needs to start talking to people and understand what is important to them.
What their goals are and how they are planning to achieve them.
It is crucial to understand the tools they are currently using.
Once the analyst understands the priorities and the used tools, they can get to work and start introducing security features and tooling.
The easiest approach here is to start enabling some security features as warnings on the existing tools.
Make sure that they don't break the build, but people are getting notified.
Define some achievable shared goals with the engineering team, and achieve them in collaboration with them.

Gradually enable more checks as the goals are achieved, and consider what tools would support the teams to deliver value in a secure manner.

Do you have some ideas, critique or want to share your story with me, you can reach me at hello@occamslabs.com

Originally published at www.occamslabs.com.