Monday, April 24, 2006

Application Security

Why is there an inherent disconnect from application development and security. Why is it there are still many web applications performing no input validation except for maybe on the login page? Why do some banking sites still only allow a password of 6-8 characters with no special characters allowed.

I heard a funny the other day where one business unit was placing a limit on the size a password could be. This limit was 25 characters and I must be crazy but most all of my passwords are much longer than that. I recommended they allow longer passwords (up to the system max of course) but the development staff said it would take a while to get business sign-off. I am wondering why this places a burden on the user by allowing a lengthier password or passphrase. I am burdened by only using a 25 char password.

Application security is seriously being looked at from a consulting perspective but not much is being done to mitigate the risks and flaws found within applications. The biggest problem is there is no security win an application development lifecycle until the implementation phase when users, groups and roles are mapped into the application. There should be security involvement throughout the entire lifecycle beginning with the requirements gathering phase. This would continue through the development phase with penetration tests and then into the implementation and maintenance phases.

This is not a new thought but it still isn't being done because security costs money and time. The real problem is there is a disconnect between development staff and what security is. I sit in meetings and ask developers if there site is secure and they say things like "It uses SSL, so yes", or "it requires a user to login." If I ask a team of developers for another company if there product has been through a formal penetration test based on standards like the OWASP Top 10 (http://www.owasp.org) I get answers that range from "Government agencies use our product," to "there are no coding changes needed."

The thing is development staff needs to be accountable for understanding the basic flow of a network, what is a socket, how does TCP/IP work, what about SSL, what does it really mean? If they really understood an HTTP Request and Response they would better understand what damage could be done. I amazed a developer recently when I bypassed the "security" checking on their site by using a proxy tool such as WebScarab or Paros. His input field validation was using client side JavaScript. I then showed him I could turn off the JavaScript and do the same thing, then I changed the input field to the max of 40 characters. He said "see we atleast verify the size." I then intercepted the request with WebScarab, changed it to be 4 million characters and slowed the site down. Needless to say I saw a lightbulb and the whites of his eyes.

Do we really have to wait for an attack to occur before action is taken? How do we put it in terms of money for management? There are actuarial tables for everything else, like how much it would cost a hotel to have a story released about a girl being raped in one of their rooms (saw it on Law and Order: SVU). It would cost the company much less to pay off the girl then to have a story released saying their hotels are not safe from predators. How about, how much would it cost a company if data was lost and a story was released to the public about a data breach through a web application? This might strike a technically savvy person as an interesting thought but for some reason development, and management staffs do not get it. What to do......

No comments: