Hacker News Reader

Comment by jiggy2011 | Hacker News Reader

jiggy2011

How do you guys who are freelancers or perhaps you work for a company and are the only guy working on a particular app handle security stuff like this?

A lot of what I hear is "drop what you are doing and patch this right now!". But of course there are many reasons why this might not be possible. For example you might be on a 15 hour flight with no internet, you might be dealing with some family crisis, you might be in the middle of a coke and sex binge with identical twins who look like Scarlett Johansen or whatever.

Do you live glued to your smartphone in constant fear of 0 days? Do you make sure there is some third party available to deal with this stuff? do you design with the possibility of having your app/site owned as a likely event?

And how do you make your client/employer aware of the implications of stuff like this?

View on HN

I was living in hospital with my wife having a baby when the last one hit and, yep, I did it all tethered over a phone. First time I've done work in a room while someone was getting set up for a blood transfusion ;-)

If you can drop everything you're doing and patch your system the moment a patch is available, that's great! Do that. For most of us, it'll probably be the next morning or next workday when you would take care of a security patch.

Is this something you put into contracts with clients (assuming you are doing client work)?

I'm curious about how people do security SLAs or whatever.

Our main client has one security agreement in place - anything but Ruby on Fails please! They seem quite happy with Python so far.

Doesn't seem like that solves the fundamental problem though. You could have django issues or whatever just down the pipe. Or issues lower down the stack.

Let's compare the track record of Django and Rails:

http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...

http://www.cvedetails.com/product/18211/Djangoproject-Django...

So far zero remote code execution and zero SQL injection vulnerabilities in Django.

That's not the point.

Given the axiom, "public facing applications that accept user input and execute code based on that input can sometimes be made to execute code that is not desired" and such a system serves some business function perhaps including storing customer data.

If you are responsible for such a system, how do you manage that risk in a realistic way? Minimising it by choosing a particular technology is only one dimension of security.

Incident response strategies, legal mitigation etc are important here also.

It seems that you either require a person with computer & internet access available at all times to patch at a moments notice or you need to devise a strategy so that having a web server compromised is not an apocalyptic event.

Still more DOS, Directory traversal and CSRF vulnerabilities.

The philosophy and nature of the features Rails provides are what causes these security vulnerabilities. Auto-magic features are prone to this sort of exploitation.

We actually moved off Ruby/Rails because of all this, but previously it was a test in QA, then patch Prod, both on same day of the word hitting the street that there was yet another hole to close

What are you going to do when whatever you're currently using has a security problem?

Moving off Rails is not a panacea

It doesn't have to be a panacea, it just has to significantly reduce the risk of being exploited (whether due to superior design philosophy, superior execution of that design philosophy, or simply 'security by low market share').

If the security of your platform depends on that platform not become a popular target of hacker attention then sometimes it really is as simple as "I don't need to outrun the bear; I just need to outrun you"

This is an odd way to think. What happens if you start on a niche platform and it gets popular, do you switch?

Just because a platform is small doesn't mean somebody isn't going to try and bust it and when they do the small project may not have the resources to push out a robust fix quickly.

I'm not parent, but the claim wasn't that popular implies vulnerable. Just that some projects ignore security while the stakes are low, which comes back to bite them in the backside once adopters pick up (e.g. what we're witnessing with Rails now).

...which is often the right choice, because projects that pay attention to security from the get-go often lose out in the marketplace to ones who pay attention to other, more important factors. There's an opportunity cost to everything, and for many apps, security is not as important as convenience, ease-of-use, performance, or features.

Witness Dropbox vs. TarSnap. Dropbox has had multiple serious security vulnerabilities published. TarSnap is by the FreeBSD security officer. Yet Dropbox is the one with the million+ users and $B+ market cap, because grandma cares a lot more about being able to figure out how to use the product than about what happens when the product gets hacked.

There's a lot more to DB v. TS than "Dropbox focused less on security". They're different programs for different audiences. While in some cases they may have market overlap, TS definitely has a niche that would never even consider DB as a possibility. TS's major competitor is custom solutions like rsync.net + duplicity.

Why do you asume that even a teenager who's learnt something about vulnerabilities of web apps, will only try to find a bug typical for i.e. Rails?

It's more likely your app will become a target when it's popular among users.

I think the issue is less with bored teenagers and more with turnkey r00tkits. Remember when these Rails issues first blew up and someone posts a very insightful article saying that anyone, anyone running a public Web-facing Rails installation would be exploited?

This is possible because it can be computer-automated.

If you're in a situation where a teenager has to get bored and specifically tinker with your niche software then you may already be a large step ahead.

I mean, right? If we take it as true (as many are claiming here) that all web frameworks have security vulnerabilities and Rails is just being picked on because of its popularity, then you essentially need to make the decision between having 24/7 ability to quickly upgrade all of your running Rails installations, or using something not as popular.

As I asked in another thread discussing Rails security, what are the alternatives? What did you move to?

I honestly want to know. I can understand that Rails has this problems, and due to the way it originated (37 Signals apps) I can understand if security wasn't top priority. But now it does scare me a lot. I'm designing a product to be deployed at some large companies and every day I feel less and less secure about using Rails for that. It will be hard to explain to an executive in a top 500 company that I have to patch the damn system every week for a new problem.

There are some frameworks that are designed with security as top priority: Lift (used at FourSquare and theguardian.co.uk), Opa, the main Haskell frameworks (Yesod, Happstack, Snap), and Google Web Toolkit come first to mind. And of course the mature J2EE frameworks if you want to go there.

That's no guarantee, and Rails gets a lot of scrutiny so it's difficult to tell to what degree if any it is less secure than other, less scrutinized frameworks, but these are all worth checking out.

http://liftweb.net/

http://opalang.org/

http://www.yesodweb.com/

http://happstack.com/

http://snapframework.com/

https://developers.google.com/web-toolkit/

It's hard to take Google Web Toolkit seriously when Google themselves don't use it. I mean, it's cool and all, but a Rails-killer, it is not. And after all is said and done, if you had wanted to develop the site in Java, you could have just used J2EE.

As for Haskell-- are you serious? You'll never find another developer who wants to maintain your Haskell code.

I agree that Lift is a good choice, for all the same reasons why Scala is a good choice.

I would also add Revel, for Golang, to that list.

>it's cool and all, but a Rails-killer, it is not

I don't consider any of these to be Rails-killers, for comparative lack of the combination of lots of web-oriented libraries/plugins and ease of configuration, Rails' biggest draw.

But OP asked for frameworks designed for security, ostensibly to suite the needs of his upcoming project. GWT and the others could be options for that project, depending on requirements. Only OP knows, but worth suggesting.

>And after all is said and done, if you had wanted to develop the site in Java, you could have just used J2EE.

Yup, as I mentioned.

>You'll never find another developer who wants to maintain your Haskell code.

That's an absolute with which I absolutely I beg to differ.

>I would also add Revel, for Golang, to that list.

Looks interesting, but not mature enough yet to include it in this answer. And when they say 'modeled on the Play framework', that's a yellow flag to me, given that Play wasn't designed from scratch for strong security. Originally Play was easily vulnerable to basic attacks like XSS and later patched - eg, not designed around security from scratch. They seemed to want to build a better Rails on the JVM, but they seem to have also adopted the Rails community's preference for 'cool, quick, easy, and magic with security bolted on later', and just added 'fast'. Hopefully the Revel guys do better.

Since I'm the op, I'll answer ;)

First, I do want to thank for pointing those frameworks out. I Knew about all the Haskell ones as well as Lift, but OPA I had no idea. Currently looking at it now. Not a fan of JS, but I'm open minded enough to take a loot at.

I quite like Haskell, but I feel the Haskell frameworks aren't there. They may be secure, but the way we have to develop around them makes me cringe (snap for example, and how to get parameters from actions, or yesod with the template haskell everywhere). Also, not sure how battle tested they are. Looking at Haskell wiki, each project has about 10 sites to each framework, and none high profile enough.

I love my unix shell, but I'm really considering .net for this (I think c# is quite a decent language, and f# allows me to have functional programming in there.) Microsoft is trusted by the enterprise (Even if there are issues, managers are more willingly to allow .net patches than framework of the day patches.)

I'll look at lift/scala/play now, see if they allow me an ease to develop that I like, combined with JVM security (whatever that is, but more likely a manager will know about JAva than Ruby/Python)

>but OPA I had no idea. Currently looking at it now. Not a fan of JS, but I'm open minded enough to take a loot at.

Crap, Opa used to be an Ocaml framework that you programmed with an Ocaml-derived DSL and that generated client side JS and a single native binary that contained both the app server, web server, and database. It reminded me of Facebook's single binary blob architecture.

But looks like it's been changed since I last looked at it, now you program it with a JS-derived DSL and it generates client-side JS and server-side Node.js. It can still compile to server-side native code, but not by default, you have to compile it from source to get that:

http://forum.opalang.org/0_235

At a cursory glance it appears the MLState guys are still using their Ocaml-based compiler to generate both the client and server side JS/MongoDB, and I assume still have the same focus on framework security, but not certain.

Personally, the only one of those frameworks I would use for high-security production is Lift, though I'm really looking forward to the Haskell frameworks getting there as well. Lift is the only one that meets my personal requirements for maturity and designed-for-security, but figured I'd list the others just in case.

Lift also does things differently, in a way that I personally appreciate but not all do - namely that html 'pages' are parsed as typed XML DOM objects rather than dumb text files/strings, and Ajax/Comet are DOM transforms rather than string rewriting. Instead of writing controllers, you write 'snippets' in Lift's DSL that bind to a DOM element and transform it, and that can be wired to other snippets, parallel processed, and lazy-loaded. All very cool, like a server-side single page application.

As for .NET, I haven't used or even paid much attention to the MS stack since 2009 so am not qualified to say anything about it, but it's definitely a safe choice. Nobody ever got fired for buying MS, they put billions into securing it, and there are tons of experts on it.

Revel doesn't run on the JVM. Golang compiles to a static binary that you can just deploy with the cp command. As for security, it seems a little unfair to criticize them for stuff that a different, unrelated framework did.

As for J2EE, it's solid, but Java's security reputation may have been tarnished by the latest web-client exploits.

As for .NET... do you really want to share your profits with Microsoft? I do agree that Microsoft's security has improved lately though.

The other thing about both .NET and J2EE is that they don't strike me as terribly productive languages for programmers. This may ignite a flamewar, but I don't think anything can claim to replace rails unless it also replicates the productivity of rails. You may find that hard to do if you use a pointy-hair-approved solution.

>As for security, it seems a little unfair to criticize them for stuff that a different, unrelated framework did.

True, but as a first impression it's not positive, for me at least. I don't have the bandwidth to evaluate more deeply, so unfortunately signaling like this carries more weight than it probably should.

>As for J2EE, it's solid, but Java's security reputation may have been tarnished by the latest web-client exploits.

Not to those of us only interested in server-side Java. The recent vulnerability not only does not affect server-side Java, it also does not even affect client-side standalone Java apps. Just Java applets running in the browser. Those of us paying attention know that and aren't overly concerned by it.

>The other thing about both .NET and J2EE is that they don't strike me as terribly productive languages for programmers. This may ignite a flamewar, but I don't think anything can claim to replace rails unless it also replicates the productivity of rails. You may find that hard to do if you use a pointy-hair-approved solution.

One of the biggest cognitive mistakes people make that leads to misjudgments is not thinking in terms of expected value. For example, Rails may be more productive than J2EE up front, but if you lose significant developer time or worse, money, to breeches and exploits, then its total productivity could end up worse than J2EE.

I'm only saying this hypothetically b/c I don't have any data on that, but I see this sentiment over and over, that Rails is the most productive framework out there. But the question to ask is what is the real expected value of Rails productivity vs other frameworks.

Having said that, I personally hate Java and J2EE, love the JVM, and use Scala whenever possible now for that reason. Lift really hits the sweet spot of productivity, strong security, and maturity.

Haskell is a great choice. While there are fewer Haskell developers in absolute terms, there is a very disproportionate amount of good developers who know Haskell. Startups using Haskell, as well as companies using similar languages like OCaml, have reported that, paradoxically, it's actually easier to hire Haskell programmers because they get more well qualified applicants and fewer unqualified ones.

Moreover, if you're actually working with competent people, they should have no trouble learning Haskell. Chances are, everybody already is, and would be happy at a chance to use it at work.

All the FUD spread around about Haskell is unfortunate. It's a brilliant, practical and extremely productive language, and people are turned away from it for misinformed and poorly considered reasons.

>All the FUD spread around about Haskell is unfortunate.

Not necessarily, Haskell's unofficial motto is after all, "Avoid success at all costs". ;)

http://www.codersatwork.com/simon-peyton-jones.html

Reply on news.ycombinator.com