I just wanted to shed some more light on how we view these types of things here.

No system is perfect, ever. The only good security is a constant watch and dedication to the process of being alert, period. I know as a business and website owner security is important, and can be a real emotional trigger word to hear. It's important to ask yourself what that word really means with each situation.

Frequently I find myself pointing out that when you eat out, you hand your credit card to someone you've never met and will never meet again, and they take it off into another room for 5 minutes before bringing it back to you. Very few of us think twice about that, but it's very easy to make people panic when putting a credit card in to a web form. Which is an easier system to hack?

I just bring that up because I think it's very important to THINK about the details when someone starts using the words "security" , "vulnerabilities", "threat", etc.

Here's how we classify potential security risks around the office:

#1 - Direct Access Vulnerabilities
Someone, anyone, can use publicly available stuff to gain administrative access to your site. For example: in the very first alpha version of concrete5 you could put "/." in the password field and login as any valid user ID... That's a huge gaping hole, and we haven't had something like this in 3 years.

#2- System Disclosure Vulnerabilities
Someone can learn something about the environment your site is on. Perhaps it's the directory path your website lives in. Perhaps its the version of PHP you're running. These are not good things to have as a little knowledge in this vein can often open up new opportunities for a hacker. Still, keep your server updated and locked down following reasonable standards and this is a manageable threat.

#3 - Data Read Vulnerabilities
Someone can see data they're not supposed to. We hash our passwords and don't store credit card numbers in ecommerce. So while no vulnerability is a good one to have, the worst were talking about here is seeing legacy order history or data on pages you shouldn't.

#4 - Data Modify vulnerabilities
Someone can actually change, delete, or insert data into the system. If you could do it at the user access level we'd call it #1 a Direct Access vulnerability. A better example of a data modify would be if someone could change a guestbook comment to be owned by a different user. (hypothetical)

#5 - Page Render Vulnerabilities
Someone can change the URL field or input something into a form field so the resulting page load throws a SQL error, for them. It's not going to impact anyone but themselves, and only on their next page view.

So just to reiterate, I'm not saying any of these are unimportant, we resolve them all - I just want you to understand that "SECURITY HOLE!" is the beginning of a thoughtful conversation here, not the end.

Outside of these classifications we have on what you can actually achieve with a vulnerability, there are two terms you're likely to hear if you follow these things:

SQL Injection - this typically means putting something in a form field that makes the database behave in an unintended way. Typically any one can take advantage of it. That example I gave for #1 was a SQL injection hack. These are not good to have, and we haven't had an issue like this in a very very long time.

XSS or Cross Site Scripting - this typically has to involve some social engineering. The idea is to take advantage of one person's legitimate access to a website to do something else. So if I'm logged in as an admin to concrete5.org and a haxor kid sends me a URL "Hey check out these hot models from russia!" and I actually click it, while a specific dashboard page is open, and the planets align, it might run some code /as me/ that the hacker wanted to run. These certainly can be serious, as that code might give them admin access, but I maintain there's something about the letter X that makes the label a bit more "FIRE FIRE" panic-y than the reality actually is.

XSS and SQL injection are techniques, not end states. If you can use SQL injection to login as admin? That's a huuuuge problem. Can you use SQL injection to make the next page load return an error for yourself? Okay, that sounds like a sloppy corner we should clean up in the next version.

Again, I don't want anyone thinking we don't take these things very seriously, as Andrew pointed out most of them in that list this morning we're already addressed.