---

Jeg har en side, hvor jeg gør brug af sessions til at holde styr på
brugere efter login.

Efter (formoder jeg) at webhotellets PHP-fortolker er blevet opdateret
til v. 4.4.9 fremkommer flg. warning på php-siderne:
"
Warning: Unknown(): Your script possibly relies on a session side-
effect which existed until PHP 4.2.3. Please be advised that the
session extension does not consider global variables as a source of
data, unless register_globals is enabled. You can disable this
functionality and this warning by setting session.bug_compat_42 or
session.bug_compat_warn to off, respectively. in Unknown on line 0
"

Jeg har forsøgt mig med forskellige varianter af:
php_flag register_globals 1 / 0
php_flag session.bug_compat _42 1 / 0
....i .htaccess, men det lader ikke til at virke efter hensigten (man
kan i bedste fald logge ind, men den "glemmer" det igen ved næste
sidekald).

Hvad kan jeg gøre (udover at læse tommetykke PHP changelogs/manualer)
for at logins igen virker med sessions?

Jeg kalder sessions på denne måde:
<?
include('include/sql.php');
db_connect();
$teams = mysql_query("SELECT teamID, teamname FROM teams WHERE
login = '$login' AND password = '$password'");
mysql_close();
if($row = mysql_fetch_object($teams))
{
session_start();
$userid = $row->teamID;
session_register("userid");
$usertype = 1;
session_register("usertype");
$username = $row->teamname;
session_register("username");
}
header("Location: $referer?PHPSESSID=$PHPSESSID");
?>

På forhånd tak,
Kenneth

---

Kenneth Brun Nielsen skrev:
> <?
> include('include/sql.php');
> db_connect();
> $teams = mysql_query("SELECT teamID, teamname FROM teams WHERE
> login = '$login' AND password = '$password'");
> mysql_close();
> if($row = mysql_fetch_object($teams))
> {
> session_start();
> $userid = $row->teamID;
> session_register("userid");
> $usertype = 1;
> session_register("usertype");
> $username = $row->teamname;
> session_register("username");
> }
> header("Location: $referer?PHPSESSID=$PHPSESSID");
> ?>

Problemet ligger i den måde du registrerer dine sessions.
session_register() er afhængig af globale variabler, som standard ikke
(bør) være sat - søg efter register_globals hvis du vil have en dybere
forklaring.

Din kode bør opdateres:
<?
   session_start();
include('include/sql.php');
db_connect();
   $login = $_POST["login"];
   $password = $_POST["password"];
$teams = mysql_query("SELECT teamID, teamname FROM teams WHERE
login = '".mysql_real_escape_string($login)."' AND password =
'".mysql_real_escape_string($password)."'");
mysql_close();
if($row = mysql_fetch_object($teams))
{

$userid = $row->teamID;
$_SESSION["user_id"] = $userid;
$usertype = 1;
$_SESSION["usertype"] = $usertype;
$username = $row->teamname;
$_SESSION["username"] = $username;
}
   // Overvej nødvendigheden af at medsende session id'et
header("Location: ".$referer."?PHPSESSID=".session_id());
   
?>

Ligeledes tilgås dine session variabler således:

$username = $_SESSION["username"];

eller

if($_SESSION["usertype"] == 1)
   echo "Typen er nummer 1";

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:

> Din kode bør opdateres:
....
> login = '".mysql_real_escape_string($login)."' AND password =
> '".mysql_real_escape_string($password)."'");

I virkeligheden burde man bruge parameterized queries, da visse databaser
også kan håndtere eksempelvis hexadecimale tegn.

At escape '-er vil ikke hjælpe mod SQL-injection i disse tilfælde.

Jeg har forlagt min oversigt over injections, så jeg ikke huske om mySQL er
med på den angrebsvektor.

Bare et hint at tænke over.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> I virkeligheden burde man bruge parameterized queries, da visse databaser
> også kan håndtere eksempelvis hexadecimale tegn.

Det emne har vi jo dækket før og vi er skam ganske enige. :) Mit forslag
var blot et hurtigt rewrite til en hurtig løsning på problemet.
I realiteten var der måske også andre aspekter af koden som man kunne
debattere, men jeg kan godt fornemme hvor du vil hen.
>
> At escape '-er vil ikke hjælpe mod SQL-injection i disse tilfælde.

<url: http://dk.php.net/mysql_real_escape_string>
Umiddelbart er det ikke nogen grund til at være alt for alarmeret, men
selvfølgelig er hex injection stadig en mulighed.

>
> Jeg har forlagt min oversigt over injections, så jeg ikke huske om mySQL er
> med på den angrebsvektor.

Det er den, dog er der alligevel taget højde for SUB og NUL hex
erstatning...

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:

> Stig Johansen skrev:
>> I virkeligheden burde man bruge parameterized queries, da visse databaser
>> også kan håndtere eksempelvis hexadecimale tegn.
>
> Det emne har vi jo dækket før og vi er skam ganske enige. :)

Det var nu ikke ment som et svar til dig, men en generel betragtning.

Med tanke i, at databaser 'kan' mere og mere med nyere versioner, kan man
godt være sikker i 'dag', men usikker i 'morgen'.

--
Med venlig hilsen
Stig Johansen