3 ms·
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 criti
by 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 agoYes, 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