Thoughts on awareness of security vulnerabilities & full disclosure
- 📅
- 📝 322 words
- 🕙 2 minutes
- 📦 .NET
- 🏷️ security
- 💬 1 response
HTML, SQL and XSS injection vulnerabilities aren’t new but they are still largely ignored by developers.
My first encounter with these issues was in 1999 whilst writing an extranet e-commerce web site. Back then the ASP fix consisted of Server.HtmlEncode for all output and a Replace("'", """")
for strings heading to SQL (other types headed there via CInt/CLong/CDate and I wasn’t aware of parametrized queries).
Convincing co-workers on the severity of the issue and what to do about it for several years can be a draining process when you work with such a variety of different developer personalities and projects and you would rather be spending the time on more exciting things
Over the last few months I’ve been trying hard to push the message further afield via presentations at the local user group, articles here on my blog, discussions in Redmond as well as forums and private mailing lists.
More than once I’ve had the feeling I should give it a rest in case people think I have nothing else to talk about and at a few times I’ve considered publishing a few scripts I had in my head to really show the sort of things available. Of course doing such a thing would both highlight the problem but also provide a dangerous tool to people who might use it to actually exploit sites which is a problem with full disclosure. In the end my article How dangerous is HTML injection was a much neutered version without a killer payload.
Thankfully some great people are now on the case including Rob Conery and Phil Haack who I believe in to push this from inside and Steve Sanderson who came up with an elegant prototype on how to handle this at the source.
That will be all the HTML injection posts for a while I hope for there are many other things I want to work on and write about.
[)amien
1 response to Thoughts on awareness of security vulnerabilities & full disclosure
To be honest I find it quite incredible that this is still an item for debate — it’s been a known issue for so long after all. But there are so many ‘green’ developers out there making apps, and so many of them gravitate towards ‘quick & dirty’ techs like PHP and ASP without knowing what the hell they’re doing, I guess it’s no surprise. Security issues like this should be covered as standard in university courses really, it’s so fundamental to modern development; even just having an awareness of it rather than a deep knowledge would help I’m sure.
It all adds fuel to the argument that the more experienced library / platform developers, particularly those aimed at entry-level people (which .Net is always pitching at, IMO, with all its wizards and create-me-an-app-now helpers) should assume that a significant number of developers using their tech will be totally clueless, and thus default to protecting them from themselves. Smart developers will always figure out how to do what they need to so any extra default behaviour won’t bother them if they need to avoid it, but dumb developers will happily use whatever crappy code snippets and insecure libraries are available with impunity and create a whole new generation of problems.