Session sikkerhed

Tags:    sessions sikkerhed login

Hej Alle.

Har søgt lidt herinde, men den tråd jeg kunne finde der mindede mest om mit spørgsmål var over 2 år gammel, og imellem tiden kan der jo være sket en hel masse:-)

Mit spørgmål er:
Vi benytter os af sessions til vores bruger login, dvs. når en bruger logger ind, så gemmer vi hans bruger id og hans rettigeheder (administrator, alm user) i sessionen.

Er der noget vi skal være opmærksom på mht. sikkerhed og hvordan beskytter vi os bedst?

Hvis nogle havde nogle gode forslag ville det være rart(guides, søgeord m.m), for har søgt meget på nettet, men der er simpelthen så mange ting man kan gøre, så det jeg er ude efter er nogle ting, som man simpelthen skal huske, ligesom man ikke sender person følsom data med en GET men med en POST..

Er i, i tvivl om noget, så bare råb højt:-)

Mvh og på forhånd tak.

Andreas



9 svar postet i denne tråd vises herunder
3 indlæg har modtaget i alt 16 karma
Sorter efter stemmer Sorter efter dato
Om du bruger GET eller POST er sådan set ligemeget. Personfølsomt data bør sendes krypteret (altså med https).

Til gengæld bør kun POST requests bruges, hvis du vil ændre på noget på server siden...altså, hvis du vil logge ind, oprette en bruger, sende en mail eller den slags.

GET bør kun bruges til at hente informationer, ikke oprette/ændre.

Mht. sessions så søg på "Cross Site Scripting" (xss) og "Session Hijacking".



Indlæg senest redigeret d. 30.03.2012 13:26 af Bruger #2695
Hej Andreas.

Der er så to steder du har glemt at kigge.
Tjek altid hos:
- The New Boston
- PHPacademy

Her er en video og SESSION





Gustav. Man kan ikke sniffe traffik mellem to maskiner bare fordi man kender deres adresser. Man skal kontrollere en maskine, som står i ruten mellem de to maskiner for at det skal kunne lade sig gøre.

XSS kan man ikke beskytte sig imod via PHP settings, for man kan meget andet end at stjæle cookies.



Sessions benytter cookies, som ikke er andet end simple tekst filer. De er per definition ikke sikre.

Generelt kræver det for en ondsindet hacker at han kender både serveren og clientens adresse. Gør han det, så er det bare at sniffe trafikken, og så er det ret nemt at lade som om man er den rette ejer af pågældende session. For at undgå det er der forskellige vinkler du kan tage.

Der er to vinkler til den slags angreb - enten kender hackeren clientens adresse på grund af XSS (som Robert omtaler) og det burde du sikre dig mod i første omgang. Hvis det ikke er muligt at lave noget i den dur, så skal hackeren skaffe clientens adresse på en anden facon.

Det eneste sikkerheds tiltag mod XSS-scripting som du kan tage er at sætte php indstillingen session.cookie_httponly - hvis den er sat, så kan en ondsindet hacker ikke læse session_id fra cookien via Javascript som er den hyppigste metode til sniffing af sessions via XSS. iniset('session.cookie_httponly', true); bør bruges før du over hovedet starter en session i dine scripts.

Den anden angrebsvinkel er hvis du kender clientens adresse af andre veje - for eksempel hvis du sidder på samme WIFI netværk. Den type angreb er sværrere - men en god ide er at bruge session_regenerate_id(), som minimum hver gang brugeren skifter rolle (fx ved login). Det der sker er at session_id'et bliver ændret og derved er et gammelt sniffet id ikke noget værd.

Andre tjek man kan bruge er at gemme en session med værdien af ip'en som brugeren havde da de oprettede pågældende session. Så sammenligner du bare den nuværende ip med den oprindelige ip og hvis der er en forskel beder du brugeren om at logge ind igen. IP adresser kan teoretisk ændres i løbet af en session - men det hører nok til sjældenhederne og brugerne vil næppe brokke sig væsenligt over at skulle logge ind en ekstra gang i ny og næ. Alternativt kan du bruge et hash af dele af http-headeren.

Det er et emne som der bliver skrevet en masse om - og der er meget mere at sige end det jeg har ridset op. Men til det meste vil en implementering af de nævnte teknikker være rigeligt

Men som Robert også siger, så er https uundgåeligt hvis du har med personfølsomme oplysninger at gøre. Jo mere de oplysninger du ligger inde med er værd, jo mere skal du beskytte dig.



Undskyld at jeg genopliver den her gamle tråd, men jeg er først lige vendt hjem fra ferie...

@Robert, Du har ret i at det kræver et man-in-the-middle angreb, Fx via en usynlig iframe der er smidt ind på en side som clienten besøger, for at sniffe trafikken. Det gælder dog ikke på trådløse netværk... Tak for rettelsen.

I forhold til XSS beskyttelse via PHP config - så siger jeg at det eneste tiltag der kan gøre en forskel er session.cookie_httponly - og det holder jeg nu stadig på er korrekt. Det er ikke en 100% sikker løsning - men det er der i øvrigt ingenting der er.



cookie_httponly benytter en teknik som ikke er tilgængelig i alle browsere, så den er lidt farlig at bruge.

Der ér en 100% sikker løsning...undgå fejl :-)

Undgå at brugerne har mulighed for at skrive HTML eller JavaScript på siden. Skal de have mulighed for at skrive markup så giv dem BB code eller lignende, HTML er for "farligt".

Og det gælder forøvrigt også alle IDer i URL'en. Man skal forvente, at et ID i URLen indeholder HTML.
Er man forsigtig (paranoid), så kan man sikre sig, men det kræver en hel del arbejde.



Inputvalidering er ikke meget værd hvis det ikke er selve din webapp der er entry point - så det er jo heller ikke en 100% sikker løsning. ;-)



Den forstod jeg ikke...hvad mener du ellers at entry point kan være ?
Vi har jo ikke fået andet at vide.



Svagheder i systemet som driver din webapp. Men selvfølgelig er inputvalidering et must. Men det er ikke svaret på alt. :-) Anyway - lad os lukke den her. Det virker som om Andreas har fået hvad han kom efter.



t