A lot of scripts handle access by including a 'secure.php' file which validates the user by session/posted username/passwords, and in the case of a login failure redirects to the login page.
Remember to always do this redirect in such a way that the rest of the script is not executed after the redirect. The easiest way to do this is using exit; after the redirect.
Example:
I've been recently looking over code for a company to identify security holes and they were doing this for their authentication. they had code which boils down to something like this:
Code:
secure.php
<?php
if (isset($_COOKIE['username']) && isset($_COOKIE['userpass'])){
$rs = mysql_query('SELECT password FROM users WHERE username="'.$_COOKIE['username'].'"');
if (mysql_num_rows($rs) == 0){
header('Location: login.php');
}
else {
$securepass=mysql_result($rs, 0, 0);
if (base64_decode($_COOKIE['userpass']) != $securepass){
header('location: login.php');
}
}
}
That file is used in an admin file as so:
Code:
edit.php
<?php
//Validate login, redirect to login page if incorrect.
include('secure.php');
$action = $_GET['action'];
if ($action == 'delete'){
mysql_query('DELETE FROM entries WHERE entry_id='.$_GET['id']);
echo 'Entry deleted';
}
?>
Now. Aside from the glaring SQL Injection problems, it is also possible for a completely unauthenticated user to delete stuff because they do not prevent the rest of the script from running.
A request to the URL http://www.site.com/admin/edit.php?action=delete&id=1
will generate a response like so:
Code:
HTTP/1.1 200 Ok
Location: login.php
Entry Deleted
The browser will happily redirect you to login.php and it looks like your code works, but if you look at the DB you'll be quick to notice entry_id #1 is no longer there because the delete was executed when the script finished up. The fix? Just exit after a redirect.
Code:
header('Location: login.php');
exit;
Dev Shed Forums Sponsor:
May 15th, 2008, 12:16 AM
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
Linear Mode
