Show HN: Is it vulnerable? Drag-n-drop your Gemfile.lock to check(isitvulnerable.com)
isitvulnerable.com
Show HN: Is it vulnerable? Drag-n-drop your Gemfile.lock to check
https://isitvulnerable.com/
12 comments
Yep! We started that project alongside postmodern_mod3 about two years ago :).
We figured we could do a better job all around if we managed to productize it.
We figured we could do a better job all around if we managed to productize it.
This looks so simple but clearly a lot of work went into it. I'm learning Ruby and this is certainly going to be one of my most used tools - thanks!
Hey. We posted about our service last week and got great feedback. We took that feedback and decided to put isitvulnerable.com together to really showcase what you can get out of it / uh check your dang Gemfile.lock at least.
We're expanding platforms, so do tell us what to support next :).
We're expanding platforms, so do tell us what to support next :).
How about a subscription service? Email me as soon as my installed gems are getting vulnerable.
Hah, well, okay, I didn't expect that page to read as too subtle.
It is a service! Visit https://appcanary.com for more deets.
It is a service! Visit https://appcanary.com for more deets.
Part of it might be the link to your site is only clearly marked "we have a service" after you open a Gemfile.lock.
Gemnasium.com offers this. (as does OP, see sibling comment)
Saw the title and thought it might be you two. The site looks great! I'm surprised you found the time to put something like that together while in YCombinator.
Of course I have to suggest Python/Django, since that's what my company uses. But to maximize (number of users)x(number of security vulnerabilities), perhaps Wordpress plugins would be worth monitoring?
Of course I have to suggest Python/Django, since that's what my company uses. But to maximize (number of users)x(number of security vulnerabilities), perhaps Wordpress plugins would be worth monitoring?
I've put something together over the last weekend, tailored for django. It's still relatively early, but if you want to check it out: https://github.com/jayfk/django-updater
> Of course I have to suggest Python/Django
But do you have bugs?
But do you have bugs?
Really nice and straightforward.
Although I'm worried about the part where I'm supposed to install a service monitor on our servers. I know, many people already do stuff like that with airbrake or newrelic but I know that admins get grey hair because of that. :)
You should think about offering an API where the client can upload its Gemfile.lock on their own.
Although I'm worried about the part where I'm supposed to install a service monitor on our servers. I know, many people already do stuff like that with airbrake or newrelic but I know that admins get grey hair because of that. :)
You should think about offering an API where the client can upload its Gemfile.lock on their own.
That's the plan! We're going to be rolling that out in the next little while.
If you want to get a personal email when it comes out, put "API" in the platform field in the email form on the link above.
If you want to get a personal email when it comes out, put "API" in the platform field in the email form on the link above.
I thought that Airbrake and New Relic were supposed to support the ops team? I wouldn't want to run apps in production without them. I'm curious what admins object to?
Sending data from your server to a third party is something many people are not comfortable with.
In environments with tighter security needs, this is outright verboten.
It is true that those tools help the developers and the admins to monitor their products but where you aren't allowed to use them and have to run your own stuff, you might pay in higher maintenance costs.
In environments with tighter security needs, this is outright verboten.
It is true that those tools help the developers and the admins to monitor their products but where you aren't allowed to use them and have to run your own stuff, you might pay in higher maintenance costs.
I love how greybeards lose sleep over things perceived to be "not invented here" because there's a commercial entity behind it, but are completely fine with installing hundreds of open source tools by default that are often poorly audited because reasons.
The cases I have in mind are not because of NIH or because of greybeards' passed-down wisdom from the time when computers had to be carved out of stone.
There are places where there are heightened security requirements (for various reasons[1]). Disallowing unnecessary outbound connections is a standard practice. This results in pruning quite a lot of possible attack vectors.
[1] Of course some of those reasons are ridiculous. One place disallowed saving word documents as blobs in an Oracle database running on a Solaris server due to fear of malicious word document macros running on said server.
There are places where there are heightened security requirements (for various reasons[1]). Disallowing unnecessary outbound connections is a standard practice. This results in pruning quite a lot of possible attack vectors.
[1] Of course some of those reasons are ridiculous. One place disallowed saving word documents as blobs in an Oracle database running on a Solaris server due to fear of malicious word document macros running on said server.
This is pretty awesome, thanks! Can't wait for a GitHub integration and a badge to paste on the app readme. Seems like an excellent build check.
FWIW, The font spacing is too tight to the point of overlapping text on my browser (firefox 39, linux)
Very nice and simple. Maybe you can expose this as a public API too?
I think developers could use way better security tooling.
It seems like a lot of people would love to have an easy way to integrate this into their continuous integration services, for instance - and we're working on making that a Real Thing That Exists.
It seems like a lot of people would love to have an easy way to integrate this into their continuous integration services, for instance - and we're working on making that a Real Thing That Exists.
If you're into PHP, SensioLabs has a similar service you can use in your Composer.lock file: https://security.sensiolabs.org/check
It'll block any vulnerable version of a dependency in your project.
It'll block any vulnerable version of a dependency in your project.
Someone should reestimate severity of those "CVEs". I got 10 warnings and none of them is any severe for my app(and yours too, likely), so I'm definitely not vulnerable.
Also LOL "CSRF Vulnerability in jquery-rails" is known as not a bug at all.
Also LOL "CSRF Vulnerability in jquery-rails" is known as not a bug at all.
Wouldn't be the first time you sent us a PR, Egor :D.
But yeah, we do need to find the time to clean it up.
But yeah, we do need to find the time to clean it up.
Just don't want it to be yet another "We found 123 vulnerabilities, sign up to learn more". E.g. if it's Rails RCE it confidence should be 3/3, if some app-specific, 2/3 etc. But anyway great job
This is terrific. Easy to understand, fast, and very useful. Great job, guys!
I guess the presentation is pretty clean. But what's a gemfile.lock?
bundler.io has a very good explanation[1]:
After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked. Keep in mind that while your Gemfile lists only three gems (with varying degrees of version strictness), your application depends on dozens of gems, once you take into consideration all of the implicit requirements of the gems you depend on.
This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.
1) http://bundler.io/v1.7/rationale.html#checking-your-code-int...
After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked. Keep in mind that while your Gemfile lists only three gems (with varying degrees of version strictness), your application depends on dozens of gems, once you take into consideration all of the implicit requirements of the gems you depend on.
This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.
1) http://bundler.io/v1.7/rationale.html#checking-your-code-int...
I suspect recursive is pointing out that if you don't know what a gemfile.lock is, then the site is not useful or easy to understand.
It's a file which Ruby on Rails uses to keep track of currently used gem versions. Gems are just Ruby libraries.
So the app just runs through the list and check whether version of the gem is vulnerable or not.
So the app just runs through the list and check whether version of the gem is vulnerable or not.
It's what ruby uses to "pin" the dependencies for a project.
Rails apps use a Gemfile.lock file to "lock" an app to specific Ruby library/dependency (gems) versions.
So if somebody hacks isitvulnerable.com, they have a list of vulnerable rails sites.
We thought about this.
We don't associate any gemfiles with user information, so at best… all you could get is a list of vulnerable gemfiles, somewhere, out there :).
We don't associate any gemfiles with user information, so at best… all you could get is a list of vulnerable gemfiles, somewhere, out there :).
Novice here, but wouldn't a list of vulnerable gems be almost as valuable a target (if it doesn't already exist elsewhere)? I would imagine it is not difficult to generate a list of sites using those versions of gems that have public repos.
Please feel free to educate me if that is not at all the case though--like I said, novice, so just starting to wrap my head around security implications of things like this.
Please feel free to educate me if that is not at all the case though--like I said, novice, so just starting to wrap my head around security implications of things like this.
Not sure why you were downvoted for asking a question and trying to learn.
The information is coming from publicly available descriptions of vulnerabilities. The affected versions of gems are already enumerated. This tool is a way to make it easier for devs to compare their set of gems against the vast database of vulnerabilities.
The information is coming from publicly available descriptions of vulnerabilities. The affected versions of gems are already enumerated. This tool is a way to make it easier for devs to compare their set of gems against the vast database of vulnerabilities.
Thanks for the helpful response, this is exactly what I was wondering as I assumed there might be some publicly available info on vulnerabilities.
Is there a definitive source for keeping track of these out of curiosity? I'd consider myself an "early" programmer, so I know enough to be dangerous, but feel like there's no time like the present to start keeping track of known issues with things I might be using, even if I may not grasp the full extent of them at my level of experience.
Is there a definitive source for keeping track of these out of curiosity? I'd consider myself an "early" programmer, so I know enough to be dangerous, but feel like there's no time like the present to start keeping track of known issues with things I might be using, even if I may not grasp the full extent of them at my level of experience.
Great tool! Bookmarked.
Bug report: text here [1] is not rendering properly, but if I resize the window to be smaller it adjusts and is fine. Happens in Firefox 39.0.3 (no plugins) and Chrome 44.0.2403.130 (64-bit, no plugins) at 1000px window width on OSX Yosemite.
[1] http://i.imgur.com/rgQqli8.png
Bug report: text here [1] is not rendering properly, but if I resize the window to be smaller it adjusts and is fine. Happens in Firefox 39.0.3 (no plugins) and Chrome 44.0.2403.130 (64-bit, no plugins) at 1000px window width on OSX Yosemite.
[1] http://i.imgur.com/rgQqli8.png
Ditto, with Fx 39.0 and uBlock Origin, 1920px, also Yosemite.
Oh no! I'll have to take a look at it. Thanks!
Looks great. Your formatting on the result page is messed up in my browser (chrome on osx). You can see a screen shot here...
https://annotate.driftt.com/view?i=99nffsejxeiittq%2F2015-08...
https://annotate.driftt.com/view?i=99nffsejxeiittq%2F2015-08...
.png%2F){kind=link}
Thanks for the report, we're on it.
[deleted]
I'd like to know if there is something similar for Python, or something like https://github.com/rubysec/ruby-advisory-db for Python.
THANK YOU!
I think this is really awesome...
...I have to go update a few projects right now.
I think this is really awesome...
...I have to go update a few projects right now.
This is awesome, great idea! I see the sign-up for additional platforms. Thinking of supporting package.json and bower files?
>Thinking of supporting package.json and bower files?
Definitely! We're building a service to monitor your app and server's dependencies, and we currently support Ubuntu and Ruby.
Our goal is to cover basically all of open source :).
Definitely! We're building a service to monitor your app and server's dependencies, and we currently support Ubuntu and Ruby.
Our goal is to cover basically all of open source :).
Checking the git history, I see that phillmv is a contributor to ruby-advisory-db.
https://github.com/rubysec/bundler-audit
https://github.com/rubysec/ruby-advisory-db