We’ve been working round-the-clock to implement some improvements that our customers suggested. The most significant ones are full Ruby support (not just Rails repositories) and free service for open source projects. Potentially, the latter one is huge and I think we just scratched the surface of what it can turn into.
We are working on a couple of big features that are going to be revealed in the next couple of weeks. Here is a sneak peak of one of them:
I am personally very excited to see security metrics that projects are being tested against. Hakiri is going to become much less of a black box and reveal its background mechanisms in a more transparent way.
Stay tuned for a bigger announcement in a couple of weeks!
Two days ago we launched an experiment called Facets. It’s a free
Gemfile.lock scanning tool that reveals CVE vulnerabilities in gems. It uses Hakiri DB and technologies in the background.
Facets turned out to be quite a success: a lot of upvotes on Reddit and a position in the featured section of Ruby Weekly. More importantly, people scanned their gemfiles more than 1000 times. I think it’s really great.
My goal with Hakiri is to make security monitoring simple and effective. I think Facets proves that it’s possible and that people are generally interested in making their products more secure.
So, what’s next? I think it would be interesting to analyze all the data that we received from multiple gemfile scans and make some sense out of it. Expect a report in this blog with some cool stats in the next couple of weeks.
Thanks for using Facets!
Web security is hard. There are so many little things that developers have to keep track of and remember. Take login forms, for example: they are an initial point of entry in almost any web app and are exposed not just to individuals but also to scripts and web crawlers. It means that login forms can be exploited automatically.
So, what can go wrong? For starters, an attacker can write a brute force script that will try millions of login and password combinations in a very short period of time, eventually hacking into some user accounts.
What if you have basic account locking implemented that some authentication libraries, like Devise, offer out of the box? The attacker can still cause havoc by attempting to connect to multiple accounts N times, where N is the number of attempts after which an account gets locked. Imagine a script that tries to login to your app with millions of stolen email addresses. After a while many users will be locked out of their accounts. Not a great experience especially if the script is looped.
In this article I am going to address those issues and show how to implement a CAPTCHA-protected lockable login form with Rails 4 and Devise 3.
I am super excited to announce new changes in Hakiri that make Rails security monitoring even smoother than before.
Hakiri already had some rudimentary GitHub integration in the previous versions that allowed developers to hook up repos and monitor their code. Now integration became even more tight.
First of all, we’ve added GitHub authentication that makes it really easy to login to Hakiri with a GitHub account. It also provides a much simpler initial integration: just choose repos and branches you’d like to monitor in a couple of clicks.
Secondly, Hakiri does a lot more on each GitHub push. Not only do we scan your code for vulnerabilities, but also parse
Gemfile.lock for all of your gem and Rails versions. After the scan is done, all of these versions are added to the latest build and vulnerability notifications are sent out. And remember, all of this requires just a few clicks! No more complicated setups, unless you want to monitor your server technologies (and even then it’s not that complicated ;) ).
2013 was a great year! I launched Hakiri and made some significant progress with it while getting a lot of early adopters on board and solving real problems for organizations.
Next year I want to focus on refining and making Hakiri more elegant and simple. My ultimate goal is to have a go-to Rails/Ruby security web service that can start delivering value to developers after just a couple of clicks.
There are a lot of big milestones ahead. I am excited!
Happy New Year!
Surprise, new Rails vulnerabilities!
It’s that time of the year again! A handful of Rails vulnerabilities was just published by Aaron Patterson last night. It’s time to upgrade Rails as soon as possible.
The latest versions to upgrade to are: 4.0.2 and 3.2.16. You can read more about them in the official Rails blog.
Folks from the National Vulnerability Database haven’t assigned any impact scores to these yet. However, all of these vulnerabilities look pretty severe. Stay safe!
Did you learn about these vulnerabilities from a blog post or your Twitter feed? Sign up with Hakiri and get security updates for your specific versions of Rails via email. We also support a whole bunch of other technologies (such as Apache, Unicorn, Postgres, etc.) and gems.
Remember January 2013? A major vulnerability was found in Rails and the whole community got riled up: blog posts, rushed security audits, impromptu email alerts… No one really expected it in the Rails world because Rails was considered so “secure.” Then a new disaster came: RubyGems—the heart of any Ruby project—was compromised; several companies started to consider migrating their projects to Python or Java. This was clearly a serious problem.
What happened after that? Developers talked about security for a couple more months, updated some technologies, kept their ears to the ground for a bit and… became indifferent about security after a while, which is a surprisingly common attitude. I should clarify that by “developers” I mean freelancers, consultants, and startup/small company engineers. Larger companies have their own sophisticated security processes that are not always optimal, but that’s a topic for a different post.
It’s official: Hakiri is out of beta and ready for production apps! I’ve walked a long path before coming to this point. Originally, I conceived the idea in January 2013 right after several serious vulnerabilities were found in Rails. I toyed with the concept of a dynamic CVE monitor for a bit and by the end of April had a robust script that notified me whenever new vulnerabilities were discovered for my stack. It was quite helpful for the project I was working on back then.
The second part of the journey began when I decided to make the script public and turn it into a web app with many more capabilities that enhance security of Ruby on Rails apps. By early August I had a working prototype that several people tried out and really liked. It gave me confidence that I was on the way to something great.
The wait is finally over and I am ready to share Hakiri with the rest of the Rails world.
I believe that security is part of quality, in exactly the same way as performance, reusability, scalability, and the like. What you don’t engineer in now will cost you later. Too many developers can’t answer a simple question: are your Rails apps secure? It’s really scary stuff. My mission is to help make the web a safer place through exploitation prevention.
I am always there for you if you need any help with Hakiri: firstname.lastname@example.org.