One of the most common configurations out there is related to allowing web2project users to have access to only specific companies. While it's not as simple as saying "users should only see things from their own company," it's not as complicated as you might think. Here's how I've done it for various groups.

If you start with the basic roles, here are the step by step directions:

Role: Project Worker

Non-Admin Modules - Allow - Access, Add, Delete, Edit, View

Companies - Deny - Access, Add, Delete, Edit, View

Reports - Allow - Access, Add, Delete, Edit, View

Explanation: This gives access for a User to do anything they want on any of the non-admin modules *except* for Company. But since all of my Projects are assigned to a company, they can't actually see anything other than the navigation menu and empty screens.

This is the third of what is intended to be a three part series. To catch up, read "Social Media for Social Evil - Part I: Impersonation" and "Social Media for Social Evil - Part II: Network Analysis". Since some of the darker parts of the web have been doing these things for *years*, I'm going to cover them in great detail here. Hopefully people can take steps to better protect themselves. Anything detailed here that might be illegal is neither condoned nor encouraged by me, anyone I work with, nor my ferocious kittens. I highlight it here for analysis only.

At this point, most of us use some form of online banking. Part of the "security" on these sites is a series of questions like:

• What is your mother's maiden name?
• What was your high school mascot?
• What is your favorite color?
• Where did you go on your honeymoon?
• Who is your favorite author?
• What street did your best friend live on in middle school?

I suspect you see where I'm going with this...

Take a quick spin around your friends' profiles on Facebook.

No, go ahead. I'll be here when you get back. Seriously, I'm not going anywhere.

This is the first of what is intended to be a three part series. I've used this space to talk about the concepts of Open Source Intelligence using Social Networks with the early analysis focused on LinkedIn (Part 1, Part 2).

This weekend when Mike Arrington created a fake Eric Schmidt (CEO of Google) on Facebook, I was reminded of a few other attacks. He put a tiny new spin on it by using a believable email address but he missed some subtle cues that could have made it much more convincing and therefore devastating.

First of all, the style of attack that Mike did is pretty old news. Since some of the darker parts of the web have been doing these for *years*, I'm going to cover them in great detail here. Hopefully people can take steps to better protect themselves. Anything detailed here that might be illegal is neither condoned nor encouraged by me, anyone I work with, nor my ferocious kittens. I highlight it here for analysis only.

Late last month, I received some bad news about web2project...

It turns out that web2project was vulnerable to a handful of select Cross Site Scripting (XSS: definition) vulnerabilities. While the attack vector was pretty specific to being an already authenticated user, it had the potential to be a major problem in a poorly configured system.

On the positive side, I say "was" because within 10 days of being notified of the problem - and the same day the vulnerability became public - we had a patched release out the door and available to users. We've spent the past month since encouraging them to upgrade. Of course, we further benefit from the fact that although the vulnerability does affect us, we're not named in the report.

Last week, I was teaching the Security Class for php|architect and talked not only about protecting your applications from security vulnerabilities but what to do after you've found (or have been notified of) one.

Unfortunately, I have some bad news for you, it's not a question of "if" you'll have a problem, but a question of when.

Depending on the type and scope of the vulnerability, this can range from "doh" to "call the lawyers and update your resume".  Either way, it can be a disaster.

And we all know there are two times to come up with a disaster recovery plan:

Before it happens OR

While it's happening... oh wait, that's not planning.

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world.  They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads:

Don't Trust the Users

It may sound harsh but:

It's not that they're malicious, though they might be...

It's not that they're incompetent, though they might be...

It's not that they're ignorant, though they might be...

In fact, there's absolutely nothing "wrong" with 99.9% of your users... or maybe even 99.999% of your users.  But all it takes is one user with any of the above qualities combined with a poorly designed application and you're going to have a bad day.  For lack of being able to say it better, I defer to Chris Shiflett and use his phrase (with credit of course):

Filter Input, Escape Output