[RESOLVED] Validation? the more the beter.

[Zpixel]

I have fairly secured web page navigations by means of sessions and server variables.

session_start();
if(!isset($COOKIE['PHPSESSID']) || $SESSION['session_check']!='admin_login'){
echo "<meta http-equiv='refresh' content='0;url=index.php'>";
exit;
}
session_regenerate_id();

---

if (substr_count($_SERVER['HTTP_REFERER'],$_SERVER['SERVER_NAME'])!=1){
echo "<meta http-equiv='refresh' content='0;url=index.php'>";
exit;
}

these may seem basic to a pro. how can i make it stronger?
by what percent do you think it is secure against attacks?
what about faking of 'SERVER_NAME' or session hijacking?

and any piece of code to make the code more reliable?
thanks.

[bradgrafelman]

The SERVER_NAME index is provided by the webserver AFAIK, not anything the user sends in the headers/data.

Also, note that if you make your application(s) depend upon the "Referer" header, you might be blocking legitimate requests; the Referer header is not only easily faked, it's optional in the HTTP standard and some proxies/firewalls/caching servers even strip the header automatically.

[dagon]

replace meta refresh with header(), some one else can point out all the other errors :-)

[dagon]

i picked this up somewhere and have been using it lately, fora little extra security

//little aqdded security to reduce session hijacking atempts
		if(isset($_SESSION['HTTP_USER_AGENT'])){
			if($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT'])){
				/* Prompt for password */
				return false;
			}
		}else{
			$_SESSION['HTTP_USER_AGENT']= md5($_SERVER['HTTP_USER_AGENT']);
		}

[NogDog]

dagon;10904187 wrote:

i picked this up somewhere and have been using it lately, fora little extra security

//little aqdded security to reduce session hijacking atempts
		if(isset($_SESSION['HTTP_USER_AGENT'])){
			if($_SESSION['HTTP_USER_AGENT'] != md5($_SERVER['HTTP_USER_AGENT'])){
				/* Prompt for password */
				return false;
			}
		}else{
			$_SESSION['HTTP_USER_AGENT']= md5($_SERVER['HTTP_USER_AGENT']);
		}

The problem with that is that the user-agent header can vary from request to request for legitimate (or at last non-malicious) reasons. I believe IE7 is somewhat notorious for this, and it might also be an issue with requests via proxies. Also, it would not be difficult for a hacker to guess at the most common user agent headers. Perhaps a token approach might be in order?

session_start();
if(!isset($_SESSION['session_check'])     ||
   $_SESSION['session_check'] != admin    ||
   !isset($_SESSION['token'])             ||
   !isset($_COOKIE['token'])              ||
   $_SESSION['token'] != $_COOKIE['token']
) {
   session_regnerate_id();
   // go to login
   exit;
}
$_SESSION['token'] = md5(uniqid('', true));
setcookie('token', $_SESSION['token'], 0, '/');

[Weedpacket]

bradgrafelman wrote:

The SERVER_NAME index is provided by the webserver AFAIK, not anything the user sends in the headers/data.

The headers in the $SERVER array that come from the user's http request are those that are prefixed by "HTTP": so those are the ones you really can't trust.

[Zpixel]

Thank you all for your helps.
So i think the code NogDog wrote is an ultiamate and engages an intruder with many troubles.

of course it's not also bad to produce 'session_check' using MD5 and store it in a database and then refer to that value using database queries. in this way, even the programmer onself can't hack his/her program. Am I right?

[Weedpacket]

Zpixel wrote:

of course it's not also bad to produce 'session_check' using MD5 and store it in a database and then refer to that value using database queries. in this way, even the programmer onself can't hack his/her program. Am I right?

What would be the point? it's not the user who is supplying the value, it's the application. So if the application is going to hash "admin_login" to get "a3107e4d4ae0ea783cd1177c52f1e630" then it has to already have "admin_login" stored somewhere.

And if it doesn't, and it's only storing "a3107e4d4ae0ea783cd1177c52f1e630" all the way through then there's no hashing to do and therefore no hashing is done, and the fact that the string is "a3107e4d4ae0ea783cd1177c52f1e630" and not "admin_login" is irrelevant.

[Zpixel]

for example:

$former_id= $_SESSION['session_id'];
$result=mysql_query("SELECT * FROM session_table WHERE (id=$former_id)");
$row=mysql_fetch_array($result);
$former_session_check=$row[1]; //$row[0] is the same $former_id

if($_SESSION['session_check']!=$former_session_check){
header("........");
exit;
}

$new_id=mt_rand(0,10000); //or somthing better
$new_session=MDF5($former_session_check);

$SESSION['session_check']=$new_session;
$SESSION['session_id']=$new_id;
session_regenerate_id();

mysql_query("INSERT INTO session_table (id,value) VALUES ('$new_id','$new_session')");

session_table has two columns:

id => to store session_id
value => to store session_check

How does it sound?

[Weedpacket]

Yes, there is a better way of generating random numbers ([man]mt_rand/man, for example), but what are you going to do about collisions?

Any particular reason you're not retrieving database records by name instead of (notional) position in the record set?

Any particular reason you're using $_SESSION['session_id'] instead of using the session ID?

[Zpixel]

record sets are being retrived by their uniqe id. Producing id has to be based of a better way rather than mt_rand to make a realy uniqe number. therefore no collisions will occur. This way of producing id numbers assures that everything is random and even id number is not predictable.

no perticular reason except to make everything random. 'session_id' is the same random id, and if session_id is a predefined php variable, then lets name it for example old_id.

of course, record sets that have more than 1 houre life long have to be deleted by a query.
is it worth the toil?

[Weedpacket]

Your English is breaking up.

Zpixel wrote:

record sets are being retrived by their uniqe id. Producing id has to be based of a better way rather than mt_rand to make a realy uniqe number. therefore no collisions will occur. This way of producing id numbers assures that everything is random and even id number is not predictable.

None of that seemed to answer my question about what you'd do about collisions.

Zpixel wrote:

no perticular reason except to make everything random.

I don't think "let's just make it more complicated for the hell of it" is a good way to design a defence.

Zpixel wrote:

is it worth the toil?

I don't see what you hope to gain by it. Once someone is logged in all you're getting from them on each request is the session ID. All the rest is just you playing with numbers.

[Zpixel]

well, thanks. It's better for me to give up. collision is needed in real life. thanks again for your time and patience.