WebsiteBaker Community Forum
General Community => Global WebsiteBaker 2.8.x discussion => Topic started by: crnogorac081 on January 12, 2011, 04:22:54 PM
-
Hi,
as previously discussed here: https://forum.WebsiteBaker.org/index.php/topic,20434.25/topicseen.html#bot
I am opening this thread for discussion about session security.
Here is the summary of related reffered topic:
I found this script which can crypt session variables based on predefined random key. At this point, for user_id == 1, we have declared $_SESSION[USER_ID'] on login, and $_SESSION[USER_ID'] = "1"
What this script does, is crypting the value, and $_SESSION[USER_ID'] crypted will look like this:
BzQAYFMxAzRTYA==BzMAYFM9Azc=BzIAYVM5AzY=BzQAYlMwAz5TaA==BzQAYFMxAzRTYA==BzQAYVM6AzdTaA==Bz0AYFM5Az8=BzQAYlM/AzBTZw==BzQAYFM4AzBTYQ==Bz0AZlM7AzQ=BzIAYVM5AzY=BzAAaFM4AzM=BzQAY1M7AzdTYQ==BzIAaFMxAzI=BzIAZFM4AzQ=BzIAZFM4AzQ=
instead of
1
The concept is to include this script into code (potentialy like this, or in some other maner):
// 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 ????
}
and when a user logs in, to crypt sessions in class.login.php (for start, and then in other files where session is declared):
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
And in other files:
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;
}
}
Now, there are several questions to be answered:
Did you have experience with session forgeries (as user or server holder), do you think it is potential voulnerability for wb(now or in near future), do you think it should be included in core ? Do you know if other cms have something like this ?
what are your thoughts about this?
cheers
Ivan
[gelöscht durch Administrator]
-
Many years ago, when beginning with Perl programming and learning about CGI, there was a guiding principle: "Trust the user, but not the data." (Some also shorten it to "Don't trust the user", but this sounds a bit too hard in my ears.)
Today, security is much more important than back in the 90's - more computers, more hackers, to break a complex subject down to something very simple.
So, ANY move to improve the security of web applications is a good thing and should be done. Securing sessions is just one step.
In the past, I have experienced some website hacks, but none of them with WB. (But, of course, I don't have hundreds of WB installations like other guys.) AFAIK none was caused by session forgery. Anyway, I still think there are many security leaks concerning sessions in WB - also found them in the code of WB 2.9. But, securing the session itself is just one step - you will also have to check the session data. This step is missing very often. (Also for form data.)
Perl has a feature called "taint mode". If you add the -T flag to the shebang, it will no longer allow to use data that came from "outside" without checking it. For example, it won't allow something like this:
my $arg=shift; # get parameter from command line
system($arg); # and execute it as a system command
BOOM!!!
(See here for more details http://www.webreference.com/programming/perl/taint/)
But, to get back to your question: Yes, I think session security should be added to the core, but I would go much further than just encrypt the session data.
-
it would be an interesting to hear what people from core development and security think about this suggestion ?
cheers
-
I can't see how encrypting session data helps whith any session based security problems?
-
Encrypting the session id would help (a bit). Encrypting session data that goes to the browser also does.
-
Encrypting the session id would help (a bit).
The session id(sid) is a uniqe cryptic number that is send from server to client and back via cookie.
So where is the difference if you send it directly or encrypted. If an attacker gets his hand on a session id or on an encrypted string representing the sid , in both cases if he manages to send this data from his own browser, he captured the session. So as far as i can see it helps nothing?
Encrypting session data that goes to the browser also does.
Please explain why session data should be send to the Browser? Session data is processed by the php script and the results are send to the clients browser.
Maybe i am entirely wrong, so please explain.
-
Encrypting session data that goes to the browser also does.
Please explain why session data should be send to the Browser? Session data is processed by the php script and the results are send to the clients browser.
Sometimes, Session data is sent to the browser as hidden fields (for multi-page-forms, for example).
-
In that case it is form data, not session data.
Or am I missing something?
-
In that case it is form data, not session data.
Or am I missing something?
You are right, Ruud. Form data is saved in the session, in this case, because a session is the place where to save data belonging to a session ON THE SERVER. When form data is also a part of the session data this does not mean that session data is sent to the browser.
Of course, a malicious module could send the entire session data to the browser, but no one would install such a module (at least when someone tells him what the module does).
-
And the same malicious module could first decrypt any encrypted session data, because that would be part of the framework.
-
Hi,
thanks for supporting this discussion.
Can a loged in user (who is set in group without other priviledges, just to log in and change preferences) somehow preview or exploit session variables by attacking with script on his remote server..or something ?
-
Can a loged in user (who is set in group without other priviledges, just to log in and change preferences) somehow preview or exploit session variables by attacking with script on his remote server..or something ?
Already we fixed a lot of this vulnerabilities. It really can be that there are more of it and we searching for.
But if you like to get a 100% guaranty... nobody can give it... no one software can give it.
Do not forget: We can speak for the core only! We have no direct influence on all the modules which are available!
Anything between [echo/print] and [$_POST/$_GET] is a battlefield.
Anything what's received from there must be sanitized and validated. Anything what's received from there must be sanitized and validated. Anything what shall pass through this battlefield must be covered.
If you follow this rules, it never depends what data it is. If 'normal' variables or data out of a session.
A Session itself never will be send to a browser(expect the sessionID). The only one you can send is a copy of the session data, nothing more.
Remember: Session handling is a process inside the server only.
WB2.8.2 provide powerful tools to secure your data (FTAN + IDKEY). You must use it only.
WB2.9 will have a completely new coded authentication and session handling too. (it's not possible to implement in 2.8.2 also, because it needs too much changes.)
-
It is possible to secure 2.8.x "from outside". (Not 100%, but more than nothing.) See secure.websitebaker s.com to see how and how to help.
-
Don't forget to mention that if you need full protection for your form Data there is already a way to encrypt your transmission. Get a certificate and use https:// :-D
-
Get a certificate and use https:// :-D
Yea right, cheaper and better way is to get my own server :)
-
Your own Server does not have an automatic SSL-certificate
and selfsigned certificates result in a browser warning.
You can get your own SSL-certificate for as low as 79€/year.
-
Or just use 2.8.2 when it's ready - there are more encryptions then encrypted encrypted (no, it's really written twice, no bug) sessions. :wink:
SSL certificates you can buy e.g. here http://www.psw.net/ssl-zertifikate.cfm - but the question is of course, if that's necessary for private sites...
-
You can get your own SSL-certificate for as low as 79€/year.
Or for free at cacert.org ...
cheers
Klaus