Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Re: CMS Security]



Dan Ritter wrote:

> On Thu, Dec 31, 2009 at 10:39:43AM -0500, Fred at PlanetaryServer.com wrote:
>   
>> Dan Ritter wrote:
>>     
>>> you should assume that no CMS framework is offering any security at all.
>>>
>>> Oh, sure, they all have at least an idea of protecting pages from view or
>>> edit. But their programmers weren't thinking of your threat model. They're
>>> thinking "Wow, if a large site gets violated, they might have to restore
>>> from backup. That could be painful!".
>>>
>>> This won't do if you are playing with real money. Worse if you are
>>> playing with access details for direct deposit systems.
>>>
>>>   
>>>       
>> Of course, if this site is set up so that it can only be access via a 
>> VPN, then the security question is contained to how secure the VPN is, 
>> thus eliminating any potential flaws in the CMS itself.
>>     
>
> This statement is extremely wrong.
>
> A well-implemented VPN provides protection against eavesdropping
> on the network connection, and perhaps some degree of network
> access control. It's not a magic security wand.
>
> It certainly does not eliminate any flaws in the CMS. Suppose
> any authorized user can edit any page, through an unintentional
> hole. Suppose an authorized user can steal the credentials or
> the effective use of another user. Suppose there is no or little
> protection against password guessing. Suppose... x1000.
>
>
> -dsr-
>   
I should have qualified that statement. "Assuming the user authorized 
can be trusted."

As far as I'm concerned, if you can't trust the people you give access 
too, all bets are off anyway.

This also assumes that there are no critical software flaws (bugs) that 
would distort data or inadvertently allow access to a restricted area. 
This is where testing (QA) comes into play, and again, if you don't do 
that, all bets are still off.

But to prevent an unauthorized person (read: not authorized with VPN 
access) from exploiting potential flaws in the CMS, VPN is effective 
(again, assuming all the proper secure practices for establishing a VPN 
are in place).

Sure, if there is a flaw in the CMS and you can't trust your employees, 
the VPN isn't going to matter diddly. I assumed that was obvious and 
didn't need to be stated.

-Fred











BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org