Beskyttelse mot session hijacking...?

[South_Bridge]

Jeg lurer på om det er en universell, grei måte å beskytte session slik at andre ikke kan ta over min session når jeg starter session... noen som gidder å poste kode/linker til tutorial? :-)

 

PHP og jeg er et ganske nylig opprettet vennskap, har fått til login med md5 mot MySQL som fungerer ganske greit. men jeg skulle ha hatt en sjekk på sidene min slik at folk ikke kan trykke inn url til feks addnyhet siden min og bypasse login helt... igjen: noen som gidder å poste kode/linker til tutorial?

[BigJackW]

<?php
session_start();

$user = "south";
$pass = "_bridge";

if ( $_POST['username'] == $user && $_POST['password'] == $pass ) {
/**
 * Du er logget inn
*/
$_SESSION['auth'] = TRUE;
} else {
/**
 * Feil brukernavn / passord
 * Setter auth til false for å være på den sikre siden.
*/
$_SESSION['auth'] == FALSE;
}
?>

 

På siden du vil sikre:

<?php
if ( !$_SESSION['auth'] ) {
	header("location: login.php");
	die;
}
?>

 

Vil si at sha1() er bedre å bruke enn md5, da md5 kan uten så alt for store problemer brute-forces/dictionary-hackes.

 

Tror btw du ikke har googla det

Endret 28. januar 2008 av BigJackW

[grimjoey]

bigjackw:

hvordan beskytter dette mot hijacking?

 

south_bridge:

du kan ikke beskytte deg mot "man in the middle" attack. dette kan kun gjøre med sertifikater tror jeg.

 

du bør være obs på sql-injection, cross-site scripting, spam og session hijacking.

 

session hijacking kan nesten forhindres dersom du sletter og oppretter session for hver request

 

kanskje noe slikt:

<?php

session_start();

if ( $auth = $_SESSION['auth'] ) {
 session_destroy();
 session_start();
 $_SESSION['auth'] = $auth;
}

if (/* verify user code here */) {
 $_SESSION['auth'] = TRUE;
}

?>

 

for å forhindre det helt må du lage en session handler som benytter "challenge-response", eller bruk innebygde http auth digest.

 

challenge-response genererer en unik session id for hver request. forrige kode-eksempel lager en unik session id for hver request, men den blir brukt to ganger. først sendt fra server til klient, så sendt tilbake. dette er ikke tilfelle med challenge-response.

 

for å lage egen challenge-response handler må du benytte ajax eller frames sannsynligvis.

 

red: man in the middle angrep kan hindres ved bruk av ssl. for at det skal kunne utføres et man in the middle angrep må angriperen være klar i det du starter key negotiation (første request til et beskyttet område). dette er da sannsynlig et målrettet angrep og er vanskelig å sikre seg mot (utover den sikkerheten som allerede eksisterer uansett), men hender skjelden privatpersoner.

Endret 28. januar 2008 av grimjoey

[Ueland]

Det kjappeste du kan gjøre av tilltak er å lagre en oversikt over hvilken IP og nettleser den aktive sesjonen har, da vil du få stoppet en god del av "grumset".

 

Dette forumet f.eks gjør oppslag i en databasetabell med sessionID, nettleser og IP som nøkler.

[grimjoey]

eller lagre ip, remote_port og nettleser (nettleser kan enkelt spoofes så det er egentlig ikke vits) i $_SESSION, og sjekke dette mot hva klienten sender. da slipper du unødig database masing.

 

red: dette er sikkert kun dersom du har sikker lagring av session filene. (beskytter mot sniffer angrep mao) har du usikker lagrning av session filene er database det sikreste.

 

red: leif

Endret 28. januar 2008 av grimjoey

[BigJackW]

bigjackw:

hvordan beskytter dette mot hijacking?

 

Virket som om han ikke hadde noe form for sikkerhet på administrasjonssidene ...

 

Edit: Derfor et lite eksempel på bruk av seessions.

 

grimjoey:

men jeg skulle ha hatt en sjekk på sidene min slik at folk ikke kan trykke inn url til feks addnyhet siden min og bypasse login helt

 

Endret 28. januar 2008 av BigJackW

[grimjoey]

jeg antok at han brukte sessions ettersom han har en login side mot mysql med md5 som funker greit, men jeg kan selvfølgelig ta feil.

 

godt eksempel. jeg ville endret måten du sammenligner strengene på men.

 

if ( 123 == "123alksdn" ) print 'hei';

 

// vil printe 'hei';

 

strcmp(); // er litt mer strict

 

if ( !strcmp( $passord, $_POST['passord'] ) ) print 'De er like';

 

// ! foran strcmp fordi strcmp returnerer "forskjellen" på strengene. altså 0 hvis de er like.

[pulse]

... strcmp(); // er litt mer strict

Hva med "===" ?

[Crowly]

Har postet denne noen ganger før

  session_start();
 if(version_compare('5.1.0', phpversion(), '>'))
session_regenerate_id(); 
 else 
 { 
unlink(ini_get('session.save_path').'/sess_'.session_id()); 
session_regenerate_id(); 
 }

 

Vil gjøre det noe vanskeligere å ta over en session, da id'en kun er gyldig en kort periode. grimjoey tror jeg postet en annen metode som har litt bedre, i en annen trå. Men denne er veldig enkel å legge til.

 

Kan også være greit å sette session.save_path, ini_set(session.save_path,"..."), til en katalog som ikke er delt av andre, spesielt hvis man kjører på ett web hotell med mange andre brukere/kunder.

[South_Bridge]

Har postet denne noen ganger før

  session_start();
 if(version_compare('5.1.0', phpversion(), '>'))
session_regenerate_id(); 
 else 
 { 
unlink(ini_get('session.save_path').'/sess_'.session_id()); 
session_regenerate_id(); 
 }

 

Vil gjøre det noe vanskeligere å ta over en session, da id'en kun er gyldig en kort periode. grimjoey tror jeg postet en annen metode som har litt bedre, i en annen trå. Men denne er veldig enkel å legge til.

 

Kan også være greit å sette session.save_path, ini_set(session.save_path,"..."), til en katalog som ikke er delt av andre, spesielt hvis man kjører på ett web hotell med mange andre brukere/kunder.

 

sikkert helt nabb og spørre, men hvordan validerer jeg da login på andre sider? feks nyhetsiden min hvor jeg legger inn nyheter hvor jeg først vil sjekke at brukeren har riktig generert session generert id?

[grimjoey]

if ( $_SESSION['auth'] ) //bruker er innlogget

else //bruker er ikke innlogget

 

jeg fåreslår at du leser litt om session_start() og $_SESSION på php.net

Endret 28. januar 2008 av grimjoey

[Crowly]

 

Har postet denne noen ganger før

  session_start();
 if(version_compare('5.1.0', phpversion(), '>'))
session_regenerate_id(); 
 else 
 { 
unlink(ini_get('session.save_path').'/sess_'.session_id()); 
session_regenerate_id(); 
 }

 

Vil gjøre det noe vanskeligere å ta over en session, da id'en kun er gyldig en kort periode. grimjoey tror jeg postet en annen metode som har litt bedre, i en annen trå. Men denne er veldig enkel å legge til.

 

Kan også være greit å sette session.save_path, ini_set(session.save_path,"..."), til en katalog som ikke er delt av andre, spesielt hvis man kjører på ett web hotell med mange andre brukere/kunder.

 

sikkert helt nabb og spørre, men hvordan validerer jeg da login på andre sider? feks nyhetsiden min hvor jeg legger inn nyheter hvor jeg først vil sjekke at brukeren har riktig generert session generert id?

 

Det er en forskjell på å validere login, og session hijacking. Session hijacking slik jeg har forstått det vil si å ta over en session fra en annen bruker. F.eks du logger inn og alt er ok, så ved noen fine triks klarer jeg å få tak i din session id, da vil nettsiden tro at jeg er deg og ferdig logget inn.

Kodesnutten min gjør ingenting med login delen, den bare oppdaterer/endrer session id'en hver gang brukeren laster siden på nytt, så hvis noen skulle klare å få ta i session id'en, så vil den kun være gyldig i ett lite tidsrom. Noe som burde gjøre den verdiløs.

 

Session hihacking definisjoner

Fra http://www.h-spot.net/threat_glossary.htm

Session hijacking:

Whereby an attacker commandeers a TCP Session from a legitimate user after the legitimate user has achieved authentication, thereby removing the need for the attacker to authenticate himself.

 

fra http://en.wikipedia.org/wiki/Session_hijacking

The term session hijacking refers to the exploitation of a valid computer session - sometimes also called a session key - to gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer (see HTTP cookie theft).

[j000rn]

Kodesnutten min gjør ingenting med login delen, den bare oppdaterer/endrer session id'en hver gang brukeren laster siden på nytt, så hvis noen skulle klare å få ta i session id'en, så vil den kun være gyldig i ett lite tidsrom. Noe som burde gjøre den verdiløs.

 

Nei. Kodesnutten din vil gjøre at jeg TAR OVER session'n til brukeren, -- og brukeren vil bli logget ut mens jeg kan fortsette å late som om jeg er han. Uten koden din vil både brukeren og jeg kunne bruke den samme session'n.

 

Se heller på hva som EGENTLIG er problemet, nemmelig at noen får ta i session'n. Dette kan angriperen gjøre på 2 måter:

* Sniffing av pakkene på nettverket

* Han har tilgang til maskinen og kan lese cookie fra RAM/disk.

 

Å unngå at pakkene blir sniffet løser man enklest og best med SSL.

 

Om angriperen har tilgang til maskinen og klarer å lese RAM/disk så er man screw'ed uansett....

Endret 28. januar 2008 av jorn79

[Crowly]

Nei. Kodesnutten din vil gjøre at jeg TAR OVER session'n til brukeren

Ja det er svakheten, men du må klare det før session id blir endret. Finnes sikkert bedre metoder.

[grimjoey]

du kan se på denne

 

det er session håndteringen jeg skrev en gang som benytter challenge-response. (alltid unik session id)

 

den er usikker slik den står i dag. (den benytter cookies til lokal lagring og cookies blir sendt over nettverket)

 

dersom du bruker dojo frameworket til java skal du kunne klare å endre scriptet til å benytte dojo.storage (funker kun i ie, firefox og browsere med flash plug-in installert) i stedet for cookies til å lagre lokalt. da skal den være ganske sikker mot session hijacking. ( obs: det er mitt første forsøk på OOPHP)

Endret 28. januar 2008 av grimjoey

[BigJackW]

Vær oppmerksom på at den klassen til grimjoey er laget for PHP4.

Men du kan bare endre på synligheten på variablene. (Om bruk bruker PHP5 selvfølgelig.)

 

F.eks. fra:

 

  var $theQuery; // Holds query before escaped.
 var $escQuery; // Holds query after escape.

 

til:

  private $theQuery; // Holds query before escaped.
 private $escQuery; // Holds query after escape.

Endret 28. januar 2008 av BigJackW

[j000rn]

Nei. Kodesnutten din vil gjøre at jeg TAR OVER session'n til brukeren

Ja det er svakheten, men du må klare det før session id blir endret. Finnes sikkert bedre metoder.

 

Det er ingen som sitter å taster inn sessionID'n på tastaturet, dette blir selvfølgelig gjordt programatisk. Og da er det samme for angriperen om det tar 10 sec eller 2 timer mellom hver gang ID'n forandrer seg...

 

Min mening er at dette bare blir innbilt "sikkerhet". Og sessions er vel også ressurskrevende å lage/ødelegge? Dessuten kan det brukes til å lage statistikk over bruken av site'n fra performance countere. Dette går ikke når man lager ny session for hver eneste request.

 

En annen ting er at brukeren ikke får lov å ha oppe 2 vinduer samtidig. Det ene vinduet vil da alltid bli logget ut. Dermed er også løsningen håpløs om man bruker frames/iframes, generering av bilder, etc.

[grimjoey]

man må jo tilpasse etter eget behov. er ikke sikkert trådstarter trenger performance counter og iframes. men det er helt klart et poeng at session id kan fortsatt stjeles ved sniffing.

 

scriptet jeg lagde er skrevet og testet i php5. jeg var bare litt umoden i oophp og skrev litt javascript samtidig, så jeg brukte var og det funka. endre gjerne til public/private/protected der det passer seg. merk at det ikke finnes noen variabel liknende $_SESSION i scriptet mitt. men session_start() kan brukes ved siden av c-r authentiseringen for å lagre ting relatert til brukeren over flere requests.

[j000rn]

scriptet jeg lagde er skrevet og testet i php5. jeg var bare litt umoden i oophp og skrev litt javascript samtidig, så jeg brukte var og det funka. endre gjerne til public/private/protected der det passer seg. merk at det ikke finnes noen variabel liknende $_SESSION i scriptet mitt. men session_start() kan brukes ved siden av c-r authentiseringen for å lagre ting relatert til brukeren over flere requests.

 

En ting du kan gjøre i koden din for å slippe å spørre databasen for hver eneste request er å "cache" denne informasjonen i Session. Siden autentiseringen fortsatt skjer ved hver request gjør det da ikke noe om session'n blir stjålet, siden den ikke blir brukt til selve autentiseringen

[grimjoey]

hehe. se innlegg #4 og #5. doh!

Endret 28. januar 2008 av grimjoey