Users Don't Value Their Own Data

One area of security I find very interesting is establishing secure SSL connections through malicious environments. Ie you should be able to do your online banking from a coffee house, but often there are subtle security mistakes made by the user, browser or website.

All of this is in the spirit of protecting information and providing a secure connection. However, perhaps I'm missing the point....


It's Monday morning and I'm sitting in my local Caribou Coffee House to get some work done. The place is almost completely full. There are a variety of telecommuters, a few people with the newspaper, and two guys dressed in slacks and dress shirts at the one larger table.

Apparently these two have started their own advertising business and work wherever makes sense. Why do I know this? I know this information and quite a bit more because they applied for a credit card for the company while they were here at the coffee house.

Did I man in the middle their application or monitor unencrypted wireless communications? Nope, I listened - with my ears. The guy applied for a credit card over the phone at a fully packed coffee house. I now know his name, address, SSN, previous employer, salary and their new company info. Btw, they are on their second year so they must be making some money.

This is all a little disheartening. If our users don't value the privacy or security of their own information, or are too ignorant to think they shouldn't announce it to the world, then how can we secure their information online? Better yet, if they aren't going to try, why should we?


-Michael Coates

Vulnerabilities vs Insecure Software

If your software has vulnerabilities then you should use a security specialist and developer to resolve those vulnerabilities.

However, the recurring presence of vulnerabilities, means you have insecure software and you need to fix your SDLC, provide security based developer training and enhance the security review process.

Lastly, if you don't know if you have vulnerabilities, then you are at square one.

• Assess to discover vulnerabilities
• Analyze to determine root cause
• Remediate technical vulnerabilities
• Address root cause in the overall process
• Rinse and Repeat

-Michael Coates

Universities & Web App Security

I'm interested to know what universities out there are offering classes which address web application security? We know we need to do more to educate students in computer science programs, but who is attempting this already?

I came across one class at Northern Kentucky University that has a pretty nice looking web app course which even utilizes the OWASP Live CD for a black box penetration assignment. Looks like a good course which covers the all the main areas. (course schedule)

What other universities are offering this kind of material? Let me know.

-Michael Coates

SSL - Who's To Blame?

There seems to have been quite a bit of discussion on SSL over the past few months. I've contributed my two cents to the discussion with recent posts (Compromising HTTP to HTTPS redirects, SSL is out of control, MD5 Collisions Allow Forged SSL Certificates, Pruning the Browser's Web of Trust).

Now I'd like to tackle a different issue with SSL - who's to blame? And by assigning blame I mean, who should the responsible party be to ensure SSL is handled correctly?

As I thought about different scenarios I decided that there are three main culprits.

1. The Website
   
2. The Browser
3. The User

The Website
Websites tend to shoulder most of the blame when something goes wrong with SSL. In many cases it is warranted. Any site that is conducting business should get their certificates right. Mismatched domain names, expired certs, mixed SSL and non-SSL content, or non-SSL landing pages are all common mistakes and are unacceptable. These issues point to a poor management of security. And that's the main take-away in my opinion. If site can't handle these basic SSL issues, which are fully visible to all of their users, then what else is going on behind the scenes? I will issue the challenge I issued in a previous post. If you stopped using a site once you encountered any sort of SSL error message - how many sites would you actually be able to use?

The Browser
For some reason the browser has hidden away from criticism in the SSL discussion. I believe they are one of the largest contributors to the problem. Imagine if you approached an elevator and there was a sign saying "Elevator cable may snap, would you like to proceed?". That is what the browser is doing with SSL. And the fact that the browser allows users to continue is partly the reason some many sites have SSL issues. Sites would probably address the SSL issues faster if they knew users couldn't reach the site because the browser blocked an insecure connection.

I expect more from my browser. I'd like my browser to do things securely or not do them. I don't want a semi secure connection. When I connect to a website over HTTPS I want the connection to be rock solid. Don't connect to the site if the cert is bad - no matter what. And don't transfer cookies over HTTP (btw, why is this the site's resposnibility to set the "secure" flag, shouldn't that be the defacto handling by the browser). The list goes on.

The other main concern here, is again, this is only what the browser is telling us. There are plenty of other issues going on behind the scene which we don't know about. Remember the SSL mixed content warning? The browser doesn't say which sites the content is from. Clicking continue to this message could very well result in your cookies going over HTTP - and then its all over.

Lastly, I don't think its realistic to expect the average Internet user to be an expert in SSL, networking and security. I say this because these are the skills which are necessary to effectively evaluate whether or not to click "ok" to the SSL warning messages. In fact, I believe that most every SSL warning message from the browser is expecting an unrealistic amount of knowledge from the user. What good is prompting the user if the question doesn't make any sense? This is why I say the browser should do things securely or not do them at all. If you can't get to your bank's website - then good. It woud be insecure to access it anyway.


The User
The last one to blame in our list is the user. In many cases, no technical controls will stop an uneducated user from doing something stupid. And I agree here. If the user provides their passwords to anyone that asks then their is nothing we can do to stop them. Also, if a user types in "mybank.com" and magically hopes they will end up at the secure site, then they are to blame too. I agree that it would be great if things worked that way, but they don't. You have to actually type https every single time. (see Compromising HTTP to HTTPS redirects)

But if we start to fix the websites and the browsers, then we can create a more realistic level of information which we can expect from our Internet users. But in our current situation, can we really get that upset at the average user? What a mess the websites and browsers have created.

-Michael Coates