noen åpenbare sikkerhetshull?

[Svish]

lager et lite hyper enkelt cms system som oppgave på skolen (og noen skal bruke det etterpå), og har nå laget et login system som fungerer. har lest litt rundt omkring, og tror det skal være sånn passe sikkert, men lurte på om noen her kan se noen åpenbare kjempekrisefeil eller sånt.

 

har et mysql table med username, password_hash kryptert som sha1, en last_seen datetime og en last_ip som er en unsigned int.

 

når noen logger inn, sjekker jeg om noen med brukernavnet og passord hashen finnes, og hvis det finnes en kjører jeg en spørring som setter last_seen til NOW() og last_ip til ip2long($_server['remote_addr']). Til slutt lagrer jeg brukernavnet i en sessionvariabel.

 

for så å holde folk innlogget, har jeg en funksjon som kjøres på hver side. det den gjør er å hente ut brukernavnet fra sessionvariablen, og så sjekke det opp mot databasen igjen. den sjekker da om den finner noen med det brukernavnet, som er last_seen mindre enn 60 minutter siden, og som har samme last_ip.

 

hvis den finner noen som har det, så oppdaterer den last_seen igjen og resetter altså da timeouten. hvis den derimot ikke finner noen, så kjører den logout funksjonen som clearer last_seen og last_ip i databasen, og unsetter sessionvariabelen med brukernavnet.

 

er dette en bra måte? noen som ser noen umiddelbare hull i dette? er sikkert en drøss, og man kan jo aldri ble helt skuddsikker, men i mitt hode skulle dette holde for en enkel side. men etter å ha kodet lenge så har jeg sett meg litt blind på koden så greit å få noen ideer fra andre..

 

bruker sprintf til å bygge opp spørringene, og bruker mysql_real_escape_string() på brukernavnet. passordet går jo igjennom sha1() så hvis det er noe sql injections der så forsvinner jo det ganske greit..

 

kunne sikkert putta inn all kildekoden til disse funksjonene, men er mest ideen og tankegangen jeg lurer på om er riktig.

[Runar]

Etter det jeg har blitt fortalt, så sikrer du deg mot det meste med mysql_real_escape_string og lignende. Det skulle ikke være noen hull i koden din da, uten at jeg kan si det 100% sikkert.

 

Hvis du bare har ét skjema, er det vel der det kan være kritiske hull?

Endret 23. februar 2007 av Runar

[Svish]

hva tenker du med et skjema?

[Runar]

Der hvor du logger inn. Det er vel det eneste stedet brukeren kan påvirke hva som blir sendt til databasen?

[Svish]

vel, det er jo en input for brukernavn og en input for passord, hvis det er det du mener

 

så eneste som kan være litt usikkert er vel det med brukernavnet. i og med at passordet blir til sha1..

 

mulig man kanskje kunne gjort mer med brukernavnet enn escapeing? sikrer den mot sql injections for eksempel?

[Runar0]

vel, det er jo en input for brukernavn og en input for passord, hvis det er det du mener

 

så eneste som kan være litt usikkert er vel det med brukernavnet. i og med at passordet blir til sha1..

 

mulig man kanskje kunne gjort mer med brukernavnet enn escapeing? sikrer den mot sql injections for eksempel?

8011996[/snapback]

 

mysql_real_escape_string skal sikre deg mot alt av injections etter som at ' og " blir til \' og \"

[Svish]

ok. menneh, hva med ; ? er jo den som splitter uttrykk. men får kanskje ikke gjort særlig mye uten ' og "?

[jorgis]

for så å holde folk innlogget, har jeg en funksjon som kjøres på hver side. det den gjør er å hente ut brukernavnet fra sessionvariablen, og så sjekke det opp mot databasen igjen. den sjekker da om den finner noen med det brukernavnet, som er last_seen mindre enn 60 minutter siden, og som har samme last_ip.

 

hvis den finner noen som har det, så oppdaterer den last_seen igjen og resetter altså da timeouten. hvis den derimot ikke finner noen, så kjører den logout funksjonen som clearer last_seen og last_ip i databasen, og unsetter sessionvariabelen med brukernavnet.

8008018[/snapback]

 

Vel, du skal ikke gå ut fra at last_ip holder seg den samme fra forespørsel til forespørsel. Ikke sikkert dette er så aktuelt for deg, men en del ISPer kjører kundene sine gjennom forskjellige proxyer, med det resultat at en kan bytte ip-adresse veldig fort veldig ofte. Mener å huske at AOL var en av de som drev mye med dette. Problemet en da kan støte på ved bruk av CMSet ditt er at brukerne blir logget ut på tilfeldige steder tilsynelatende uten grunn.

 

Men å bare fjerne sjekken etter last_ip er heller ikke lurt, for da er du plutselig sårbar for session hijacking/forging, der noen kan bryte seg inn ved å sette sessionvariabelen på lokal maskin, og velge en bruker som de vet ofte er innlogget. Vips, så er de innlogget som denne aktive brukeren.

 

Forslag: session settes til unik id, som genereres på nytt for hver forespørsel. Om ikke id'en returneres helt identisk for hver forespørsel, har det skjedd noe muffens. Kombiner med relativt kort timeout, og du har et noenlunde trygt system.

 

...så er det også begrenset hvor mye du bør gidde å styre med sikkerhet på et custom system som kanskje skal brukes av få brukere? Så lenge du styrer unna de åpenbare feil (sql insertion og XSS-feil), bør du gå klar av problemer.

[Svish]

så klart. gidder ikke gå av hektene på dette systemet her, men vil lære så mye som mulig spesielt slike relativt åpenbare ting som dette her, som også er relativt enkle å beskytte seg mot.

 

hva er xss-feil?

 

er nettopp dette med session-hijacking jeg leste om da forslaget om å sjekke ip ble nevnt. og synes det var en god ide. men dette med å generere en unik id hørtes jo ikke så dumt ut. mente du istedet for ip? eller i tillegg? og så putte den inn på samme måte som jeg nå putter inn tid og ip ikke sant? hørtes definitivt ikke dumt ut. kan jo bruke denne funksjonen her jeg fant i phpmanualen en dag for eksempel da?

PHP

<?php

$token = md5(uniqid(rand(), true));

?>

Endret 25. februar 2007 av Tussi_qwerty

[Runar]

http://kaiultraboard.byethost9.com/tutoria...xss_attacks.php

http://kaiultraboard.byethost9.com/tutoria...srf_attacks.php

 

Disse guidene forteller deg hvordan du kan beskytte deg mot XSS og CSRF angrep.

[Svish]

Runar: takker og bukker for de linkene! det var interessant lesning, og visste ikke om det der, hehe. har ikke begynt på adminbiten enda, men den skal sikres mot sånt ja! bruker som oftest $_get['id'] eller lignende til å hente nummer på artikler og sånt, men den går igjennom sprintf med %u, så skal vel ikke være noe risk der

[Svish]

da har jeg byttet ut ip med en sha1(uniqid()). ser ut til at det fungerer ypperlig. men nå kan jeg ikke å hacke da.. så får liksom ikke testet det ut noe annet enn i mitt eget hode