Rack-webconsole: a Ruby/Rails console inside your browser

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.

IMO, it's not worth the risk.

I have preconceived ideas but I am not a security specialist by profession and hence the question. Perhaps you can explain instead of a downvote?

Thanks Mentat. Yup, I understand CSRF and current methods such as tokenization, double submit cookies, etc. I was trying to get an explanation from tptacek or patio11 about their statements about unprotected shells and arbitrary code.

The most voted comment is from patio11 about it being a very bad idea. A lot of discussion and hand-waving happened before finally CRSF was even mentioned. Once the author implemented a CSRF fix, the conversation seemed to quiet down. So is this kind of web-based access on the road to being safe and usable now? Many popular VPS hosts offer out-of-band access through web-based consoles such as Anyterm and Ajaxterm. Are those acceptable simply because they've taken care of the CSRF, XSS common issues? They allow arbitrary code on the remote boxes so how are they different from a security concern? I have no idea so I just threw out SSL even though it probably makes no bit of difference. I simply don't have the background or experience to know. Is it time to be concerned about how proficient the hosts are in securing their hypervisors and bridged networking for guests? If they do pose a concern, then why is there not more brouhaha about it to get some attention on the matter? Linode and Slicehost have a lot of customers...

To just say it is a bad idea and move on and not mention other implementations seems to leave a bad taste. Someone also asked about Werkzeug(of the Python demesne) as well...

The idea is that any sort of web console (that can be attacked with CSRF) is a really bad idea as it likely results in a complete compromise. Most web developers are not at all good at web security (case in point being this release with easy CSRF vulnerabilities). The likelihood that the same or similar mistakes will be introduced again later is high. The conservative approach is that, because the consequences of a failure are really bad, and because the level of convenience beyond an ssh shell is marginal, therefore you should never use web consoles. I guess if you were an expert at web security you could analyze a particular web console and say "yeah, it looks ok to me and I'm willing to take the risk." I think Patrick is saying that he doesn't see that being a worthwhile tradeoff for himself (as an expert) and therefore it seems particularly unwise for non-experts to be doing it.

There is some buzz about doing cloud to cloud attacks but I haven't heard anything that's been realized yet. I have also heard that there are issues with data staying resident on local disks on EC2 after machine termination, but I don't know if that's the case.