Innlogging.. Sikkert nok?

[EirikO]

Lurte på om noen har noen kommentarer til innloggings-systemet mitt..

 

Har login.php:

$email = mysql_real_escape_string($_POST['email']);
$passord = md5(mysql_real_escape_string($_POST['passord']));
$query = mysql_query("SELECT id, email, passord FROM kunde WHERE email='$email' AND passord ='$passord'");
$result = mysql_fetch_array($query);
if($result['id'] == null) {
print("Feil kode/passord");
} else { 
$_SESSION['kunde'] = array("id" => $result['id'], "email" => $result['email'], "passord" => $result['passord'],   "ip" => $_SERVER['REMOTE_ADDR']);
 print("Du er logget inn.<br>Du blir tatt til hovedsiden.");
}

 

Så for å sjekke på de beskyttede sidene bruker jeg:

if(bruker_sjekk($_SESSION['kunde']['email'], $_SESSION['kunde']['passord'], $_SESSION['kunde']['ip'])) {
$kundeid = $_SESSION['kunde']['id'];
//bla bla bla. Du er logget inn.. Fint for deg..

 

bruker_sjekk(..) ser slik ut:

function bruker_sjekk($email, $passord, $ip) {
  $query = mysql_query("SELECT email, passord FROM kunde WHERE email = '$email'");
  $result = mysql_fetch_array($query);
  if($result['passord'] == $passord && $_SERVER['REMOTE_ADDR'] == $ip) {
   return true;
  }
  return false;

}

 

Noen som har tips til forbedringer? Har forresten session_start() på alle sidene..

Endret 7. november 2007 av EirikO

[Gjest Slettet+142]

Jeg vil ikke kalle det der helt sikkert nok. Jeg anbefaler deg å kjøre en mysql_num_rows(), og sjekke om det faktisk returneres noen rader, før du kjører mysql_fetch_array()..

[EirikO]

Ok. Takker for det.

Noen andre kommentarer??

[Sjark]

så bare raskt over det nå, men det ser ut som om du lagrer passordet til brukeren i klartekst i SESSION, jeg ville anbefale at du lagrer det som md5 hash i både databasen og i session, ivertfall litt skikrere, evt legge inn en salt i md5 hashen så blir det mye mye sikrere.

 

Edit: ups, jeg som er sløv her, du hadde vist md5

Endret 7. november 2007 av Sjark

[-morten]

Det er litt unødvendig å gjøre sånn som du gjør. Det holder å lagre ID i session, og hvis den er satt så er bruker logget inn. Trenger ikke å sjekke verdiene i sessionen på nytt for hver side. Husk at sessionen lagres på serveren, og at brukeren bare får en lang unik id som php så bruker for å hente riktig session data.

 

$passord = md5(mysql_real_escape_string($_POST['passord']));

er forøvrig litt bortkastet. Det er ikke noe poeng i å escape før du MD5-er, siden MD5 uansett bare gir deg tall og bokstaver.

[mysjkin]

Hvor viktig sikkerheten er kommer jo an på hvor mye skade det er om noen uvedkommende kommer seg inn.

 

Husk, cookies kan komme på avveie... og hva om en person går fra PC-en uten å logge seg ut og noen andre finner den en stund senere?

 

Mitt standardsystem er omtrent som følger

 

Innlogging, sjekker brukernavn og passord, dersom OK genererer jeg en sessionid med en md5sum av localtime()+brukers ip+ en random verdi. Sesjons-iden lagres i en tabell i databasen sammen med rettigheter brukeren har i sesjonen, IPadressen og en timeoutverdi.

 

Når brukeren går til en beskyttet side skjekkes det utfra sesjons-iden og IP om brukeren har tilstrekkelige rettigheter. I tillegg oppdateres timeoutverdien og alle sesjoner som har timet ut slettes.

 

Faren med å sjekke IP er at brukeren kan bli hevet ut om h[au]n sitter på et system hvor IPen varierer. Det finnes en del måter å gjøre dette bedre på, men må se an hvor stort problemet er, eventuelt kutt ut ip-sjekk mot da å få litt mindre sikkerhet i systemet. (dersom noen på en annen PC får på et eller annet vis tak i sesjonsiden, er de i sesjonen å lenge ikke en bruker logger seg ut)

 

Lykke til!

 

M.

[EirikO]

Forstår jeg det rett hvis du mener noe sånt:

$randomVerdi = "blablalba"; //lage random

$_SESSION['innlogget'] = $randomVerdi;

//Skrive $randonVerdi, IP, og timeout til databasen

Så får å sjekke innlogging:

if($_SESSION['innlogget'] == randomFraDatabase && $ip == IpFraDatabase &&  time() < TimeoutFraDatabase) {
Du er innlogget
};

 

Når er det forresten fornuftig å bruke tre likhetstegn? (===)

[Ernie]

Det er litt unødvendig å gjøre sånn som du gjør. Det holder å lagre ID i session, og hvis den er satt så er bruker logget inn. Trenger ikke å sjekke verdiene i sessionen på nytt for hver side. Husk at sessionen lagres på serveren, og at brukeren bare får en lang unik id som php så bruker for å hente riktig session data.

Jo, det er nettopp det man må. Alle har tilgang til å skrive filene session er lagret i. Det betyr i praksis at enhver person på samme server kan endre session til sin fordel. Å da lagre bare brukerid gjør at uvedkommende enkelt kan logge seg inn som f.eks admin. Videre er det heller ingen garanti for at brukeren som besøker siden med en viss session-id faktisk er den rette personen, derav sjekk mot IP og nettleser.

Når er det forresten fornuftig å bruke tre likhetstegn? (===)

Når du ønsker typesjekk av dataene det gjelder. F.eks er 1 == "a" true, mens 1 === "a" er false. Endret 10. november 2007 av Ernie

[Peter]

Jo, det er nettopp det man må. Alle har tilgang til å skrive filene session er lagret i. Det betyr i praksis at enhver person på samme server kan endre session til sin fordel. Å da lagre bare brukerid gjør at uvedkommende enkelt kan logge seg inn som f.eks admin. Videre er det heller ingen garanti for at brukeren som besøker siden med en viss session-id faktisk er den rette personen, derav sjekk mot IP og nettleser.

Elimineres ikke denne risikoen ved å lagre sessions et annet sted enn standardmappen (som er /tmp elns.), eller enda bedre, enn database?

[Ernie]

Jo, det er nettopp det man må. Alle har tilgang til å skrive filene session er lagret i. Det betyr i praksis at enhver person på samme server kan endre session til sin fordel. Å da lagre bare brukerid gjør at uvedkommende enkelt kan logge seg inn som f.eks admin. Videre er det heller ingen garanti for at brukeren som besøker siden med en viss session-id faktisk er den rette personen, derav sjekk mot IP og nettleser.

Elimineres ikke denne risikoen ved å lagre sessions et annet sted enn standardmappen (som er /tmp elns.), eller enda bedre, enn database?

Nei, med mindre det er snakk om en VPS-løsning eller PHP kjørt som CGI-prosess er alle filer like tilgjengelig for alle andre. Dvs. passordet til databasen vil være fult tilgjengelig og session-dataene kan redigeres.

[-morten]

Jo, det er nettopp det man må. Alle har tilgang til å skrive filene session er lagret i. Det betyr i praksis at enhver person på samme server kan endre session til sin fordel. Å da lagre bare brukerid gjør at uvedkommende enkelt kan logge seg inn som f.eks admin. Videre er det heller ingen garanti for at brukeren som besøker siden med en viss session-id faktisk er den rette personen, derav sjekk mot IP og nettleser.

Om du tenker at kun ID kan endres til admin-ID, mens bruker/passhash ikke har det problemet, så ser jeg den ja.

Men hvis alle har tilgang til å endre session-filene på serveren din, så tror jeg du bør vurdere å rekonfigurere litt.. Eventuelt bytte til et litt mindre inkompetent webhotel

IP kan forøvrig spoofes ganske enkelt.

[Ernie]

Jo, det er nettopp det man må. Alle har tilgang til å skrive filene session er lagret i. Det betyr i praksis at enhver person på samme server kan endre session til sin fordel. Å da lagre bare brukerid gjør at uvedkommende enkelt kan logge seg inn som f.eks admin. Videre er det heller ingen garanti for at brukeren som besøker siden med en viss session-id faktisk er den rette personen, derav sjekk mot IP og nettleser.

Om du tenker at kun ID kan endres til admin-ID, mens bruker/passhash ikke har det problemet, så ser jeg den ja.

Men hvis alle har tilgang til å endre session-filene på serveren din, så tror jeg du bør vurdere å rekonfigurere litt.. Eventuelt bytte til et litt mindre inkompetent webhotel

IP kan forøvrig spoofes ganske enkelt.

Altså shared hosting er langt fra så sikkert som man tror. De inkompetente webhotelene du snakker om er i bunn og grunn de aller fleste som finnes. VPS/VDS innebærer løsninger ala vmware og gir hver bruker en egen virtuel maskin, hvilket ikke er vanlig. Å kjøre PHP som separate prosesser for hver bruker er heller ikke så vanlig, etter det jeg veit. Noen annen måte å gardere seg mot problemet finnes ikke. Samme bruker må nemlig kjøre alle brukerenes script, og kan derfor endre alle brukerenes filer. Hvis du mener det finnes andre løsninger på det her som faktisk funker, så er jeg veldig interessert i å høre Så lenge "hvem som helst" har tilgang til serveren og overnevnte løsninger ikke er i bruk, er det ingenting som heter sikker innlogging i eller for PHP pr. dags dato.

[Gjest Slettet+142]

root@mariyo:/var/lib/php5# ls -l

total 4

-rw------- 1 mariyo www-data 0 Nov 11 20:38 sess_9bddab019c1bab4dd99968ec8f5e6b3d

-rw------- 1 mariyo www-data 285 Nov 11 20:45 sess_f401cb5de039156c98e6c42ba34eba36

root@mariyo:/var/lib/php5#

Ovenfor ser dere kun brukeren www-data har tilgang til filene. Så jeg vet ikke helt hvor du har det du sier om at "hvem som helst" kan se session-filene fra..

 

Under her ser dere hvordan det gikk da jeg engang bare prøvde å lese ifra mappen som session-filene er i:

mariyo@mariyo:/var/lib/php5$ ls -l

ls: .: Permission denied

mariyo@mariyo:/var/lib/php5$

--

Men uansett må jeg si at jeg ble "fasinert" av hvor enkelt det kan være å få f.eks admin-access på en side bare av å tukle med disse filene

[Ernie]

root@mariyo:/var/lib/php5# ls -l

total 4

-rw------- 1 mariyo www-data 0 Nov 11 20:38 sess_9bddab019c1bab4dd99968ec8f5e6b3d

-rw------- 1 mariyo www-data 285 Nov 11 20:45 sess_f401cb5de039156c98e6c42ba34eba36

root@mariyo:/var/lib/php5#

Ovenfor ser dere kun brukeren www-data har tilgang til filene. Så jeg vet ikke helt hvor du har det du sier om at "hvem som helst" kan se session-filene fra..

 

Under her ser dere hvordan det gikk da jeg engang bare prøvde å lese ifra mappen som session-filene er i:

mariyo@mariyo:/var/lib/php5$ ls -l

ls: .: Permission denied

mariyo@mariyo:/var/lib/php5$

Du veit ganske åpenbart ikke hva du snakker om her. Det du viser her beviser ikke noe som helst. Først og fremst tilhører de filene brukeren mariyo tilknyttet gruppen www-data. At du ikke får kjøre en directory listing har noe med at mappen det er snakk om tilhører brukeren root. Videre vil det være slik at alle PHP-script på din server vil kjøres med brukere mariyo og gruppe www-data. Alle filer denne bruker-gruppe-kombinasjonen har tilgang til vil alle script automatisk ha tilgang til.

[Gjest Slettet+142]

Damn. Vet ikke hva jeg tenkte på da jeg postet det der nå som du sier det der, ja.

Sorry

[-morten]

De inkompetente webhotelene du snakker om er i bunn og grunn de aller fleste som finnes. VPS/VDS innebærer løsninger ala vmware og gir hver bruker en egen virtuel maskin, hvilket ikke er vanlig. Å kjøre PHP som separate prosesser for hver bruker er heller ikke så vanlig, etter det jeg veit.

Egentlig er det vel brukerne som er inkompetente, og ikke ISPene. De fleste leverandørene vet vel om denne sikkerhetssvakheten, men regner med at kundene ikke bryr seg fordi de ikke aner noe om det.. Ikke at det er noe bedre...

 

Med suPHP så kjøres alle phpscript som din bruker på webhotellet. Dermed kan alle filer være chmodda 600 og eid av din bruker, inkludert session-data. Men det er klart at dette krever mye mer ressurser enn ren mod_php. Allikevel bruker hvertfall Domeneshop dette, og de er da ganske store.

 

Men dette er ikke bare et problem med tanke på sessiondata. Alle med et webhotell som har SSH uten chroot kan jo bare vandre rundt i alle brukeres kataloger og se etter world-readable php-filer med sql-bruker/pass i, og så koble seg til den databasen fra egne script og styre som man vil...