Tuesday, February 5, 2008

Trust: to have confidence or faith in

(title is a definition from google.com)

Trust is what lets management sleep at night. Managers trust their employees to do the right thing and keep business progressing, and employees trust managers to take care of them. Much like any other part of business, on the application development and security side, trust is what gets us into hot water. Developers expect users to make mistakes, but they also trust them to not be malicious. Companies also trust third parties to develop applications securely, with proper access control, input validation, and zero back doors.

This undeserved trust is the cause of many application security vulnerabilities, and I'm not sure where it comes from. Some people say "trust but verify". I say "trust = validation". If you haven't performed validation on it, you can't trust it. This goes for data flowing in from the Internet, as well as your new app being delivered from your overseas outsourcer. You can validate the data flowing across trust boundaries using regular expressions, and you can validate your new codebase using manual review and automated static analysis.

I spoke with some developers today, and instead of trying to train them to hack their own applications, I explained to them how their blind trust of users and data is a paradigm that can't exist anymore. I think that if we can break this trust, coding habits will rapidly change. Teaching developers to be hackers is the wrong approach, but that's a post for another day.

I told these guys you can never trust a user; you can only trust a users data, and only after the data is validated. Validation consists of strong typing of input as well as CSRF protection using anti-CSRF tokens. CSRF is a perfect reason for not blindly trusting users or authenticated requests in web apps, as you can't be sure that an authenticated user actually intended to send the request.

Next, I told them they need to compartmentalize the different components of their applications using trust boundaries. When you look at an applications trust boundary diagrams, you are really looking at data flow across the app. A picture says a thousand words, and when a developer sees that his "trusted" middle tier is just a conduit for tainted data from the Internet, he may think twice about trusting said middle tier.

I'll conclude by saying that trust is a lame way to place responsibility on someone else when you get hacked, and if you trust the wrong people, hacked is what you will be. Just ask Jérôme Kerviel.

2/6/2008 Note: The above link used to go to an interview with Jerome Kerviel which seems to have been taken down. Here is a new link to a different article: http://www.france24.com/france24Public/en/news/world/20080125-societe-generale-kerviel-banking-scandal-police-custody.php

Also, Mike Tracy has an interesting blog post up on Matasano here.

No comments: