CodeMash 2014 Session Recap: Applicaiton Security
After letting it “sink in” for a week I realized that we all need to be a little more aware of the importance of security when we are developing applications. It amazes me that someone would post data source and connection information in StackOverflow but I was able to find 15 articles with that information readily available. Granted some of those are probably connections to a personal development environment but I literally spent less than 30 minutes looking and ultimately it made me more curious about what I could find if I actually spent some actual time digging.
Let me be clear, I am in no way, shape or form going to start targeting folks or organizations that post that information. What that really did for me was make me take a step back when posting questions, using comments in my code that directly reference a particular person’s work and catching errors appropriately. I would like to think that I would never make a mistake like this but I am still a human and most of us are imperfect on our best days. I myself was really taken aback by the aspect of commenting your source when using someone else’s code.
I am not above using someone else’s solution when it is better than my own and I always reference the code in the comments. One of the revelations that I had in this session was that I never really look past the piece of the code that I use to improve my solution. In many cases I am simply taking a method that refactors something I created and I almost never look at the entirety of the solution. That can be a huge mistake, I really should be taking the time to ensure that if I do comment the resource that it will not expose any vulnerabilities in my code as well.
The other big piece of this that I never really put much thought into is the error catching aspect of code. Creating a generic error catching block is something that I have been in the habit of for quite some time but I never thought about the effect of not doing writing a generic error catcher. When an end users sees the dreaded “Server error in ‘/’ Application” error it means absolutely nothing to them but for a developer with nasty intentions it can provide a plethora of details that your application doesn’t really need to be displaying to anyone. I work with SharePoint a majority of the time and when developing applications for SharePoint I generally turn off the custom debugging so I can get a relevant error message without using ULS Viewer or digging through the logs (nothing against correlation ID’s but I don’t want to spend the time looking around). I never do this in a production environment and after this session I never will.
Most “hacking” is done over a period of time and involves many different aspects of penetration but one thing remains the same as it was before the internet was even a thought…people make mistakes. It may just be that the developer had to rush to beat a deadline and posted something on StackOverflow that exposed too much information or just the fact that they did not think there was a need to catch all errors. Ultimately the biggest source of knowledge gathering for a potential threat is still the human element. Much like a 12 step program the only way that you can start to correct the problem is to admit it is a problem. One of the great things about being a developer is that we really do have a community and there are many sources of support out there but we first have to realize that we need that support.
