Optimal session sikkerhed

Tags:    php

Jeg har prøvet på at finde ud af hvordan jeg vil arbejde med mine sessions, og jeg leder efter den mest sikre metode til at gemme at en person er logget ind.

Det første script jeg lavede en gang var noget i stil med:
Fold kodeboks ind/udPHP kode 


Hvilket jo ikke er særlig sikkert da man bare kunne sætte sin session til det, og så kom man ind. Nu sidder jeg og tænker på den maksimale sikkerhed, og jeg har tænkt på nogle forskellige ting, f.eks:
Fold kodeboks ind/udPHP kode 


men kender man en persons IP så kan man også fuske med den.

Så nu overvejer jeg noget i stil med:

Fold kodeboks ind/udPHP kode 


så en session kunne være "Test84.291.28.123ab847zk2"
og det kunne jeg så tjekke op imod. Men hvad bruger i egentlig? Og hvad er den simpleste og mest sikre måde og gøre det på.



Indlæg senest redigeret d. 08.07.2008 20:41 af Bruger #13808
9 svar postet i denne tråd vises herunder
3 indlæg har modtaget i alt 3 karma
Sorter efter stemmer Sorter efter dato
.. Hvorfor ikke bare bruge en variabel med et normalt navn, fx. dit domæne og en understreg og så fx. username.

Fold kodeboks ind/udKode 




Sessions er baseret på cookies. Hvad du ikke ved er at når en session bliver etableret, oprettes et unikt id som så gemmes i en småkage på klienten.
Id'et herfra bliver så brugt til at allokere den session der passer samme klient.

Det man kan gøre for at sikre at færrest computere har adgang til samme session er at gemme ip og session id i session variablen.
Fold kodeboks ind/udPHP kode 

Kan ikke huske den nøjagtige opsætning, men det kan der eksperimenteres med.



Indlæg senest redigeret d. 08.07.2008 22:28 af Bruger #10216
#Dennis.

Hvis folk kan eksekvere PHP kode ved at indtaste det på din side, så har du et ganske stort sikkerhedsproblem.
Men det bør de ikke kunne, og så kan du jo ikke indtaste den sesssion-kode der. Sessions er server-side cookies, og folk kan derfor ikke ændre det.

Det eneste de kan ændre, er SESSID-cookien - men så er man også uheldig hvis de "hackerne"/"crackerne" får fat i et fungerende SESSID. Hvis man virkelig gerne vil være sikker mod dette og er paranoid, så gør som Gnu siger.
Ja, man skal være paranoid når man laver hjemmesider, men sikkerhedstjek på sessions, bruger jeg ikke selv.



Jeg bruger bare den løsning, som du også brugte først. Jeg kan ikke umiddelbar se hvordan du vil fuske med en session. Jeg kunne nemt se hvordan du ville fuske med en cookie, men ikke med en session.



Gnu, nu har jeg ikke lige sat mig ind i hvordan en onion router som TOR arbejder helt præcist, men såvidt jeg ved kan den samme klient godt foretage forskellige routes til samme host. I sådan et tilfælde ville din kode vel nægte brugeren adgang til siden, selv om vedkommende egentlig bare ønskede at være anonym på internettet?

Til Dennis:
Sessions i PHP er server side. Klienten kan aldrig ændre på data i sessionen selv, det kan kun din kode gøre. Session er såvidt jeg ved den eneste bruger-inputs-global som PHP har, som du kan stole på. POST, GET og COOKIE kan du derimod aldrig stole på.




Til Dennis:
Sessions i PHP er server side. Klienten kan aldrig ændre på data i sessionen selv, det kan kun din kode gøre. Session er såvidt jeg ved den eneste bruger-inputs-global som PHP har, som du kan stole på. POST, GET og COOKIE kan du derimod aldrig stole på.


Hvis nu du har den her på en side til et login script:

Fold kodeboks ind/udPHP kode 


lad os sige det er www.minside.dk

Det ved vores mini-hacker så, og skriver på siden egen side:

Fold kodeboks ind/udPHP kode 


men som gnu siger laver den selv et id :)



Indlæg senest redigeret d. 09.07.2008 00:43 af Bruger #13808
Sessions gemmes på serveren hvor scriptet køres.



#Niklas

Jeg spurgte fordi jeg gerne ville vide hvordan andre folk gør det, og hvis du bliver negativ på grund af det kan du da bare lade være med at skrive.

Men tak til jer andre :)




#Dennis.

Jeg undskylder da hvis du opfanger det negativt, for det var ikke sådan ment.
Jeg ville bare gøre dig opmærksom på at sessions ligger på serveren, og kan derfor kun ændres via PHP. Derfor skal en eventuel besøgende "cracker" altså have adgang til eksekvering af PHP.



t