Sunday, October 18, 2009

OWASP TLS Protection Cheat Sheet



I'm now officially launching the OWASP Transport Layer Protection Cheat Sheet. This cheat sheet joins the ranks of other successful OWASP cheat sheets such as the Cross Site Scripting Prevention Cheat Sheet.

The TLS Protection Cheat Sheet provides a quick but detailed explanation of the primary considerations when implementing TLS (e.g. SSL, HTTPS) for your web application.

Here's a taste:
  • Secure Server Design - How to do the login page correctly, Risks of HTTP to HTTPS redirects,"Secure" cookie, HTTPS referrer leakage
  • Server Certificate & Protocol Configuration - TLS vs SSL, Cipher selection, Certificate Authorities
  • FIPS 140-2 - Certified Cryptomodules
  • ...and more

Many thanks to the reviewers (Mike Boberski, Dave Wichers, Tyler Reguly). The cheat sheet wouldn't be where it is today without your help.

If you are attending OWASP AppSec DC I'll be speaking about several of the items within the Secure Server Design section during my power talk : Advanced SSL: The good, the bad, and the ugly.

Twitter? Use #TLSCheatSheet.


-Michael Coates

Monday, October 12, 2009

PCI Requires Developers Receive Training in Secure Coding Practices

Did you know that section 6.5.a of PCI requires that developers receive security specific training which incorporates security coding best practices such as those listed at OWASP?
6.5.a Obtain and review software development processes for any web-based applications. Verify that processes require training in secure coding techniques for developers, and are based on guidance such as the OWASP guide (http://www.owasp.org).
PCI v.1.2.1

On the note of PCI, be sure to check out last week's post on PCI Requirements Soon Change Per New OWASP Top 10.

-Michael Coates

Friday, October 9, 2009

PCI Requirements Soon Change Per New OWASP Top 10

Section 6.5 of PCI requires that all web applications must be developed in accordance with the security guidelines produced by OWASP. PCI version v1.2.1 references these security areas in sections 6.5.1 - 6.5.10. In addition, PCI also states the following:
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when this version of PCI DSS was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements.
A release candidate of the OWASP Top 10 is scheduled for release at OWASP AppSec DC taking place in November in Washington DC.

This version will not be an official release and hence not immediately go into effect based on the above statement by PCI. However, you may want to attend this conference and get the first view of the new OWASP Top 10.

Once the document is finalized and officially released the guidelines put forth by the OWASP Top 10 will supersede the existing items in PCI sections 6.5.1-6.5.10. As such, compliance with PCI will immediately require that applications are designed with defenses to prevent against the vulnerabilities identified in the 2009 version of the OWASP Top 10.



-Michael Coates

Thursday, October 8, 2009

Report Confirms - SSL Largely Misunderstood

[All quotes from Dark Reading Story]

Interesting statistics on users, info sec users, and SSL from Tyler Reguly's research discussed at the SecTor Conference.

Regarding average web users:
Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords.
I'm not terribly surprised here. Most users are aware of the threat of "identity thieves" and have associated SSL with protecting their credit card. I don't believe that users think through the whole process. If the attacker steals your password, then they become you and can get any information provided by the app.

Want to get an even lower percentage response? Test to see how many users consider SSL an important factor after they've logged in (e.g. after login page, but not a page which accepts credit card data). My guess is none of them will care. That's because very few average users have any concept of the risk of session ID exposure. Many popular sites operate this way - facebook, linkedin etc.

Regarding information security professionals:
More than half of the respondents don't know what Extended Validation SSL (EVSSL) is and how it differs from SSL, while 36 percent say they do.
This is not good. Security professionals need to get on the ball here. EVSSL is especially important to understand. Because, although the extra verification of the owner is good, it is not a silver bullet by any means. There are numerous other ways a site can mess up SSL - even with an EVSSL cert. (Since the EV part is the manual verification of the company's identity and has nothing to do with the technical implementation of SSL itself)
Even so, nearly one-third say the only purpose of SSL is to encrypt their traffic so it can't be sniffed.
This is a common misconception. Remember, SSL offers end-point authentication, confidentiality, replay attack protection, and built in integrity checking.
Meanwhile, 51 percent of the survey respondents said they rely on browser error messages to alert them of flaws in Website security
That's just not good. I hope that percentage is based on the average user and not an info sec community poll. On the other hand, I think it is fair to judge that a site has poor security if they can't even get the SSL portion right. Just don't think the inverse. SSL is just one piece of a large pie.


-Michael Coates

Wednesday, October 7, 2009

UK's Website for Citizens to Spy is Insecure Itself

The UK has always had a keen interest in recording and monitoring the general population. Its all in the name of "personal security" but is often compared to Orwell's 1984 classic. With the recent announcement of the ability for home citizens to monitor the CCTVs, the UK has taken another step towards Orwell's nightmare scenario.

Casting aside the debate on big brother, I found it very interesting that the new website, which will allow the public to register to became a government paid voyeur, is in itself insecure. Internet Eyes fails to employ even the most basic security controls to protect its users.

For example:
  • The registration page does not use SSL. This means that an attacker could monitor the information you enter, including your username, password, name, address, email and paypal email. There is also mention that you may need to provide financial information to receive payment, so that info would be available for the attacker as well.
  • If you attempt to browse to the equivalent SSL page, you see a huge browser warning that the SSL certificate is both expired and also only supposed to be used for a site called feedthelake.com
Both of these are huge red flags in the area of application security. And consider this, these items are some of the most fundamental security controls that can be easily observed by all users. If a site is having difficulty with these items, just imagine whats going on behind the scenes. It can't be good.

The other interesting item is that both of these security failures are in violation of the site's own privacy policy. (emphasis added)
13. Your information is stored on our servers located in the United Kingdom. We treat data as an asset that must be protected and use a number of tools (which may include encryption, passwords and physical security) to protect your personal information against unauthorised access and disclosure.
However, I think the next few sentences of item 13 really take the cake.
However, as you probably know, third parties may unlawfully intercept or access transmissions or private communications. Therefore we do not promise, and you should not expect, that your personal information or private communications will always remain private
Actually, I didn't know that. In fact, good security controls are supposed to be implemented to prevent this very issue. Though, judging by the security on your site, or lack there of, I guess you do have a valid point.

My advice, stay away from this site. Any user registering with this site will be putting their personal and financial information at significant risk.


-Michael Coates

Monday, October 5, 2009

SSL Null Prefix Attack in the Wild

Moxie Marlinspike discussed the SSL Null Prefix Attack several weeks ago at BlackHat. Due to flaws in the handling of SSL Certificates, at the time of his talk, all browsers were vulnerable. Shortly after the talk Mozilla patched Firefox for the flaw. Unfortunately, other browsers have not yet followed suit.

What does this mean for you? There is now a ficiticious paypal certificate in the wild. The certificate looks like this:

www.paypal.com\0ssl.secureconnection.cc

If you are using a browser other than Firefox, your browser will determine the above certificate to be valid for SSL connections to paypal.com. This means that an attacker with this certificate can execute a Man-In-The-Middle attack against your connections to PayPal and your browser will not alert you to anything. Again, because the non-FF browsers believe the certificate to be legitimate.

Ikes.

It's time for the other browsers to catch up and patch this flaw ASAP.


-Michael Coates