Here's the current OWASP 2010 Top 10 list (this is release candidate 1, so it could change):

1. Injection
2. Cross Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Failure to Restrict URL Access
8. Unvalidated Redirects and Forwards
9. Insecure Cryptographic Storage
10. Insufficient Transport Layer Protection

If you are a developer and you don't know what some of these security risks are and how to avoid them in your code, then you should be reading this: OWASP Top 10 2010 RC1 (pdf).

Many of the developers I've worked with treat SSL as if it's the carrier of a new and virulent plague or the product of evil magic. They duck and run for cover whenever the boss shows up looking for someone to battle a new error. Having not ducked fast enough, I've found myself face-to-face with SSL on many occasions, and have survived to overcome the intimidation factor and tell you that solving most SSL problems is a snap and anyone can learn to do it. By becoming the SSL go-to person in your IT department, you'll win fame and recognition as the great defender against evil magic. I reveal below these mysterious secrets of common SSL problems and some simple tricks and tips for solving them.

Expired Certificate

Probably the most common problem is that the certificate can expire. When the certificate expires, the site breaks. You can view the certificate in your browser to see the expiration date when you try to load a page that is using an expired certificate. This is usually accomplished by right clicking on something, and differs by browser, so I'll leave you to learn how to view the certificate in your preferred browser.

Solution: Purchase a new certificate and follow the instructions to install it.

If you already did purchase and install a new certificate and you're still having problems, then it's likely a configuration issue, so check the "Certificate Configuration" section below.

Hostname Doesn't Match

Browsers and SSL-enabled programs don't like when the hostname in the certificate doesn't match the hostname of the URL that's being used to access the content, and they complain about it. In a browser you'll see a pop-up window warning you of imminent danger. In a program you wrote, it will show up in an error console or log file. In Java, you can see a nice exception stack trace telling you of the hostname mismatch.

The problem here could be configuration or usage, so I'll give a list of things to check:

• Check that the hostname of the certificate you installed does indeed match the hostname of your server. Certificates aren't perfect and can sometimes come with the wrong hostname, or it's possible there was an error in ordering the certificate.
• Did the hostname get changed recently?
• Is the IP address being used in the URL rather than the hostname that matches the certificate?

Certificate Configuration

If a new certificate was recently installed, check for these common mistakes:

• Certificate not installed where your server expects to find it. Check the server configuration files to learn where it expects the certificate.
• Similarly, check that the certificate file has the name the server is expecting.
• Incorrect certificate format. When a certificate is ordered, it's ordered to be the format expected by the particular server and operating system. Make sure that the certificate order was for the correct type of certificate. If it was incorrect, it may be possible to convert it at the Certificate Authority.

You'd be surprised how often simple errors regarding file path, file name and certificate format occur.

Certificate Chain, Testing With Self-Signed Certificate

Developers often want to test with SSL and so they generate a self-signed certificate to test with, but then are mystified when it doesn't work. Two problems with this scenario are first, the above issue of the hostname not matching the hostname for the self-signed certificate, and second, the certificate chain is not determined to be valid by the browser or program accessing it.

The hostname mismatch is easily solved by making sure to generate a certificate that matches your development server.

The certificate chain problem arises because indeed, the certificate you generated is not considered valid because the root cannot be traced back to a valid Certificate Authority. You can work around this by granting trust to the certificate:

• Import the self-signed certificate into your browser.
• Import the self-signed certificate into your truststore, this is simple to do in Java.

Certificate Chain, Untrusted Root Certificate

I've seen cases where a certificate was showing up as untrusted when we knew it was a new certificate that we spent good money on and it should be trusted. This usually turns out to be a certificate format issue, so see the section on "Certificate Configuration".

SSL and Load Balancers - Sessions

SSL gets along great with load balancers, but if you're having issues with application sessions being killed or users unexpectedly logged off, you'll need to look for a load balancer configuration to maintain SSL sessions.

SSL and Load Balancers - Spotty Off and On Errors

If you're seeing problems with SSL and some load balanced servers, but it isn't consistent, then the most likely culprit is that one or more of your servers behind that load balancer has one of the above errors, such as expired or mis-configured certificate. You'll have to check all of your servers to find which ones are not working correctly, and hopefully you have monitors on all of them so that will be easy to do.

Also remember to check ACLs, I've seen cases where new servers were added to a load balancer configuration, and the SSL was working perfectly on those servers, but the IT people forgot to register those servers in the ACL (on either end of the transaction).

Links and More Information

Here's a very detailed image of the SSL Handshake. Click the image to go to the full-size version (2081x1853) .

Links:

• What is a Root Certificate
• Java tools for managing SSL certificates
• Invaluable guide to debugging SSL connections for Java
• SSL protocol overview here here and here
• Certificate Authority

I saw a notice announcing a new release of Apache Tomcat Native this morning, and when looking at the page, saw the usual notice, as follows:

"Use the links below to download Tomcat Native from one of our mirrors. You must verify the integrity of the downloaded files using signatures downloaded from our main distribution directory."

That made me wonder how many people who download actually do verify the integrity of their downloads? I know I do, but I've worked with developers who don't. It would be interesting to do a poll on that. I'd also be interested in knowing of any cases where the integrity verification failed. I've never had one fail.

This is an excellent, excellent list of very common programming errors that can and should always be easily avoided by the use of common sense and paying attention to what we're doing. They're presented in three categories: Insecure Interaction Between Components (think XSS), Risky Resource Management, and Porous Defenses.

CATEGORY: Insecure Interaction Between Components

• CWE-20: Improper Input Validation
• CWE-116: Improper Encoding or Escaping of Output
• CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
• CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
• CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
• CWE-319: Cleartext Transmission of Sensitive Information
• CWE-352: Cross-Site Request Forgery (CSRF)
• CWE-362: Race Condition
• CWE-209: Error Message Information Leak

CATEGORY: Risky Resource Management

• CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
• CWE-642: External Control of Critical State Data
• CWE-73: External Control of File Name or Path
• CWE-426: Untrusted Search Path
• CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
• CWE-494: Download of Code Without Integrity Check
• CWE-404: Improper Resource Shutdown or Release
• CWE-665: Improper Initialization
• CWE-682: Incorrect Calculation

CATEGORY: Porous Defenses

• CWE-285: Improper Access Control (Authorization)
• CWE-327: Use of a Broken or Risky Cryptographic Algorithm
• CWE-259: Hard-Coded Password
• CWE-732: Insecure Permission Assignment for Critical Resource
• CWE-330: Use of Insufficiently Random Values
• CWE-250: Execution with Unnecessary Privileges
• CWE-602: Client-Side Enforcement of Server-Side Security

Read the full article and please use this list on your next software project. If you need further information and/or assistance in securing your code, OWASP is a great resource, check them out and help to support them.

Now you may be wondering, "so who do you meet?" Well, I'd say the majority are security consultants of one form or another. A few are principles of companies that perform security audits, some build software to sell for promoting better security. Last night at the meeting I attended, I sat next to a PCI Compliance consultant and so I added a little to my knowledge about that. I also tend to meet system administrators, but usually they're higher up the ladder and not the guys down in the trenches, but I'm not sure that's always true. Also, keep in mind that I'm not the most outgoing social butterfly you'll ever meet, so there could easily be other developers there and we just don't meet up.

The meetings I've been to have covered some fascinating topics, often focusing on XSS attacks, but not always. They've been a bit scary, too. I tend to go home and start looking for new ways to lock down all of my computers. Last night's meeting especially compelled me to focus on that! I wish that other software developers would discover these meetings and find them to be as intriguing as I do.

(P.S. I'll give more details about that meeting in another post - it was memorable.)

First off, I want to say that the local chapter here is doing a great job of setting up meetings and finding interesting speakers. This meeting was combined with the San Francisco chapter and was held at the eBay offices. In fact, the plan is for all future meetings to be combined. They had a free meal for everyone, which was quite nice and they didn't forget about vegetarians, either. That included assorted beverages and beer, too. They also had free t-shirts: OWASP shirts, and the moderator of the privacy panel had shirts from his company to give away. It was a great deal from the standpoint of freebies.

The speaker presenting the malicious code injection had quite simple slides. The real impact was in the words he said, which can probably be summed up as "be very, very careful - you can never be too careful". He had an example online banking site as the victim of his XSS exploits. He didn't have time to cover everything, and so he pointed everyone to the infamous RSnake XSS Cheat Sheet. That wasn't the first time that's been mentioned at OWASP meetings, but probably it can never be mentioned enough. The bits that struck me the most about the presentation were the talk about SSL proxying, his comments that root kits are so sophisticated nowdays that no one can detect them, and his closing statement that he wipes his OS probably about every two weeks and reinstalls - that's how paranoid he's become - the expert! Yikes!

Then we were on to a panel discussion about online privacy. I actually thought it was going to be boring and was plotting my escape, but I was so wrong. The panelists were great. The questions were mostly driven by the audience, and many kept going back to the Electronic Frontier Foundation lawyer (whose name I didn't write down and it's not listed in the OWASP website). He was fascinating to listen to. The other panelists were great, too. I especially enjoyed the points of view raised by Larry Pingree of Safeway and a very knowledgeable gentleman from Kaiser Permanente. The main bit of information I took away is this: don't ever give any more information to anyone than you absolutely have to and especially don't give it out to anyone not in the United States (this was from the perspective that we were in the US, of course), because as much as we may complain about invasions of our privacy here, we have it the best here of anywhere else in the world.

Overall, it was a great meeting, 5 thumbs up. Now I have to go lock down some more computers. Hmmm, maybe I could convince the neighbors to let me in to tweak theirs just a little...