Are SSL implementation Problems Policy Problems?

Another interesting article from ThreatPost, which highlights a problem faced by many of us. TLS/SSL implementation is something which often taken for granted. It is one of the most misunderstood aspects of security. Like firewalls, those who don’t fully understand security perceive SSL and Firewalls as magic pills, which will solve all the security problems. Of course there is no magic pill.

Looking at this article it is clear the see that developers and implementors seem to think that simply turning on SSL will equal security. However weak implementations of SSL can mean that attackers may be able to manipulate SSL handshakes to force the use of weak cipher suites.

There are many mechanisms to combat this:

1) Education -> Project implementors, network professionals and developers need to be shown how to use SSL appropriately.

2) Governance -> Updating project implementation policies to include governance that assures the implementation of SSL comply with predefined standards and guidelines.

3) Testing -> Include compliance testing as part of QA processes, which verify that SSL implementations are strong and comply with the prescribed governance.

Check out the SSL Labs at Qualys.

Advertisements

Don’t call me Shirley!

The other day someone came into my office and asked: “Why should I have to validate the web form input at the web server? Surely it better to do it in the browser!”

*Humph!*

“I can think of many reasons why you are wrong”, I said, “and don’t call me Shirley!”

Firstly, and I can hear the clockwork ticking over in many web developers heads, you may get a slight performance improvement if you don’t validate the input at the server. However, any gains need to be offset against the losses. Are you willing to risk the chance [did I say chance? I mean damage!] that an attack will do for a mere millisecond or two gain in performance? Lets think about it logically: are users really going to gain anything by you doing this? Simple answer : NO!!! The user of your web application is never going to notice and doesn’t even care whether you do the validation of the input in the browser, server or Timbuktu! Save your users and save your web application by always validating at the web server!

Secondly, there are many intercepting web proxies that can be used to extract and manipulate the parameters of a web form after validation. Even if the validation is in the browser this does not protect your web server. Also, there is nothing to stop me as a developer cloning your web form, removing the validation and then submitting to your application. Again, this renders the input validation useless.

Finally, many of the main web server or web application server vendor solutions (think IIS / ASP.NET or Oracle Application Server  or JBoss) include in the framework the ability to validate the input data against a specified subset of character or data type. In ASP.NET you have to explicitly change the configuration in order to turn it off. If it’s already there, use it! Don’t go re-inventing the wheel just because it sounds like fun.

With these words of advice ringing in his ears this individual went off with their tail between their legs – and he’s never called me Shirley since!