Sikker måte å sjekke om bruker er pålogget?

[ZeRKoX]

Er dette en sikker måte å sjekke at bruker er pålogget?

 

<?php
$sql_host = 'localhost';
$sql_user = 'bruker';
$sql_pass = 'passord';
$sql_name = 'database';
$sql_table = 'tabell';

$sebruker = $_SESSION['brukernavn'];
$sepassord = $_SESSION['passord'];
$sefornavn = $_SESSION['fornavn'];
$seetternavn = $_SESSION['etternavn'];
$setilgang = $_SESSION['tilgang'];

$con = mysql_connect($sql_host,$sql_user,$sql_pass);
if (!$con)
{
 die('Could not connect: ' . mysql_error());
}

mysql_select_db("$sql_name", $con);

$result = mysql_query("SELECT * FROM $sql_table WHERE brukernavn='$sebruker'");

$row = mysql_fetch_array($result);

$hentassord = $row['passord'];
$hentfornavn = $row['fornavn'];
$hentetternavn = $row['etternavn'];
$henttilgang = $row['tilgang'];

if(!$sepassord == $hentpassord)
{
 session_destroy();
 header("location:index.php");
}
if(!$sefornavn == $hentfornavn)
{
 session_destroy();
 header("location:index.php");
}
 if(!$seetternavn == $hentetternavn)
{
 session_destroy();
 header("location:index.php");
}
 if(!$setilgang == $henttilgang)
{
 session_destroy();
 header("location:index.php");
}
?>

Endret 8. januar 2008 av obrestad

[Peter]

Er dette en sikker måte å sjekke at bruker er pålogget?

 

 

<?php
$sql_host = 'localhost';
$sql_user = 'bruker';
$sql_pass = 'passord';
$sql_name = 'database';
$sql_table = 'tabell';

$sebruker = $_SESSION['brukernavn'];
$sepassord = $_SESSION['passord'];
$sefornavn = $_SESSION['fornavn'];
$seetternavn = $_SESSION['etternavn'];
$setilgang = $_SESSION['tilgang'];

$con = mysql_connect($sql_host,$sql_user,$sql_pass);
if (!$con)
{
 die('Could not connect: ' . mysql_error());
}

mysql_select_db("$sql_name", $con);

$result = mysql_query("SELECT * FROM $sql_table WHERE brukernavn='$sebruker'");

$row = mysql_fetch_array($result);

$hentassord = $row['passord'];
$hentfornavn = $row['fornavn'];
$hentetternavn = $row['etternavn'];
$henttilgang = $row['tilgang'];

if(!$sepassord == $hentpassord)
{
 session_destroy();
 header("location:index.php");
}
if(!$sefornavn == $hentfornavn)
{
 session_destroy();
 header("location:index.php");
}
 if(!$seetternavn == $hentetternavn)
{
 session_destroy();
 header("location:index.php");
}
 if(!$setilgang == $henttilgang)
{
 session_destroy();
 header("location:index.php");
}
?>

Det spørs helt på hvor disse session-variablene kommer fra og om de er validert eller ikke?

I utgangspunktet burde de være validert, men jeg tipper de ikke er det, og risikerer du ganske mye muffins.

 

Strenger sammenlignes forsåvidt med strcmp() eller ===. header("Location") direktivet skal ha absolutt url, du bruker relativ.

Endret 8. januar 2008 av Peter

[Ernie]

... og ikke minst bør man i aller høyeste grad slenge på en exit()/die() etter header m/location med mindre det er meningen at scriptet skal fortsette (Nei, folkens det er faktisk slik at header ikke er en magisk funksjon som stopper scriptet hvis du sender "Location:...").

Endret 8. januar 2008 av Ernie

[luxus]

Strenger sammenlignes forsåvidt med strcmp() eller ===. header("Location") direktivet skal ha absolutt url, du bruker relativ.

 

Nåja, strenger kan fint sammenliknes med $s1 == $s2.. Men hvis man bruker == vil "12" være lik 12 (altså tallet 12). "12" === 12 vil derimot være false, da === også typesjekker variablene og ser om de er lik hverandre.

 

strcmp brukes i andre sammenhenger, da helst under sortering. Kodesnutten

if ( strcmp("hei", "hei") ) {
 print "Lik";
} else {
 print "Ulik";
}

vil faktisk printe ut Ulik, da strcmp("hei", "hei") vil resultere i 0 (tall). if ( 0 ) valideres som false. (Selvfølgelig kan man sjekke om strcmp() === 0 og if-blokken over vil da fungere fint, men dette er vel litt tungvindt ) Hva som valideres som false finnes her.

Endret 8. januar 2008 av luxus

[grimjoey]

Du har nok misset poenget litt. Alt dette er helt unødig slik jeg ser det. Dette betyr at du sender passord og brukerinformasjon mellom web serveren og mysql servere hver gang det gjøres en request. Det øker kjangsen betraktelig for å fange opp den kommunikasjonen for en hacker en hvis infoen bare ble sendt ved første request (som er det vanlige). Du legger passord og brukerinformasjon i $_SESSION som i mange tilfeller ved shared hosting betyr at all informasjon er tilgjengelig i klartekst for alle andre brukerene av hosten. Noen steder også tilgjengelig fra utsiden.

 

for de som ikke orker å lese på php.net

 

session_start(); lagrer en tilfeldig hash i php motoren. hashen blir også sendt til klienten i form av en cookie, eller dersom klient ikke støtter cookies blir hashen lagt til alle lokale linker og vises som en get variabel.

 

så ved å enkelt gjøre:

 

$_SESSION['auth'] = TRUE;

 

etter en brukergodkjenning (brukernavn og passord sjekkes mot database)

 

kan du være ganske sikker på at brukeren er den som logget seg inn så lenge $_SESSION['auth'] === TRUE;

 

$_SESSION lagres vanligvis i en tmp fil på web serveren. all infoen du setter inn i session er synlig i den filen. er det kun en hash, er det værste som kan skje en session hijack dersom noen får tak i informasjonen

 

skal du ha noe som er sikrere en dette må du bruke en challenge response mekanisme som gjør at hashen forandrer seg for hver request. dette er innebygt i http protokollen ved bruk av http auth digest.

 

ssl er neste steg for sikkerhet.

Endret 8. januar 2008 av grimjoey

[grimjoey]

sry. dobbel post

Endret 8. januar 2008 av grimjoey

[ZeRKoX]

Du har nok misset poenget litt. Alt dette er helt unødig slik jeg ser det. Dette betyr at du sender passord og brukerinformasjon mellom web serveren og mysql servere hver gang det gjøres en request. Det øker kjangsen betraktelig for å fange opp den kommunikasjonen for en hacker en hvis infoen bare ble sendt ved første request (som er det vanlige). Du legger passord og brukerinformasjon i $_SESSION som i mange tilfeller ved shared hosting betyr at all informasjon er tilgjengelig i klartekst for alle andre brukerene av hosten. Noen steder også tilgjengelig fra utsiden.

 

for de som ikke orker å lese på php.net

 

session_start(); lagrer en tilfeldig hash i php motoren. hashen blir også sendt til klienten i form av en cookie, eller dersom klient ikke støtter cookies blir hashen lagt til alle lokale linker og vises som en get variabel.

 

så ved å enkelt gjøre:

 

$_SESSION['auth'] = TRUE;

 

etter en brukergodkjenning (brukernavn og passord sjekkes mot database)

 

kan du være ganske sikker på at brukeren er den som logget seg inn så lenge $_SESSION['auth'] === TRUE;

 

$_SESSION lagres vanligvis i en tmp fil på web serveren. all infoen du setter inn i session er synlig i den filen. er det kun en hash, er det værste som kan skje en session hijack dersom noen får tak i informasjonen

 

skal du ha noe som er sikrere en dette må du bruke en challenge response mekanisme som gjør at hashen forandrer seg for hver request. dette er innebygt i http protokollen ved bruk av http auth digest.

 

ssl er neste steg for sikkerhet.

 

Så det du her sier her er at det er nok å sette en session til en verdi når brukeren logger på, og sjekke den for hver sikker side?

 

Jeg trodde det ville være en fordel å sjekke opp mot databasen at brukerinfoen stemmte, slit at ikke noen prøvde å endre på noen verdier...

[Crowly]

$_SESSION lagres vanligvis i en tmp fil på web serveren. all infoen du setter inn i session er synlig i den filen. er det kun en hash, er det værste som kan skje en session hijack dersom noen får tak i informasjonen

 

skal du ha noe som er sikrere en dette må du bruke en challenge response mekanisme som gjør at hashen forandrer seg for hver request. dette er innebygt i http protokollen ved bruk av http auth digest.

 

<?php
 session_start();
 if(version_compare('5.1.0', phpversion(), '>'))
session_regenerate_id(); 
 else 
 { 
unlink(ini_get('session.save_path').'/sess_'.session_id()); 
session_regenerate_id(); 
 } 
?>

Skal lage ny session id for hver gang siden lastes. Det anbefales vel også at man endrer session path til en "ikke public mappe" i eget domene/hjemme område, slik at det blir vanskeligere for andre domener/brukere på samme server å få tak i ditt domenes session informasjon. Mener å ha lest dette ett sted

[grimjoey]

har ikke testet den metoden crowly, det er vertfall et godt prinsipp. digest er et hakk bedre dog. gjør du slik som du sier vil hver unike session id bli brukt 2 ganger. serveren setter den og sender den til client. client sender den til server for sammenlikning ved neste request. http auth digest (som forøverig kan gjøres med header()) fungerer slik at hver unike "session id" aldri blir brukt mer en èn gang. man kan også skrive en challenge response mekanisme i php hvis man bruker frames eller ajax. (man er avhengig av å kunne lagre data lokalt på klienten som ikke sendes til server)

 

obrestad: du fattet riktig.

 

ingen bruker kan endre $_SESSION så lenge du ikke skriver kode som lar de gjøre det som:

 

$_SESSION[$_GET['val1']] = $_GET['val2'];

 

unngå denne koden og bruk din egen key og verdi i $_SESSION for eksempel: $_SESSION['alksjdfa'] = 'aksdjfhalks';

 

dette er kun for de som er paranoide. (egentlig ganske unødvendig)

 

 

Ellers ville jeg forsøkt å få til http auth digest. det gjøres med headere. google "php http auth digest"

[ZeRKoX]

Så da er egentlig dette en god nok sikkerhet viss alle session variablene kommer fra database?

 

 if (isset($_SESSION['tilgang']) && isset($_SESSION['brukernavn']) && isset($_SESSION['passord']) && isset($_SESSION['fornavn']) && isset($_SESSION['etternavn']))

[grimjoey]

det er å gjøre ting mindre sikkert enn de trenger å være.

[Crowly]

har ikke testet den metoden crowly, det er vertfall et godt prinsipp. digest er et hakk bedre dog. gjør du slik som du sier vil hver unike session id bli brukt 2 ganger. serveren setter den og sender den til client. client sender den til server for sammenlikning ved neste request. http auth digest (som forøverig kan gjøres med header()) fungerer slik at hver unike "session id" aldri blir brukt mer en èn gang. man kan også skrive en challenge response mekanisme i php hvis man bruker frames eller ajax. (man er avhengig av å kunne lagre data lokalt på klienten som ikke sendes til server)

Begge metodene benytter seg av samme beskyttelses prinsipp, at session id kun er gyldig i en kort periode. Kjenner ikke til http auth digest, men svakeheten med php metoden blir at session id er gyldig helt til bruker foretar seg noe nytt (eller den går ut på normal måte). Men er til gjengjeld enkel å legge inn/ta i bruk. Endret 9. januar 2008 av Crowly

[grimjoey]

http auth digest benytter noe som kalles en challenge response mekanisme. serveren sender 1 eller 2 nonce's (unik tilfeldig verdi) til klienten for hver request. under første request blir det hashet en key på klientsiden ut i fra brukernavn, passord og nonce'n. serveren lagrer denne nonce'n. keyen blir så hashet med den andre nonce'n og sendt til server. serveren har nonce'n brukernavn, passord og nonce'n i databasen og kan verifisere key'en ved å reprodusere med den andre nonce'n. den siste hashinga blir gjort hver request, med en ny nonce slik at det alltid er en unik verdi som blir overført som bekrefter brukerens autentitet.