Mapster Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 Holder på med mitt eget lille "cms" system, og har behov for en admin side av systemet. Er det noen spesielle metoder som er å anbefale til dette bruket? Det jeg forløbig gjør er å lese inn brukernavn og passord fra et <form> og lage en md5-sum av passordet, og kontrollere det mot en mysql-database. For at systemet skal "huske" at brukeren er innlogget generer jeg en md5sum som jeg lagrer i SESSION og har den samme summen i alle linker brukeren trykker på (vha. REQUEST). Er denne måten sikker nok? Er det nødvendig å ha en slik sjekksum i alle linker? Eller er det nok med å lagre en boolean i SESSION som er true for innlogget? Takker for alle svar Lenke til kommentar
serrghi Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 tja... jeg ville kanskje ha brukt sha1, usersalt og sitesalt istedet for md5. Og lagret sitesalt og påloggings status i cookies. Men den funker nok bra den måten din og Lenke til kommentar
nree Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 Hvis man får tak i md5sum til en bruker, vil ikke den metoden gjøre at session hijack er fryktelig enkelt når man bare kan legge den rett i url'en? Lenke til kommentar
AlecTBM Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 Ikke bruk $_REQUEST, bruk $_SESSION, $_POST, $_GET osv med $_REQUEST så kan du ikke hindre at folk bruker GET isteden for POST på bla innlogginga Lenke til kommentar
OIS Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 tja... jeg ville kanskje ha brukt sha1, usersalt og sitesalt istedet for md5. Og lagret sitesalt og påloggings status i cookies. Men den funker nok bra den måten din og Sitesalt burde holdes hemmelig hvis du kan. Det bør iallefall ikke lagres i cookies. Og påloggingsstatus bør iallefall ikke lagres i cookies. Den bør du lagre i session. Hvis man får tak i md5sum til en bruker, vil ikke den metoden gjøre at session hijack er fryktelig enkelt når man bare kan legge den rett i url'en? Jo. Utrolig enkelt. Og hvis en hacker får tak i brukerdatabasen, så slipper han å bruteforce et søk for å finne passordet da han bare kan bruke md5 summen rett i urlen. Ikke bruk $_REQUEST, bruk $_SESSION, $_POST, $_GET osv med $_REQUEST så kan du ikke hindre at folk bruker GET isteden for POST på bla innlogginga $_REQUEST er default en sammenslåing av $_POST, $_GET og $_COOKIES. Siden andre websider kan sette cookies for din webside, så kan de gjøre noe rart for siden din hvis du bruker $_REQUEST ja. Lenke til kommentar
Mapster Skrevet 18. mars 2009 Forfatter Del Skrevet 18. mars 2009 Lærte en del nytt no ja Jeg trodde $_REQUEST var eneste man kunne bruke for å få variabler fra url. Ellers så tror jeg kansje noe av det jeg sa ble missforstått., MD5 verdien jeg bruker i url er ikke passord md5, men en verdi så genereres basert på time() (+masse annet) for hver innlogging. Hvordan kan jeg gjøre det slik at jeg unngår session hijack? Lenke til kommentar
AlecTBM Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 Bruke $_SESSION istedenfor $_REQUEST Lenke til kommentar
Mapster Skrevet 18. mars 2009 Forfatter Del Skrevet 18. mars 2009 For å prøve å forklare enda bedre, sånn at jeg er sikker på at ingen missforstår meg: Når en bruker blir autentisert mot databasen og brukernavn + passord stemmer, så generer jeg en md5 "session id" som jeg lagrer i Session, samt jeg har en Session variabel for bruker-id og en boolean for at bruker er innlogget. Hver gang en bruker skal laste en av sidene man må være innlogget for å se, så kontrolleres det at bruker har korrekt "session id" i url mot den som er lagret i Session. Er dette en usikker måte å håndtere innlogging på? Lenke til kommentar
Sk!ppy Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 sha512 + doublecrypt .. Lykke til med å cracke den! Lenke til kommentar
veliro Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 Brukernavn og passord: - Salt: Tilfeldig string som blir generert til hver bruker ved registrering. - Passord: sha1 av salt+brukerens passord Session: - I tillegg til å lagre session-variabler ville jeg lagret brukerens ip i databasen. Og ved hver oppdatering ville jeg sjekka om ipen er den samme. Hvis ikke logges brukeren ut. Cookies: - Cookie-verdien som blir satt ved setCookie kan være en sammensetning av brukerens brukernavn + tilfeldig string som blir lagret ved registrering Altså har brukertabellen: brukernavn, passord, salt, cookie. Tror du er ganske sikker når sessionen blir sjekka hver gang. Om noen stjeler session-verdien har de mest sannsynlig en annen ip (session er da ugyldig). Selfølgelig ikke holdbart om den "onde" brukeren sitter med samme ip som den "gode"... Kan også endre i php.ini slik at session ikke kan sendes via url... Lenke til kommentar
Mapster Skrevet 18. mars 2009 Forfatter Del Skrevet 18. mars 2009 Takker Flotte tips det der! All min php kunnskap er selvlært og lært når behovet har oppstått, så jeg har en del spørsmål i forhold til ting jeg bare anntar er sant. Her er noen påstander jeg antar er sanne, flott om noen kan rette meg .php filer på en web server kan ikke personer som kun har http tilgang til serveren se innholdet i? Dvs. jeg kan lagre innloggingsinfo til mysql database i variabler i en php-fil uten problemer. Variabler i php-skript har ikke vanlige brukere mulighet til å se verdiene til. Ingen kan utnytte funksjoner i php filer på min server, uten å ha tilgang til å endre en fil vha. shell,ftp e.l.. Det er derfor ikke nødvendig å kontrollere i starten av en funksjon om den kalles på av en som skal ha rettighet til det. Det holder å gjøre dette i skriptet som kaller funksjonen. Lenke til kommentar
veliro Skrevet 18. mars 2009 Del Skrevet 18. mars 2009 Takker Flotte tips det der! All min php kunnskap er selvlært og lært når behovet har oppstått, så jeg har en del spørsmål i forhold til ting jeg bare anntar er sant. Her er noen påstander jeg antar er sanne, flott om noen kan rette meg .php filer på en web server kan ikke personer som kun har http tilgang til serveren se innholdet i? Dvs. jeg kan lagre innloggingsinfo til mysql database i variabler i en php-fil uten problemer. Variabler i php-skript har ikke vanlige brukere mulighet til å se verdiene til. Ingen kan utnytte funksjoner i php filer på min server, uten å ha tilgang til å endre en fil vha. shell,ftp e.l.. Det er derfor ikke nødvendig å kontrollere i starten av en funksjon om den kalles på av en som skal ha rettighet til det. Det holder å gjøre dette i skriptet som kaller funksjonen. 1: Kode mellom <?php ?> blir håndtert av server, dermed stemmer det du sier at ingen andre kan lese det som står der. Men om php-serveren skrus av før webserveren blir teksten lesbar. Det er ikke akkurat stor sannsynlighet for at dette skal skje, men alikevell skader det ikke å ta forhåndsregler. Det koster ingenting å legge sensitiv informasjon som brukernavn og passord til databasetilkoblingen i en fil utenfor web-område. 2: Sant, med mindre du har et php-script som gir variabelverdien ved $_POST / $_GET etc. Men det kommer jo ann på hva koden din gjør (se 3)... 3: Stemmer det med funksjoner, men regner med du bruker knapper og $_POST eller url og $_GET, da kan en annen bruker greie å utføre funksjonene. Denne brukeren kan lage sin egen form (på sin egen side), og sende action mot din side, da vil ditt system håndtere forespørselen som om henvendelsen kom fra ditt eget script. Derfor kan det være en ide å sikre metodene (om du har en funksjon kun admin skal bruke kan du f.eks. sette en session-variabel til true på alle administratorene og bruke denne som ekstra sjekk i funksjonen). En annen ting, regner med du vet det, men å sikre seg mot sql-injections er viktig! Dette er også kun selvlært, så rett meg om jeg tar feil i noe av det ovenfor PS: Lurt å lese om session-hi-jacking, sql-injections og cross-site-scripting da dette er viktig for sikkerheten. Lenke til kommentar
Mapster Skrevet 19. mars 2009 Forfatter Del Skrevet 19. mars 2009 Takker Har lest en del om sql-hijacking og har lært meg å gjøre det selv på amatør nivå, for å forstå hvordan det fungerer og kunne motvirke det. Men bør vel gjerne oppfriske det litte grann. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå