Locks Are to Keep the Honest People Out
The latest DevCares, from my perspective, was an appropriate deep dive after Tuesday’s MSDN Event covering application security. The MSDN Event was a little less than stellar, and we found out why at DevCares. Uber presenter (and ex-LÛCRUM-ite) Bill Steele had a family emergency, so the MSDN presenter was probably working off of one-day’s notice. It’s forgivable. Mike Wood picked up the ball and handled DevCares. Given the circumstances, Wood handled the ball with the heart of the bat. Get it? Wood? Bat? Oh, never mind.
Before things began, I had an interesting conversation with Joe Wirtley, a fairly well-known, independent .NET developer in the Cincinnati community. We talked about the benefits of presenting at events like this when you are an SME on the material. We also talked about the pitfalls of having the presentation material given to you from a third party. In the second case, everything works well until it doesn’t. As long as no one has a question about the materials (uh…yeah), you’re good to go. Then Joe verbally lamented the continual pounding on SQL injection that pervades almost any application security talk. You know, you’d think with all the coverage, SQL injection simply would not be an issue anymore. I suppose it’s the laziness of experienced developers because they have not been caught with their hands-down yet, the inexperience of younger developers who are many times handed the more mundane SQL tasks, and the pressure of GET IT DONE NOW that keeps developers from following through on disciplined security practices. These things are not too difficult to design into an architecture or framework in the first place, still they get missed. What do you think?
I got a chance to meet and talk with Xavier CompSci grad and Sogeti Senior Consultant Kevin Arand. I was somewhat surprised to hear that Xavier had a CompSci program. We had an interesting discussion about different training strategies and the ever-present requirement to balance billable hours with training time. Given all the consultants I talk to in Cincinnati, this is a fairly common theme. The company is in business to make a profit while at the same time needing to address employee retention strategies. Training seems to be a central retention topic. I hear from most that training hours need to be made up, so training is not a foremost pursuit in the consultant’s mind. And that is generally at odds with the annual review process which inevitably has the “what did you learn this year” question in some form or another. How does this work at your company? The consulting firm that creates a training model that allows the company to make a profit while really benefiting their employees may find themselves in an enviable and strategic front-runner position when folks are looking to move.
Tim Adams, the Microsoft Developer Solutions Specialist (this week), attended DevCares bearing VisualStudio branded hoodie-vests. Nice touch.
Congratulations are also in order for Kavitha Allam. I had a few moments to speak with her. She let me know she’s moving from First Data Government Solutions to Cintas in a couple weeks. Good luck, Kavitha. Although, I gotta say the ties and name badges are a formality I could live without.
USBank‘s .NET Framework Architect, Brad Butts, was also in attendance. We talked a bit about application security and how he leads efforts to implement best practices in their enterprise framework. If I remember correctly, Brad is an experienced consultant having spent a number of years at EDS. He’s been able to settle into a role at USBank that has kept him off the road and nearer to his family. Brad is definitely a talented architect, and he currently serves in a hands-on consultative role to the enterprise.
Okay, so Mike dove into the application security presentations, and to his credit, given the short notice, most of the demo’s succeeded. We didn’t have much experimenting in this talk. Microsoft provided most of the slide deck, and I thought it was interesting to see the material built around the OWASP top ten vulnerabilities. It’s good to see MS leaning on the efforts of an Open project from time-to-time.
The material covered the topics of:
- Information Leaking – revealing too many system internal details to the user. Symptoms include returning developer level error messages to the user which can reveal sensitive and detailed infrastructure and configuration information. I saw one of these plastered on the Macy’s Fountain Square big screen once. You can thwart this with consistent exception handling approaches – no one-offs. Update 2/13/08: I was at Brueggers and logged onto their free WiFi in Firefox (did not work in IE). On their submit page I submitted a form with all blank fields and got this Bruegger’s Exception response.
- Broken Authentication and Sessions – generally a condition when you allow the browser, and not the server, to manage sessions and authentication too much. You’ll find this when you rely on cookies and “remember me” functionality. For instance, try this link to a page that, I believe, is supposed to be behind an employee login screen (hopefully this link won’t work in a day or two). All I did was type “liliane mylott” into a Google search, and it’s right there, for me – the 4th link on the first page of search results. To guard against this simply put a control matrix in place that validates the user/role is allowed to access this URL. I coded up a straight-forward implementation of something like this some time ago. If anyone is interested, just let me know and I’d be glad to share it. See the next issue, Failure to Restrict URL Acces, for more detail. Manage these issues by authenticating your user at every access to secure functionality, and let the server, and not the browser, manage the session.
- Failure to Restrict URL Access – security through obscurity and poor authentication.
- Cross Site Scripting (XSS) – usually iframe tags that hijack information stored in user cookies due to “remember me” functionality. Suffice it to say that you probably never want to check that box. Let your browser remember your passwords, don’t let the sites you visit remember them, unless you enjoy fixing thousands of dollars worth of unauthorized charges to your credit card. Use Captcha as just one of many ways to short-circuit XSS.
- SQL Injection – see conversation with Joe Wirtley allowing free form user data to pass through your application invalidated and unscrubbed. Remember “Little Bobby Tables.” Two words: Parameterized Queries.
- Injection Flaw – similar to SQL Injection, Injection Flaw is when unscrubbed and invalidated data is injected into any process, i.e. XML processing, etc. For this one, constrain and sanitize all user input. User input is Evil.
- Malicious File Execution – allowing arbitrary file uploads and then execution of those files or commands. Since these exploits will many times try to connect to networks outside your own, don’t allow outbound traffic through your firewall from your app and database servers. Don’t allow functions to take filenames as parameters. And run your applications in unprivileged states.
- Insecure Direct Object References – referencing files and other objects by name rather than by some mapping or reference to those objects, i.e. http://someurl.com/locations?store=cincinnati.txt rather than store=18, where 18 is some arbitrary map to the referenced object.
- Insecure Cryptographic Storage – coming up with your own encryption algorithm. You are not that smart. Use existing, proven algorithms and implementations. Or create your own and send me the URL.
- Insecure Communications – not using SSL at appropriate certificate encryption levels. And pay attention to your URLs, as SSL, obviously, does not encrypt the URL. What do you have hanging off the end of your query string?
Remember, locks are to keep the honest people out. You really have to ramp up and be diligent to handle the pounding that hackers will try on your applications. Put up the barriers necessary to frustrate attempts to exploit your apps. I hate to say this, but you really just want the hacker to go somewhere else in the spirit of, “I don’t have to outrun the bear, I just have to outrun you.“
Part two of DevCares focused on building Office apps in Visual Studio ’08. The nicest learning here is the VSTO comes with VS’08 and implements document level code-behind. We were running out of time, and some of the demos in this section were going slow. That, coupled with the sheer amount of information in the first three hours, and I started fading in my attention span.
Mike provided some nice give-aways at this event. In addition to the hoodies, a couple of books about secure code, a nice laptop backpack, and a copy of Office Pro ’07 were given away. Doughnuts and danishes were provided in the morning.
Check out these links for more valuable information:
- Fiddler web debugging proxy
- Wireshark network protocol analyzer
- We were given a DVD with the iBuySpy reference implementation for all these exploits at the MSDN Event earlier this week. I don’t see it online, but you might be able to get more information at some point at the Event website. I do have the DVD if someone would like to borrow it.
- MSDN threat modeling
- MS anti-XSS library
- The PCI Security Standards site for working with credit card information
- The NSA Security Configuration Guides
- The MS Hello Secure World site – a Silverlight implementation
- MS Ramp Up to access TONS of .NET training materials
- Central Ohio Day of .NET to be held April 19th
Holy cow. WordPress is telling me I’m at 1600 words. Thanks for reading this far. It’s been a packed week with the MSDN Event and DevCares. I’m glad these only happen quarterly. I’d be interested in your thoughts about how your organization handles training and your personal response to training policies. I’d also like your understanding of why some of the basic exploits still make it into our apps. Take care, and I’ll see some of you soon.