4 ms·

Neither has any outstanding critical security vulnerabilities, which is normal for any web framework. The "security" of a web framework is not a well-defined q

by emmett 13y ago

Neither has any outstanding critical security vulnerabilities, which is normal for any web framework. The "security" of a web framework is not a well-defined quantity. Your question is malformed, and you got an answer that you should listen to: your choice of web framework is not a very important factor in the security of your site.

hardwaresofton 13y ago
I don't know if that's quite right... There was a huge rails vulnerability a little while ago (something to do with YAML executing arbitrary code) -- and I'm not sure I have seen anything thus with .NET (not to say it's not there). If you decide to go with certain versions of .NET, entire attack vectors will be closed, but ONLY because there are entire sets of features missing that you might get with Rails.
- mechanical_fish 13y ago
  I typed "zero day .NET" into Google as a proxy for actual research and got back results from 2010, early 2011, and late 2011. All seemed to be publicizing critical .NET patches, which is what you want to see. Presumably this barely scratches the surface of the list of .NET patches with potential security implications. The ideal security patch goes out quietly and gets applied quietly, after all. I'm not going to take the time for a more exhaustive search, because I've got the knowledge I'm looking for: .NET is not made of magic, such that it has not had critical patches for half a decade and I can safely choose to let it run itself. If I run a .NET stack, I'll need to watch for critical patches and apply them ASAP. If I run a Rails stack I'll need to do the same. This is the state of the art and nobody has a silver bullet for it. Meanwhile, it remains the case that the overwhelming issue in site security is my own decisions as an implementor, either architectural (e.g. "do administrators share the same login path as tens of thousands of users?") nuts-and-bolts ("did I sanitize each and every one of those queries or did I make an error late at night?") or even strategic ("did I notice that scary article about the new style of attack against compressed HTTP, and note how it applies to my stack and my application?")
  - hardwaresofton 13y ago
    Yes, in the end, as others have stated, it's definitely your job to make sure that you follow the practices that will make your system safe, but I'm essentially hoping that .NET is so old that most gaping security holes have already been found
- tptacek 13y ago
  .NET had a gigantic vulnerability just a few years ago due to pushing an encrypted blob out to users that was CBC encrypted but not authenticated; the result in many apps was direct remote code execution. Juliano Rizzo and Thai Duong won a Pwnie for it, I think. Concern over gigantic flaws like this is a good reason not to adopt a brand new unproven framework; but, once a framework matures, it's pretty much random chance whether it's going to suffer a setback like Rails did with YAML input encoding or .NET did with CBC padding oracles.
  - hardwaresofton 13y ago
    Definitely agree here too, but, the point I'd like to make is at least, a framework that has been around longer (like .NET) has already had it's tires kicked, and most of the low hanging fruit has been picked. Though I'm also not crazy about .NET in general, Microsoft does have a pretty vested interest in making it very secure, around the clock.

by emmett 13y ago

hardwaresofton 13y ago

I don't know if that's quite right... There was a huge rails vulnerability a little while ago (something to do with YAML executing arbitrary code) -- and I'm not sure I have seen anything thus with .NET (not to say it's not there). If you decide to go with certain versions of .NET, entire attack vectors will be closed, but ONLY because there are entire sets of features missing that you might get with Rails.

mechanical_fish 13y ago
I typed "zero day .NET" into Google as a proxy for actual research and got back results from 2010, early 2011, and late 2011. All seemed to be publicizing critical .NET patches, which is what you want to see. Presumably this barely scratches the surface of the list of .NET patches with potential security implications. The ideal security patch goes out quietly and gets applied quietly, after all. I'm not going to take the time for a more exhaustive search, because I've got the knowledge I'm looking for: .NET is not made of magic, such that it has not had critical patches for half a decade and I can safely choose to let it run itself. If I run a .NET stack, I'll need to watch for critical patches and apply them ASAP. If I run a Rails stack I'll need to do the same. This is the state of the art and nobody has a silver bullet for it. Meanwhile, it remains the case that the overwhelming issue in site security is my own decisions as an implementor, either architectural (e.g. "do administrators share the same login path as tens of thousands of users?") nuts-and-bolts ("did I sanitize each and every one of those queries or did I make an error late at night?") or even strategic ("did I notice that scary article about the new style of attack against compressed HTTP, and note how it applies to my stack and my application?")
- hardwaresofton 13y ago
  Yes, in the end, as others have stated, it's definitely your job to make sure that you follow the practices that will make your system safe, but I'm essentially hoping that .NET is so old that most gaping security holes have already been found
tptacek 13y ago
.NET had a gigantic vulnerability just a few years ago due to pushing an encrypted blob out to users that was CBC encrypted but not authenticated; the result in many apps was direct remote code execution. Juliano Rizzo and Thai Duong won a Pwnie for it, I think. Concern over gigantic flaws like this is a good reason not to adopt a brand new unproven framework; but, once a framework matures, it's pretty much random chance whether it's going to suffer a setback like Rails did with YAML input encoding or .NET did with CBC padding oracles.
- hardwaresofton 13y ago
  Definitely agree here too, but, the point I'd like to make is at least, a framework that has been around longer (like .NET) has already had it's tires kicked, and most of the low hanging fruit has been picked. Though I'm also not crazy about .NET in general, Microsoft does have a pretty vested interest in making it very secure, around the clock.