ve_gard Skrevet 18. april 2007 Del Skrevet 18. april 2007 Har en side.. kjører autentisering og lager så en session variabel med et eller annet innhold. Sidene sjekker så på om session-variabelen med det hasha innholdet eksisterer og viser siden om det gjør. ex: if($_seesion['login']) { echo 'innholdet vises';} else{echo 'siden vises ikke';} Lurer på om jeg heller skal skrive en funksjon som bruker session variabelen til å viderebringe en brukerID og sjekke denne opp mot brukerdatabasen.. for så returnere true or false f.x. Noen som har noe innspill.. forslag eller innvendinger til hvordan på en best mulig sikre websiden's interne sider. mvh Vegard Lenke til kommentar
Ståle Skrevet 18. april 2007 Del Skrevet 18. april 2007 logge inn, sjekke brukernavn og pw mot DB, lagre hash i session og brukernavn i session, sjekke hash og brukernavn for hver side. eller? Lenke til kommentar
ve_gard Skrevet 18. april 2007 Forfatter Del Skrevet 18. april 2007 sjekke hasj for hver side ja... Lenke til kommentar
grimjoey Skrevet 20. april 2007 Del Skrevet 20. april 2007 (endret) har ikke så mye for seg etter hvordan jeg innbiller meg at session fungerer... *bruker spør etter side. *server svarer med side_ikke_innlogget. *bruker skriver inn brukernavn og passord. *server sjekker dette opp mot database og returnerer side_logget_inn dersom success. server setter samtidig en cookie på bruker med en unik tilfeldig ID (SID). alle variabler som blir lagt i $_SESSION[] arrayet blir lagret på server med en referanse til SID. altså hvis du sjekker $_SESSION[] variabelene for hver gang vil de uansett vise det samme, selv om det er en hijacker som har sniffet og gjenskapt cookien med SessionID ettersom alle variablene er bundet til denne referansen. det man kan gjøre er å sjekke ip, browser, traceroute, ping(krever høy toleranse og gjentatte forsøk før feiling), og andre verdier som varierer med brukerene. har du peil på javascript kan du implementere en challenge-response mekanisme. ved innlogging: *server sender side (side inkluderer 2 stk av noe som kalles en nonce. en kryptografisk sikker tilfeldig verdi) *bruker skriver inn brukernavn og passord. javascript/java utfører en hashing funksjon på passord -> resultat = sha(passord). så utfører javascript/java en hashing funksjon på resultat + nonce og resultat + nonce2. (dette genererer verdier/nøkkler som er tilfeldige pga nonce, men kan fortsatt bekreftes fordi server og klient har all nødvendig informasjon. en eventuell sniffer mangler passordet og kan ikke gjenskape nøkkelen fordi den er tilfeldig for hver gang pga tilfeldig nonce.) den ene nøkkelen lagres som en cookie verdi lokalt gjennom javascript (den sendes ikke til server så ingen kan sniffe den). den andre nøkkelen sendes til server sammen med brukernavn for authentisering. når serveren responderer med en ny side kommer en ny nonce. java/javascript sørger for å lage en ny nøkkel ved å gjøre en hashing på cookie verdien + ny nonce. så når neste side etterspørs kan denne nøkkelen blir brukt til å authentisere. også gjentar den siste runden seg. hver eneste nøkkel er tilfeldig så det skal ekstremt mye til før den "sessionen" blir hijacket. bakdelen er at det kun funker med javascript+cookie. (det er ikke alle som har det enablet). og alle passord eller hashes som er lagret i databasen blir en større risiko. ettersom de kan bruke til å generere nøkkler sammen med nonce. Endret 20. april 2007 av grimjoey 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å