Session sikkerhed

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".

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.