Login script.

[jic]

Hei jeg har laget en forum og chatbox script, og jeg tror jeg vil prøve å lage en login script. Vel det jeg lurer først på om hva som passer best.

 

Cokies eller sessions. Som jeg har søkt og sett på kilde koder på diverse login script så er det session som er blitt brukt.

 

Det andre jeg lurer på om det er mulig.

<? 
if(session_is_registered(brukernavn)) 
{ 
print("Hemmelige innholdet!"); 
} 
else 
{ 
print("Du må logge inn for å se denne siden!"); 
?> 

 

Er det mulig at innholde blir printet ut slik,

 

<? 
if(session_is_registered(brukernavn)) 
{ 
print("Du må logge inn for å se denne siden!"); 
} 
?>

<img src="etellerannet.jpg">
<?
print("Hemmelige innholdet!"); 
} 

?>

 

Rekke følgen ikke er samme.

[????????]

Cookies lagres hos brukeren, og han eller hun har muligheten til å endre den. Videre er det ikke alle som har Cookies enabeld. Så det kan oppstå problemer ved å velge Cookies.

 

Sessions lagres på servere, og er vanskligere å hacke, men ikke umulig - ta en kikk på security i manualen. Videre må brukeren logge seg inn på nytt hver gang de kommer til nettstedet ditt.

 

Hvis du ikke kjører en veldig gammel versjon av PHP, eldre enn 4.1, så kan du bruke $_SESSION.

 

For å sjekke om en session er satt, bruker du f.eks.:

 

if(isset($_SESSION['variabel'])){

echo "variabelen har denne verdien ".$_SESSION['variable'];

}else{

echo "variabelen har ingen verdi";

}

 

Det er like lett å lagre til en session, f.eks.

$_SESSION['variabel'] = "EnVerdi";

 

Glem ikke session_start();

 

 

Det er lurt å lagre både brukernavn og passord i sessions - og sjekke disse mot en eventuell database for hver side som lastes - siden det er mulig å hacke sessions holder det ikke å sjekke om den finnes. Det samme gjelder for Cookies.

Regner også med at du krypterer passordet for sikkerhetens skyld. Passord skal aldri lagres ukryptert - ikke en gang i databaser!

 

Lykke til!

[jic]

Cookies lagres hos brukeren, og han eller hun har muligheten til å endre den. Videre er det ikke alle som har Cookies enabeld. Så det kan oppstå problemer ved å velge Cookies.

 

Sessions lagres på servere, og er vanskligere å hacke, men ikke umulig - ta en kikk på security i manualen. Videre må brukeren logge seg inn på nytt hver gang de kommer til nettstedet ditt.

 

Hvis du ikke kjører en veldig gammel versjon av PHP, eldre enn 4.1, så kan du bruke $_SESSION.

 

For å sjekke om en session er satt, bruker du f.eks.:

 

if(isset($_SESSION['variabel'])){

echo "variabelen har denne verdien ".$_SESSION['variable'];

}else{

echo "variabelen har ingen verdi";

}

 

Det er like lett å lagre til en session, f.eks.

$_SESSION['variabel'] = "EnVerdi";

 

Glem ikke session_start();

 

 

Det er lurt å lagre både brukernavn og passord i sessions - og sjekke disse mot en eventuell database for hver side som lastes - siden det er mulig å hacke sessions holder det ikke å sjekke om den finnes. Det samme gjelder for Cookies.

Regner også med at du krypterer passordet for sikkerhetens skyld. Passord skal aldri lagres ukryptert - ikke en gang i databaser!

 

Lykke til!

Takk skal du ha for all infoen jeg har prøvd å forandre på cokies, men greide ikke det.

 

• Hvordan encrypter jeg passord
  
• hvis jeg kjører include script kan jeg ha session på indexfilen, og resten av session kode på include filen, vil det fungere
  

Fordi jeg har brukt inlclude i alle filene som jeg har.

[Torbjørn]

hva har det noe å si om man legger brukernavn/passord i session eller ikke - med tanke på sikkerhet?

[????????]

Bare du ikke har noe output før sessionen så kan du ha den der du vil.

kikk i manualen på md5() og crypt() for å se to løsninger til hvordan du kan kryptere passordet.

[Torbjørn]

jeg pleier å inkludere en fil øverst, før noe input, som sjekker sessions evt cookies.

[????????]

hva har det noe å si om man legger brukernavn/passord i session eller ikke - med tanke på sikkerhet?

Tenker du på i session i steden for cookie eller at man like gjerne bare kan lagre $_SESSION['LoggetInn'] = "ok"?

 

Hvis du tenker på Cookies er det forde da kan hvem som helst endre de - og det er ikke alle som har det enabled.

 

Tenker du der i mot på å lagre passord og brukernavn i motsettning til å bare lagre f.eks. "ok" vil jeg si MEGET STOR. Har du en liten side og ikke bryr deg om sikkerheten er den kanskje ikke så stor, men det tar ikke lang tid å gjøre scriptet sikkert.

 

Problemet med session er at de kan hackes de også. Er man på samme webhotell som en hacker kan han enkelt lagre sessions på ditt område. Videre finnes det mange andre måter å hacker og "lytte" på sessions.

 

Ved å lagre kryptert passord og brukernavnet kan det sjekkes. Da må noen legge inn rett variabler - så da hjelper det ikke om noen lagre en fake session om den har feil verdi.

 

For de som vil ha mer sikkerhet kan man også opprette en logget inn database og bruke session_id. Da slipper man å tenke, i alle fall like mye, på de som "lytter på" sessionene og lagrer variabler de finner i kommunikasjonen mellom brukeren og serveren.

 

I tillegg anbefaler jeg SSL!

[Torbjørn]

hvis noen lytter på http trafikken og snapper opp cookies, så er man like langt uansett hva som måtte ligge av sessiondata på disk. den cookien er likevel knyttet til sessiondata uavhengig av hva som ligger av data i session'en (altså, om det ligger brukernavn der eller ikke)

 

jeg regner med du mente man skulle ha krypterte passord i session data? det ungår selvsagt at noen kan lese sessiondata på disk og snappe det opp.

 

Hvis du vil hindre noen i å lese noe fornuftig fra sessiondata på disk, burde du kryptere brukernavn og. men det er egentlig uinteressant, hvis noen leser sessiondata der, finner de sessionid og kan sende den i en cookie til sidene dine.

[????????]

Tror jeg muligens kan ha forklart litt dårlig.

Jeg mente ikke at man skulle benytte cookies.

Torbjørn:

hvis noen lytter på http trafikken og snapper opp cookies, så er man like langt uansett hva som måtte ligge av sessiondata på disk. den cookien er likevel knyttet til sessiondata uavhengig av hva som ligger av data i session'en (altså, om det ligger brukernavn der eller ikke)

 

Sessions sendes ikke med browser headeren, slik som cookies gjør! Det er derfor man ikke kan bruke $_REQUEST på sessions, siden de sendes ikke ut av serveren.

 

 

Torbjørn:

jeg regner med du mente man skulle ha krypterte passord i session data? det ungår selvsagt at noen kan lese sessiondata på disk og snappe det opp

 

Jeg skrev at passord aldri skulle lagres ukryptert.

Det er lurt å lagre både brukernavn og passord i sessions - og sjekke disse mot en eventuell database for hver side som lastes - siden det er mulig å hacke sessions holder det ikke å sjekke om den finnes. Det samme gjelder for Cookies.

Regner også med at du krypterer passordet for sikkerhetens skyld. Passord skal aldri lagres ukryptert - ikke en gang i databaser!

 

Grunne til at nesten alle tutorials om login bruker sessions, er at det er tryggere enn cookies. Ved å lagre brukernavnet og passordet i en session og i tillegg lagre session_id i en database hjelper det ikke om de klarer å hacke sessions - da må de i tillegg hack databasen.

 

Skjønner ikke helt hva du mener med:

hvis noen lytter på http trafikken og snapper opp cookies, så er man like langt uansett hva som måtte ligge av sessiondata på disk.

- men så er jeg passe trøtt nå, så kanskje noe jeg har oversett?

Jeg mener at man burde bruke sessions, ikke cookies.

[Torbjørn]

hei, tilbake etter Team Antonsen,

 

sessions *sendes* som cookies til besøkeren!

 

han får typisk en cookie som heter PHPSESSIONID eller noe sånt (husker ikke detaljene)

 

Hvordan skal serveren ellers kunne identifisere brukeren, om ikke det er en eller annen del av HTTP trafikken som er relatert til sessionen?

 

Og som sagt, lytter man på http trafikken, er det et fett hva man lager i sessionen eller i cookien, snifferen får tilgang til cookien som identifiserer en evt. administrator eller annen innlogget person.

 

ved å matche en besøker mot både ip og cookie får man litt økt sikkerhet.

[????????]

Okay, da skjønner jeg hva du mener.

Trodde du mente å lagre både i cookie og i session. (PHPSESSID heter den forresten).

 

Den variabelen sendes av PHP i headeren, og returneres av brukeren for hver side som lastes. Poenget med å lagre brukernavnet og passordet er ført og fremst for de som er på et delt webhotell (som de fleste er).

 

php-mag fra desember skriver en liten artikkel om sessions og hvordan man kan forsøke å sjekke flere variabler om brukeren. Den ugaven finnes forresten gratis på nettet: www.php-mag.net

 

SSL vil hjelpe mye, men det koster en som regel en del - så å sjekke flere variabler er for mange det beste.

 

EDIT:

OpenSSL er gratis SSL alternativ! www.openssl.org

Endret 22. januar 2004 av ????????

[Torbjørn]

hvis noen leser variable direkte fra disk, skjønner jeg ikke helt hva man kan gjøre. mener du å lagre hele sessionen kryptert på disk?

[Torbjørn]

eventuelt angi en del av sitt eget webområde som lagringsplass for sessionen (den vil som regel være sperret for andre web hotell brukere), kanskje kalle en katalog .htxxxx for å sperre direkte tilgang også.

[????????]

hvis noen leser variable direkte fra disk, skjønner jeg ikke helt hva man kan gjøre. mener du å lagre hele sessionen kryptert på disk?

Nei, hvis man bare bruker isset($_SESSION['LoggetInn']) er det betraktlig større sjanse for at noen klarer å gjette det, enten av ren gjetting eller hvis PHP skulle svikte en dag så vises jo PHP scriptet. Det er derfor f.eks. passord til databasen og lignede burde lagres i en config fil i en mappe som er beskyttet.

Endret 22. januar 2004 av ????????

[Torbjørn]

jeg satte opp en liten test, det viser seg at man vanskelig kan begrense cookien til kun å gjelde for katalogen den blir laget i.

 

jeg satte opp en online demo her:

 

http://sirius.isa-geek.org/~lindahl/session_test/

 

brukeren 'hacker' prøver å komme seg inn på reserverte områder til brukeren 'secure'

 

hvis vi ser på secure sine filer, eks:

http://sirius.isa-geek.org/~lindahl/sessio.../secretpage.php

 

Her vil ikke alt vises, uten at man har satt sessionen 'hacker'. Kildekoden er vist som htmlfiler.

 

brukeren 'hacker' lager seg en slik fil, i hans katalog,

http://sirius.isa-geek.org/~lindahl/sessio...ker/session.php

 

etter at han har satt sin session 'hacker', kommer han seg inn på secure sine tilgangsbegrensede steder.

 

 

Ser for meg et par løsningsstrategier på dette:

• kjøre virtualhost - cookies vil begrense seg til en host
  
• tvinge gjennom individuelle session settings - i <directory> kan man angi individuelle session settings, og sånn sett knytte cookien fra en phpsession fil til den katalogen fila ligger i.
  
• lagre sessiondata individuelt hos brukeren - gitt at apache kjører med individuelle brukere, vil ikke andre brukere få tilgang til å lese session fra ditt område. problem er at man risikerer at sessiondata kan leses ved direkte tilgang. Dette løses ved å legge de i en katalog som begynner med .ht da apache sperrer for direkte accecss til .ht* adresser.
  

Jeg ser for meg kun alternativ 3 som helt sikkert, da man kan overstyre de to første ved å slenge på PHPSESSID=whatever i URL'en til en nabobrukers katalog. Med mindre man kan tvinge php til kun å bruke cookies for sessions. Noe som kanskje går an.

 

EDIT: BBCode list

Endret 23. januar 2004 av Torbjørn

[Torbjørn]

jeg må ete i meg det igjen, idet apache ikke kan kjøreø med individuelle brukere likevel... hm... eneste som gjenstår er en setuid cgiløsning...

[????????]

Ikke tenk så avansert, for det første - lagrer man kryptert passord og brukernavn i sessionene og sjekker disse er det ingen som kan se en "svak" kode, som:

if($_SESSION['LoggetInn'] == "ok")

 

Så lager man en logg inn tabell, og lagrer all info om brukeren der (som f.eks. ip og browser). Det opprettes bare en rad i tabell fra logginn skjemaet når en person har tastet rett brukernavn og passord.

 

For hver medlemsside de besøker så sjekkes brukernavn og passord i sessionen og så sjekkes logg inn tabellen. Da hjelper det mindre om man hacker sessionen, man må i tillegg legge til info i databasen.

[FuLu]

Blir kanskje litt offtopic, men er min erfaring. Mitt webhotell har Cobalt med PHP 4.1.2, hvor desverre session delen bugger. Jeg endte opp med å lage egen session klasse som bruker MySQL. Har etterhvert laget transparent funksjon, som endrer alle A HREF og om FORM inneholder en input med session id osv. Støtter også cookie.

 

Uansett, vil vel muligens bli noe vanskeligere å skrive over sessiondata, eller tvingen en session til å bli "logget inn" når dette er lagret i db'en.

[Torbjørn]

"ikke tenk så avansert" hehe, var mest ute etter å se gjennom hva som fantes av muligheter

[jic]

Vel det ser ut som php war starter snart her.

 

Takk for all infoen setter pris på det.