7 ms·

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

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

charliesome 14y ago
What are you going to do when whatever you're currently using has a security problem? Moving off Rails is not a panacea
- mpyne 14y ago
  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"
  - jiggy2011 14y ago
    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.
    - obstacle1 14y ago
      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).
      - nostrademons 14y ago
        ...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.
        cookiecaper 14y ago
        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.
  - szalansky 14y ago
    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.
    - mpyne 14y ago
      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.
BSousa 14y ago
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.
- SkyMarshal 14y ago
  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://liftweb.net/ http://opalang.org/ http://opalang.org/ http://www.yesodweb.com/ http://www.yesodweb.com/ http://happstack.com/ http://happstack.com/ http://snapframework.com/ http://snapframework.com/ https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
  - cmccabe 14y ago
    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.
    - SkyMarshal 14y ago
      >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.

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

charliesome 14y ago

What are you going to do when whatever you're currently using has a security problem? Moving off Rails is not a panacea

mpyne 14y ago
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"
- jiggy2011 14y ago
  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.
  - obstacle1 14y ago
    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).
    - nostrademons 14y ago
      ...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.
      - cookiecaper 14y ago
        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.
- szalansky 14y ago
  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.
  - mpyne 14y ago
    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.

BSousa 14y ago

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.

SkyMarshal 14y ago
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://liftweb.net/ http://opalang.org/ http://opalang.org/ http://www.yesodweb.com/ http://www.yesodweb.com/ http://happstack.com/ http://happstack.com/ http://snapframework.com/ http://snapframework.com/ https://developers.google.com/web-toolkit/ https://developers.google.com/web-toolkit/
- cmccabe 14y ago
  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.
  - SkyMarshal 14y ago
    >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.