How some people can actually see the php source of i page!
Moderator: General Moderators
How some people can actually see the php source of i page!
Someone seen my php source for http://www.nikolas.tk and i dont know how he did it! sounds crazy! is there a tol for that?
Most common mistakes is to not proctect web access to files you include and such, anc if its filename is not .php it will be shown as plain text...
Another way is other users on the same shared-host can peek in any of your files that are world readable..
Exploits/vulnerabilities (poorly secured) scripts on the server may let someone peek in your files, it doesn't have to be scripts on your account/webspace, any on the same server..
Are there any other ways to hack to make apache not process as php? If so I would guess that should be considered a flaw in PHP or Apache?
Another way is other users on the same shared-host can peek in any of your files that are world readable..
Exploits/vulnerabilities (poorly secured) scripts on the server may let someone peek in your files, it doesn't have to be scripts on your account/webspace, any on the same server..
Are there any other ways to hack to make apache not process as php? If so I would guess that should be considered a flaw in PHP or Apache?
i dont actually know of any myself, but a guy on my MSN viewed my PHP source once and laughed at my copyright notice, i'll ask him what he uses.
I would say the best way to prevent password theft is to create a new .php file called:
db.inc.php
and inside it have $user = "username", $pass = "pass", then save that in a non HTTP accessible dir, for example, below /www folder. Then include it onto your pages. include( "/full/path/db.inc.php" ) and inside your mysql connection just use the variables.
That way if someone looks at your source, they will see the include and the variables $pass and $user, but no actual info.
I would say the best way to prevent password theft is to create a new .php file called:
db.inc.php
and inside it have $user = "username", $pass = "pass", then save that in a non HTTP accessible dir, for example, below /www folder. Then include it onto your pages. include( "/full/path/db.inc.php" ) and inside your mysql connection just use the variables.
That way if someone looks at your source, they will see the include and the variables $pass and $user, but no actual info.
Check out the php manual for how the encryption functions work (php.net).
Here's a couple of functions which process data from a login form and set a (time limited) cookie. There is a table called auth where names and passwords are stored. When a password is created, the password itself is used as the salt for crypt(). Even the database admin can't read the un-encrypted passwords.
Other functions (not listed here) would look for the cookie to decide if authorisation for such-and-such will be granted.
You could create randomly variable name cookies, store the cookie name in the auth table and delete it at logout: this makes it impossible to spoof cookies (I think) since the hacker never knows what the name will be - even if he CAN read your source code.
You could also improve things by checking against current IP in a similar way (ie storing current IP in the table) but still allow login from multiple machines by overwriting each time. I guess that would block a hacker who had sniffed a current, valid cookie. Even if he did, and there was no IP check to block the same cookie submitted from different machines, his spoofed cookie won't work after admin has logged out and destroyed the cookie (it's deleted from the auth table at logout and so no longer listed as a valid cookie).
[EDIT: I've just realised that if a hacker sniffs a cookie with a randomly variable name, he can get the encrypted pass then try to crack it offline. Although he can't (I think) spoof a randomly named cookie, with the real pass he can log on anytime to get a valid one. Randomly variable names might not be the answer. Oooh my head hurts.]
This is the first login script I've written so use it as a starting point not an authoritative guide. I haven't looked at sessions yet for example.
function login() {
unset($name, $user_pass);
$name = $_POST['name'];
$user_pass = $_POST['user_pass'];
$mysql = "SELECT * FROM auth where name='$name'";
$query = mysql_query($mysql) or die("Cannot query the database.<br>" . mysql_error());
$result = mysql_fetch_array($query);
$pass = $result['pass'];
IF (($user_pass = crypt($user_pass, $pass)) == $pass) { #don't forget to create pass's by salting with the pass
$value = "$user_pass";
/* NB: following line blocks cookie because it initiates page output!! Duh!! */
#echo "value is $value<p>";
setcookie("ooRU", $value, time()+7200); #cookie expires in 2 hrs
#echo '<A HREF="../../nav.php?page=admin_main">Cookie set now click.</A>';
header("Location: http://".$_SERVER['HTTP_HOST']."/"."/mcos_project/html/nav.php?page=admin") ;
} ELSE {
echo 'Password not recognised<p>';
echo '<A HREF="nav.php?page=admin_login">Try again.</A> | <A HREF="index.php">Home</A>';
}
}
function logout() {
//set the cookie expiration to -7200??
setcookie("ooRU", $value, time()-7200);
echo "You have now logged out.<p>";
echo '<A HREF="index.php">Home</A> | <A HREF="admin.php">/admin.php link - Can I open admin main logged out?</A>';
}
Here's a couple of functions which process data from a login form and set a (time limited) cookie. There is a table called auth where names and passwords are stored. When a password is created, the password itself is used as the salt for crypt(). Even the database admin can't read the un-encrypted passwords.
Other functions (not listed here) would look for the cookie to decide if authorisation for such-and-such will be granted.
You could create randomly variable name cookies, store the cookie name in the auth table and delete it at logout: this makes it impossible to spoof cookies (I think) since the hacker never knows what the name will be - even if he CAN read your source code.
You could also improve things by checking against current IP in a similar way (ie storing current IP in the table) but still allow login from multiple machines by overwriting each time. I guess that would block a hacker who had sniffed a current, valid cookie. Even if he did, and there was no IP check to block the same cookie submitted from different machines, his spoofed cookie won't work after admin has logged out and destroyed the cookie (it's deleted from the auth table at logout and so no longer listed as a valid cookie).
[EDIT: I've just realised that if a hacker sniffs a cookie with a randomly variable name, he can get the encrypted pass then try to crack it offline. Although he can't (I think) spoof a randomly named cookie, with the real pass he can log on anytime to get a valid one. Randomly variable names might not be the answer. Oooh my head hurts.]
This is the first login script I've written so use it as a starting point not an authoritative guide. I haven't looked at sessions yet for example.
function login() {
unset($name, $user_pass);
$name = $_POST['name'];
$user_pass = $_POST['user_pass'];
$mysql = "SELECT * FROM auth where name='$name'";
$query = mysql_query($mysql) or die("Cannot query the database.<br>" . mysql_error());
$result = mysql_fetch_array($query);
$pass = $result['pass'];
IF (($user_pass = crypt($user_pass, $pass)) == $pass) { #don't forget to create pass's by salting with the pass
$value = "$user_pass";
/* NB: following line blocks cookie because it initiates page output!! Duh!! */
#echo "value is $value<p>";
setcookie("ooRU", $value, time()+7200); #cookie expires in 2 hrs
#echo '<A HREF="../../nav.php?page=admin_main">Cookie set now click.</A>';
header("Location: http://".$_SERVER['HTTP_HOST']."/"."/mcos_project/html/nav.php?page=admin") ;
} ELSE {
echo 'Password not recognised<p>';
echo '<A HREF="nav.php?page=admin_login">Try again.</A> | <A HREF="index.php">Home</A>';
}
}
function logout() {
//set the cookie expiration to -7200??
setcookie("ooRU", $value, time()-7200);
echo "You have now logged out.<p>";
echo '<A HREF="index.php">Home</A> | <A HREF="admin.php">/admin.php link - Can I open admin main logged out?</A>';
}
Last edited by McGruff on Fri Jan 31, 2003 4:54 pm, edited 4 times in total.
Ooops ranting on about login when you want some ideas about database access variables.. I don't know any way to connect except by putting the un-encrypted strings in the php script.
I THINK you would create an anonymous database user OTHER than the root user, and use those settings in your scripts. That way ordinary users don't get root access.
Oh, and you probably don't want to use your database root user password for admin access to the php site. Anyone who sniffed an admin cookie for example, even if the pass in the cookie is encrypted, could possibly crack it at leisure offline and so get root acess to your database. Mind you, with full admin privileges for your php site, there might not be much difference in the damage they could do.
Anyone?
I THINK you would create an anonymous database user OTHER than the root user, and use those settings in your scripts. That way ordinary users don't get root access.
Oh, and you probably don't want to use your database root user password for admin access to the php site. Anyone who sniffed an admin cookie for example, even if the pass in the cookie is encrypted, could possibly crack it at leisure offline and so get root acess to your database. Mind you, with full admin privileges for your php site, there might not be much difference in the damage they could do.
Anyone?
any reversable encryption used in world-readable files doesn't really secure anything, just slows down the process and possibly prohibits some scriptkiddies from finding the login information..
I don't know much about it, but Zend has a commercial product to encode PHP code, I assume this would help quite a bit..
Myself I think for most things it is sufficient to run scripts SuExec as your own users and make all files with sensitive info private (and ofcourse never in the web accessible area).. Things like CC num and other sensitive info like SSN's should not be stored with server-reversible encryption, instead use GnuPG (or PGP or S/Mime etc)...
I don't know much about it, but Zend has a commercial product to encode PHP code, I assume this would help quite a bit..
Myself I think for most things it is sufficient to run scripts SuExec as your own users and make all files with sensitive info private (and ofcourse never in the web accessible area).. Things like CC num and other sensitive info like SSN's should not be stored with server-reversible encryption, instead use GnuPG (or PGP or S/Mime etc)...