2.8.2 release projection?

[crnogorac081]

yes it is mate, but I still didnt forget to include $ftan = $wb->getFTAN(); before the forms. I folowed your instructions as you wrote

it looks like I dont have luck with this..

[PurpleEdge]

WebsiteBaker 2.8.2 is quite secure, but the biggest security flaw is always the server. Just secure your server, then WB is - in most cases - quite safe.

I know it is a big question, which is why I ask, what are the top things to do to secure a WB server?

[crnogorac081]

I am also curious, can $_SESSION['USER_ID']; and other sessions in wb be faked by other self use, by other registered users, and by not loged user?

cheers

[testör]

I know it is a big question, which is why I ask, what are the top things to do to secure a WB server?

Well, it's more securing a server in general - doesn't matter which software running.
It's very hard to give here advice, because it depends on that much (which OS / derivatives, ...) and then most people don't have access to the server root.
In short it's just: Are you satisfied with your webhoster (if you don't have a root server your own). Do the guys seem to know what they are doing?

The other:
- Don't give anybody root FTP access you aren't 100% sure.
- Don't give any access (WB access, FTP access, server access) via internet forums (also PM, every server could be hacked) or even public. E.g. a "WB test site" with root access (they exist) is really heavy risk - everybody could take controll with installing "godmode" modules.
- Only give access to WB backend to people you are sure of.
- Don't install too much modules and check them (e.g. once all 3 months) if there are new versions. If they are outdated a long time - try to guess if they could be a security flaw or if they are needed.
- Don't post anywhere in WB installations / hidden or restricted pages / droplet code etc. accesses, e.g. to the database.

[DarkViper]

I know it is a big question, which is why I ask, what are the top things to do to secure a WB server?

one of the most important rules is to DENY anything...
then ALLOW these services only, which are absolutely important for working.
a 'can be needed in future maybe' should be a DENY
How to realize, this depends from your server and it's environment. (OS, software, network environment and a lot more ..)
A standard XAMPP installation definitely is very unsure. You can find these warning on the website of ApacheFriends too.

I am also curious, can $_SESSION['USER_ID']; and other sessions in wb be faked by other self use, by other registered users, and by not loged user?

Right now the session handling is working. Security? It makes me crying. But we are working on it.  
It's like an old car... in past there was no airbag, ABS, ESP, crashzones, and much more... we have a lot to do.

On the other hand, you can't find a 100% safety.
Last night i had big trouble to remove a BlackMailer from one of my servers. The server itself was safe...  but the PC of a customer was infected by a keylogger and thereby the FTP account of the customer was compromised. So the trojan was able to upload itself.  

[crnogorac081]

Hi,

how can I protect $_SESSION['USER_ID'] and my other sessions form being hacked ?

cheers

[crnogorac081]

Hi,

I am answering to my own question and I feel silly, but I found interesting class script which can crypt/decrypt session variables, and I think it would be interesting to include it in the core.
It works like this:

Code:

// to set session
$sess = new LsmCryptSession();
$sess->_setSession("user_id","1");

// to get session
echo $sess->_getSession("user_id");
// it will echo "1"

if you echo $_SESSION['user_id'] previously crypted, you will get an array, which will printed look like this:

BzQAYFMxAzRTYA==BzMAYFM9Azc=BzIAYVM5AzY=BzQAYlMwAz5TaA==BzQAYFMxAzRTYA==BzQAYVM6AzdTaA==Bz0AYFM5Az8=BzQAYlM/AzBTZw==BzQAYFM4AzBTYQ==Bz0AZlM7AzQ=BzIAYVM5AzY=BzAAaFM4AzM=BzQAY1M7AzdTYQ==BzIAaFMxAzI=BzIAZFM4AzQ=BzIAZFM4AzQ=

to me it looks neat, and I am going to try to include it in my project to protect my wb from potential session forgery.

Now, could someone please help me how to include it in core, is this the way:

Code:

// to pot this code at the bottom of class.wb.php before ?> tag ?
require_once(WB_PATH."/framework/LSMCrypSession.php");
class wb extends LsmCryptSession {
// there is no code here at all or there is  ????
}

I think that it would be easy to inplement, as all sessions are defined in class.wb.php and class.login.php right ?

also, please let me know what you think about this ?

cheers

[BlackBird]

I know it is a big question, which is why I ask, what are the top things to do to secure a WB server?

See here for a tool that can help you: http://phpsec.org/projects/phpsecinfo/

[Paul - Westhouse IT]

A common problem is users who use "root" access for daily use of a system. In WB that means using a full admin account even when all you're doing is managing content.

When you first install WB create a new group for content editors and an account for yourself. This group should have only content editing access. Then log out of your admin account and use your "content editing" account for normal access. Then when you need to do admin things you can log in using your admin account and log out as soon as you're finished.

This will prevent the most common CSRF attacks from working.

Essentially think of CSRF as "an attacker can do (almost) anything I can" and limit your account accordingly. The same goes for any users you create who access your site.

Automated backups should then cover you for most content related breaches.

[crnogorac081]

hi,

could someone please check my post related to session forgery ?

cheers
i.

[PurpleEdge]

@crnogorac081  The link from BlackBird has an interesting library, you might find the answer there...

http://phpsec.org/library/

[BlackBird]

Now, could someone please help me how to include it in core, is this the way:

Code:

// to pot this code at the bottom of class.wb.php before ?> tag ?
require_once(WB_PATH."/framework/LSMCrypSession.php");
class wb extends LsmCryptSession {
// there is no code here at all or there is  ????
}

Creating a class by extending another one makes the new class inherit methods and class data. So, in this example, the class "wb" will inherit methods _setSession() and _getSession() from class "LsmCryptSession". This will only help if there's some code later that uses $wb->_setSession() and/or $wb->_getSession() to handle session data.

On the other hand, if the class "wb" already defines methods _setSession() and _getSession(), they will overwrite the inherited methods - so extending the class "LsmCryptSession" would have no effect.

Anyway, the class "wb" accesses the global var $_SESSION directly very often, for example:

Code:

<?php
// Check if the user is already authenticated or not
function is_authenticated() {
if(isset($_SESSION['USER_ID']) AND $_SESSION['USER_ID'] != "" AND is_numeric($_SESSION['USER_ID']))
        {
return true;
} else {
return false;
}
}

or

Code:

<?php
// Get SESSION data
function get_session($field) {
if(isset($_SESSION[$field])) {
return $_SESSION[$field];
} else {
return null;
}
}

...and so on. You would have to patch all these methods to take advantage from using LsmCryptSession.

Edit: BTW: WB 2.9 still accesses $_SESSION directly.

Code:

// Check if the user is already authenticated or not
function is_authenticated() {
if(isset($_SESSION['USER_ID']) && $_SESSION['USER_ID'] != "" && is_numeric($_SESSION['USER_ID']))
        {
return true;
} else {
return false;
}
}

[BlackBird]

Here's an article worth reading.

http://shiflett.org/articles/the-truth-about-sessions

[BlackBird]

Just use SecureForm.php - you can use it with any WB-Version you like. Just add / adjust

Code:

require_once(WB_PATH."/framework/SecureForm.php");
class wb extends SecureForm
{

in /framework/class.wb.php and copy SecureForm.php in framework (or wherever you like, you can even make a module if adjusting require_once).

So how does this help? This just extends a class SecureForm. You will still have to patch the class "wb" to make use of the methods defined there.

[DarkViper]

So how does this help? This just extends a class SecureForm. You will still have to patch the class "wb" to make use of the methods defined there.

This statement is definitively wrong.
SecureForm is already a steady component of the Core(2.8.2) and (2.9.x) too. There is nothing to patch in class 'wb'.
The backend is moved already almost completely on it. The last changes are inserted nowadays by FrankH within the scope of the security-fixes. Also into some of the basically  modules.
For all the other modules it is the decision of the module authors to insert this additional security or just not.

[crnogorac081]

Hi all,

My idea is to extend wb class with this script and then in class.login.php to define sessions like this:

Code:

class.login.php:

function authenticate() {
global $database;
// Get user information
// $database = new database();
// $query = 'SELECT * FROM `'.$this->USERS_TABLE.'` WHERE MD5(`username`) = "'.md5($this->username).'" AND `password` = "'.$this->password.'" AND `active` = 1';
  $loginname = ( preg_match('/[\;\=\&\|\<\> ]/',$this->username) ? '' : $this->username );
$query = 'SELECT * FROM `'.$this->USERS_TABLE.'` WHERE `username` = "'.$loginname.'" AND `password` = "'.$this->password.'" AND `active` = 1';
$results = $database->query($query);
$results_array = $results->fetchRow();
$num_rows = $results->numRows();
if($num_rows == 1) {
$user_id = $results_array['user_id'];
$this->user_id = $user_id;
$_SESSION['USER_ID'] = $user_id;
// AND HERE INSTEAD $_SESSION['USER_ID'] = $user_id; to set session like this

wb->_setSession("USER_ID",$user_id);

// AND DEFINE ALL OTHER SESSIONS LIKE THIS

then, the next job would be to replace session variables in the core files (framework etc..):

Code:

FROM:
// Check if the user is already authenticated or not
function is_authenticated() {
if(isset($_SESSION['USER_ID']) AND $_SESSION['USER_ID'] != "" AND is_numeric($_SESSION['USER_ID']))
        {
return true;
} else {
return false;
}
}
TO:
// Check if the user is already authenticated or not
function is_authenticated() {
if(isset($wb->_getSession("USER_ID")) AND $wb->_getSession("USER_ID") != "" AND is_numeric($wb->_getSession("USER_ID")))
        {
return true;
} else {
return false;
}
}

what I am trying to accomplish is to crypt session variables from the core, and in addition, when creating modules to use $wb->_getSession("USER_ID") instead $_SESSION['USER_ID']

the final goal is to protect sessions from forgery ?

I am not an expert in this at all, but I read some articles about session forgeries and I got worried because I am working on a community site where multiple users would be loged in into site (set in group with no access to backend features, just an option to be loged in ).

So, for those with bigger experience, do you think that this protectionwould be usefull for WB, or not ?
if not, It would save me a lot of time to quit working on this

cheers

[BlackBird]

So how does this help? This just extends a class SecureForm. You will still have to patch the class "wb" to make use of the methods defined there.

This statement is definitively wrong.
SecureForm is already a steady component of the Core(2.8.2) and (2.9.x) too. There is nothing to patch in class 'wb'.

THIS statement is wrong. In WB 2.9, class wb extends SecureForm, but never uses any of the methods. (You know that it is not enough to extend a class, do you?) Also, the class (wb) still directly accesses $_SESSION, without checking the params for consistancy, so where's the security improvement?

Second, we still talk about securing 2.8.1 'til 2.8.2 or 2.9 are available. "testör" said it would be enough to make class wb inherit from class SecureForm, which is definitely nonsense.

[BlackBird]

My idea is to extend wb class with this script and then in class.login.php to define sessions like this:

Yepp. That's the right direction.

[crnogorac081]

So how does this help? This just extends a class SecureForm. You will still have to patch the class "wb" to make use of the methods defined there.

This statement is definitively wrong.
SecureForm is already a steady component of the Core(2.8.2) and (2.9.x) too. There is nothing to patch in class 'wb'.

THIS statement is wrong. In WB 2.9, class wb extends SecureForm, but never uses any of the methods. (You know that it is not enough to extend a class, do you?) Also, the class (wb) still directly accesses $_SESSION, without checking the params for consistancy, so where's the security improvement?

Second, we still talk about securing 2.8.1 'til 2.8.2 or 2.9 are available. "testör" said it would be enough to make class wb inherit from class SecureForm, which is definitely nonsense.

Hi mate,

SecureForm class(and file) is about securing form, and not sessions. What I am trying to do now is to deal with sessions securing.
I am sorry if I caused confusion because previous the sessions, I asked about SecureForm.

cheers,
Ivan

[BlackBird]

Yes, sure it is. Mixed that up a little bit, too, sorry for this.
The core of my statement still is: It isn't enough just to include or extend it. You will still have to make use of it. That's what "testör" missed in his post.
Anyway, I think it would be better to open a new thread for the session security thing, as the subject of this one is a bit misunderstanding.

[crnogorac081]

Hi,

new topic about securing sessions can be found here:

http://www.websitebaker2.org/forum/index.php/topic,20498.0.html

cheers