I've never been a strong believer that data in transit is in grave danger. After all, Web-related data is at rest most of the time. Sure, someone could use an ARP poisoning tool such as Cain & Abel to capture unencrypted data going across the wire. There's also the issue of unprotected wireless networks. But even with all this, it's usually improperly secured Web applications and server-side weaknesses that facilitate most of the Web security problems.
In today's world of compliance and potential risks being misunderstood there's an aspect of data in transit that deserves a further look: Secure Sockets Layer (SSL). SSL in and of itself is not all that bad. It's the outdated and poorly-implemented installations of SSL that tend to cause the problems. I know a lot of people get dinged with certain SSL vulnerabilities on their Web security reviews – especially those involving PCI DSS compliance.
Want to be able to get past these headaches? Here are four things that come up in practically every Web security assessment I do. Fix these and you can fix a sizable chunk of your Web security vulnerabilities and get those pesky auditors and compliance folks off your back:
- SSL version 2
This old version of SSL is often enabled by default on Web servers which can allow an attacker to decrypt sessions and glean sensitive information especially when accessed over an unsecured communications channel such as a wireless network. The likelihood is low but the impact is high. The solution is to use SSL version 3 (a.k.a. TLS version 1) on your Web server. Once you make your changes, you can use the Foundeo SSL check site to verify your settings.
- Weak encryption ciphers
Low encryption ciphers (key lengths less than 128 bits) are enabled which can allow an attacker to decrypt SSL sessions and glean sensitive Web information especially when accessed over an unsecured communications channel such as a wireless network. The solution is to disable cipher low encryption ciphers on your Web server. Once you make your changes, you can use Foundstone's SSLDigger tool to verify your settings.
- SSL cookies not being used
SSL cookies are cookies that are marked secure and are, therefore, only transmitted if an SSL connection is present. Not using SSL cookies can result in sensitive information being exposed in unencrypted HTTP sessions. Marking SSL cookies as secure varies among platforms but it's often a matter of setting secure=true when creating each cookie.
- SSL not being enforced on the entire site
Another common issue I see is SSL being enforced on certain parts of a site but not others which could lead to unauthorized access of login credentials and other sensitive information especially when the application is used on an unsecured system such as a wireless network.
To find out if you have any of these SSL-related weaknesses I recommend using a Web vulnerability scanner such as WebInspect or Acunetix Web Vulnerability Scanner. This OWASP document also outlines some additional manual steps for analyzing SSL settings as well.
You can never ever rely on SSL alone to provide security for Web applications – even when you make the changes listed above. However, using SSL in the all the right ways will go a long way towards ensuring an overall secure and compliant Web environment.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books, Hacking for Dummies and Hacking Wireless Networks for Dummies (Wiley). He's also the creator of the Security On Wheels IT security audio books.
This was first published in March 2010