For those following along at home, you know that we love to work iteratively, and as such, work towards our big-picture goals one small step at a time. We also take software quality seriously, and an important part of software quality, particularly when it comes to web applictations, is security. We’ve begun to develop a new process to address security in our applications. In the process we also want to contribute back to the community where we can because it will make the entire web ecosystem that much better. After the break we’ll talk about our high-level process and how we implement it.

Our Process

At Highgroove we take application security very seriously. The good news is that Ruby on Rails helps developers write secure applications if we simply follow the well documented best-practices in the field. As a side effect it is very difficult to introduce the majority of security vulnerabilities that plague other platforms and frameworks. There are trade-offs of course, and as applications become more sophisticated the more powerful the tools that are brought to bear on the problem. With that sophistication comes the potential for security issues of great subtlety to creep in. To prevent this we perform security audits each iteration to catch such subtleties before they are put into production.

As a general overview, we audit the most common vectors for attack on a Rails application:

1. We start by using the excellent Brakeman scanner to give us a general overview of the state of the application. We use this scan to determine any hotspots to analyze. We really like Brakeman, have given a tech talk about it, and contribute as often as we can!

2. Audit the use of model attributes for mass-assignment vulnerabilities, even when attr_protected and attr_accessible are in place to prevent mistakes in granting too much access in a given white or blacklisting effort.

3. Audit the use of scopes and database access throughout the application to prevent SQL Injection.

4. Audit authorization and authentication controls used through the application.

5. Audit sessions for their use within the app to prevent user manipulation or attacker compromise.

6. Audit any extra-database storage mechanisms, such as S3, used throughout the application for potential data leaks or incorrect permissions.

7. Report all findings in an open format such that the customer(s) and developer(s) see and understand the report. This way they can integrate the process of fixing any vulnerabilities in their standard agile workflow. So far we’ve had good luck with creating Github issues with the report as a dialog can be opened addressing the given points. We can also deliver in other ways if the customer would prefer.

8. If any issues are found in either our audit tools, or gems we audit in the above process we either create patches and pull-requests within github, or if we cannot quickly do so, or need the original developer or maintainer’s input, a bug-report (usually in the form of Github issues) in an effort to contribute back to the community.

Our process is constantly evolving based upon our own understanding of the attack space, and with the evolution of tools, both offensive and defensive. As a side effect please fork our process on not-so-secret-sauce and contribute your techniques so we can all get better. If “software is hard”, then security definitely is.

What techniques and tools do you roll into your workflow to help ensure the security of your customers and their data?

Image credit: m thierry