He understands that. Like me (we've trained him well!), he does not have particularly great faith in the insulating powers of the words "development environment".
At a minimum, after running this you are one Twitter shortened link away from losing your development machine. The link will probably show you a cute cat picture just like any other one. You'll only find out you lost the machine later.
At worst, you're one of the 80% of companies that keeps development machines in your data center protected by a firewall/VPN. Now you're a cute cat picture away from attackers with direct TCP access to your database servers. Wee!
I've read through the rest of this thread, and I'm still not understanding the big deal about this tool.
If the entire dev environment is my macbook, and the app is localhost:3000, and the line to enable this thing exists only in the development environment initializer, and I leave it commented out all the time except for those rare cases where I want to inspect session variables and controller state or some other thing that can't really be done in irb, then what's the risk?
At least, that's how I would use it...
EDIT: Nevermind, patio11 explained it much better in his response above. I still think this could be a useful tool with CSRF protection.
There used to be web-based Rails debuggers, didn't there? I haven't used any kind of Ruby debugger since 2007. I just keep an SSH screen with "bundle exec rails console" running. I'm of the impression that this is what most people do.
So what's the win here?
Even with CSRF protection, you still have to worry about who can talk to port 3000 on your machine. There's a "rails server" running on my Macbook pretty much every day. I bought a whole separate Macbook because I was worried about the attack surface that Rails runs with by default. Adding a remote shell to the mix doesn't seem like a win.
> There used to be web-based Rails debuggers, didn't there?
I'm not sure.. This is the first one that I've ever heard of. Well, remote debugging has been around for years for plenty of platforms, and this is the first remote debugging tool for Ruby that I have seen, and embedding it into Rack is kind of cool and useful. And sure, probably not very secure in version 0.0.5.
That doesn't mean "All remote debugging is bad and insecure, and you're stupid for even considering this," which sadly is the tone that people are taking. I can think of several ways that this thing could be made more secure. The gem initializer could take a private key, and the backtick command could prompt you to enter the public key, rather than just dropping you right into a console and executing your arbitrary code.
> So what's the win here?
Yes, normally I would just ssh to the remote machine and and "bundle exec rails console" too. OR far more likely, there is no remote machine, I just open another terminal window and keep a console running. (sorry I said "irb", though I meant "rails console" -- In my mind they are basically the same thing).
The win (at least, to me) is that I can inspect parts of the rails stack that change as the user (me) is interacting with the app, such as request details, session contents, controller variables.
>I just keep an SSH screen with "bundle exec rails console" running. I'm of the impression that this is what most people do.
>I bought a whole separate Macbook because I was worried about the attack surface that Rails runs with by default.
This seems a bit incongruous, don't you think? I'm not trying to pick a fight, but I read stuff like this and I just feel sad...
after running this you are one Twitter shortened link away from losing your development machine
Who runs an internet-accessible development machine? Maybe I give the rest of the dev world too much credit.
you're one of the 80% of companies that keeps development machines in your data center protected by a firewall/VPN
I've been in Dev/Ops for about 20 years, and been working the internet since the web took off in '94. I have never, ever heard of such a thing, and would freak out if I did. 80% of companies? Maybe you've got stats to back this up, and my experience is merely anecdotal -- but I've never heard of a single instance of something so obviously stupid. SQL injection vulnerability, sure. XSRF, XSS vulnerability, sure. Running a database server on the same host as your app server, with the webserver running as the DBA user? Sure, it happens.
Certainly someone is bound to misuse this gem as well. But that doesn't mean it's "a very bad idea". It's a very good idea. It's just that it takes knowledge and experience to run a web site, and some people have to find out the hard way.
Everybody runs development machines that can (a) be spoken to by machines with human-driven browsers and (b) can speak to other machines.
You're a dev/ops guy, I'm an appsec security assessor. I think we just look for different things. Trust me, this isn't just common it's standard practice.
It's a clever bad idea. Minimal payoff. Maximum risk.
Incidentally: I'm not sure I'm in love with this "everyone has to find out the hard way" notion. No, they don't. We can just tell them: DON'T RUN STUFF LIKE THIS, IT WILL HURT YOU. You have 20+ years of experience. Most people on HN do not; they see this, think "ooo, shiny", and install it. As a practitioner yourself, you have a responsibility --- in fact, if you're keeping that CISSP cert current, an obligation --- to step in and help that not happen.
Who runs an internet-accessible development machine? Maybe I give the rest of the dev world too much credit.
I apologize for not having an underground cold war bunker with which to develop my software on. Until i get one, I'll stick with my one and only machine (which, as you can tell, has internet access) for doing development.
EDIT: And because of it, i'd never put this code on a machine i run.
Most professional shops do indeed have dev machines. They live at Rackspace alongside the prod servers. They are protected from the Internet by firewall rules; you need a VPN connection to access them. Unfortunately, everyone who writes code has that VPN connection accessible at all times, because that's their job, and so rack-webconsole puts them a cute cat picture away from giving an anonymous Twitter user access to their data center.
It doesn't need to be internet enabled, that's the point. As long as I can guess the URL you are using for your development machine and have you click on a link on your laptop one can make this work (in the bad sense of the word).
You're a dev/ops guy, I'm an appsec security assessor. I think we just look for different things. Trust me, this isn't just common it's standard practice.
Actually I'm a CISSP and was CISO for a major financial web site for >5 years. I look at things the way you do, trust me.
It's just that I try to temper my security reflexes. Just because something might be potentially dangerous doesn't means it's automatically a bad idea.
Everybody runs development machines that can (a) be spoken to by machines with human-driven browsers and (b) can speak to other machines.
Indeed we do. And if you can't trust that environment to be private and secure, then you've got bigger problems than a web console. I wouldn't stop at shutting down SSH; I'd disconnect entirely. Hell, I'd quit.
If your dev environment is exposed to people who are malicious, you're screwed. Web console is not going to hurt you, because it's too late -- you've already been hacked.
I think you're contemplating the attack vectors from the wrong direction. We're not necessarily talking machines with open ports on internet facing IP addresses. Think about it from the other direction.
The root of the problem lies at the feet of a few factors:
A) HTTP is a relatively "trusted" protocol, which means you should be very, very careful about running local services over HTTP (on any port) that can do bad things™ to your computer.
B) http://localhost:3000/ isn't difficult to guess. If you know someone is a Rails developer, there is a good chance that embedding requests to that URL will hit a Rails dev environment at some point, and that's where this thing is going to end up running.
C) Eval, in general, is just about the right length of rope to hang yourself with. Use sparingly and with great respect for its ability to completely hose you. Passing anything sent as HTTP params to eval is just asking for it.
Knowing the above, consider an example like Patrick (patio11) outlines above.
Let's say this takes off and people start using it. This means that some percentage of Rails devs have this running. To attack their machines, I need only to trick their machine in to making a request to 'http://localhost:3000/malicious-string-here.
How might I accomplish that? I like Patrick's suggestion of an img tag src attribute. There are plenty of forums that treat img tags as safe, or provide some means of embedding images with arbitrary src attributes.
So let's say I head over to railsnewbforum.com and embed the malicious image in my sig. Then I start happily posting useful information in every thread on the board. Assuming this webconsole takes off, how long until a vulnerable dev hits a page with my malicious signature code and gets pwnd?
Can this be made safe? Probably to some degree, but then it would involve many of the security measures involved with using the Rails console over an ssh session or something similar.
At a minimum, after running this you are one Twitter shortened link away from losing your development machine. The link will probably show you a cute cat picture just like any other one. You'll only find out you lost the machine later.
At worst, you're one of the 80% of companies that keeps development machines in your data center protected by a firewall/VPN. Now you're a cute cat picture away from attackers with direct TCP access to your database servers. Wee!