Beskyttelse mot session hijacking...?

j000rn · 28. januar 2008

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

Yeah, og hvis du har usikker lagring av databasen så er session-filene sikrest? :roll:

Hvis man ikke klarer å sikre serveren sin så er det vel bare å gi opp i første omgang, siden man da har betydelig større problemer enn session-hijacking etter min mening....

ze5400 · 29. januar 2008

EDIT: Leste nettop manualen, så plutslig hadde jeg ikke noe å si :blush:

Endret 29. januar 2008 av ze5400

South_Bridge · 1. februar 2008

Hmm... gjør et forsøk her. Ønsker gjerne veiledning, ikke så mye kommentarer Har bladd litt rundt(google, php.no osv). De bobler om den beste måten er da seff bruker og passordsjekk samtidig med en session_regenerate_id(), cookie... To sistnevnte er veldig ukjent for meg, så dukker også (!isset($_SESSION['initiated'])) som dere ser i scriptet mitt nedenfor.

SPM er, er denne biten fullført, og hvordan kontrollsjekker jeg da en side som jeg feks bare vil at 'Lars' skal ha tilgang til? Nøkkelen er sikkerhet

<html>

<body>
<p>Test for login!</p>

<?php
if(isset($_POST['add']))
{

$bnavn = $_POST['bnavn'];

// SJEKK MOT DATABASE FOR BRUKERNAVN OG PASSORD....

// Hvis brukernavnet og passord stemmer
if($bnavn =="Lars")
{
	echo "Velkommen: " . $bnavn;

	session_start();

	if (!isset($_SESSION['initiated']))
	{
    	session_regenerate_id();
    	$_SESSION['initiated'] = true;
	}
}
// Passordet stemte ikke.... 
else
{
	echo "Du hører ikke hjemme her!";
}
}
else
{
?>

<p>
<form method="post">
 Brukernavn: 
 <input type="text" name="bnavn" id="bnavn" />
 <input name="add" type="submit" id="add" value="OK">
</form>
<p>

<?php
}
?>
</body>
</html>

grimjoey · 1. februar 2008

Du kan ikke gjøre session_start() etter:

"<html>

<body>

<p>Test for login!</p>"

Det er aldri noen grunn (som jeg vet om) til å ikke sette session_start() i starten av filen.

Og bruk gjerne !strcmp($bnavn, "Lars") for å sammenlikne strenger.

South_Bridge · 2. februar 2008

da har jeg missforstått konseptet med session_start(). men igjen da... hvordan blir det da? skal jeg feks ta vare på en session_generated_id og sjekke den på sider som jeg vil beskytte?

grimjoey · 2. februar 2008

session_start() starter en session.

Det gjør den på følgende måte:

PHP prøver først å sette en cookie med navn PHPSESSID og verdien session_id() som er en "tilfeldig" md5 sum (tror jeg).

Så forsøker PHP å lese cookien (for å sjekke at klienten støtter cookies).

Dersom klienten støtter cookies, fortsetter PHP å lese PHPSESSID cookien hver gang for å sjekke at det er samme bruker.

Dersom klienten ikke støtter cookies, legger PHP PHPSESSID=session_id() til en get variabel i alle linker på siden som ikke går til ekstærne sider.

Slik får den session_id() gjennom $_GET[] arrayet.

Alt dette gjøres automatisk.

Scriptet får et $_SESSION[] array som gjelder for hver enkelt bruker med hver sin session_id().

Du trenger ikke lagre session_generate_id(). PHP husker på den selv. Det eneste du skal benytte er $_SESSION[] arrayet.

Red: $_SESSION lagres på serveren med referanse til session_id() så brukeren kan ikke manipulere hva som står der. (Har sett enkelte oppfatte det som at $_SESSION lagres hos brukeren og ikke kan stoles på)

PS: jeg så noe interesant i beskrivelsen av session_name() på php.net. Det viser seg at dersom du bruker et session navn (kan defineres i php.ini) som bare består av tall, vil session_id regenereres automatisk for hver gang. Har ikke testet dette.

Problemet med å ha session_start() etter at scriptet har printet output (som det gjør når du har html før <?php) er at cookies må settes i headers. Headers sendes til klienten før output. Så dersom output er sendt, kan ikke flere headers sendes og ingen cookie kan settes.

Red: Du kan antageligvis sette session_start() hvor du vil dersom du tvinger PHP til å bruke $_GET. ini_set( 'session.use_cookies', '0' ); ini_set( 'session.use_only_cookies', '0' );

<?php

function dbEscape( $msg, $quote = '\'', $dbLink = null )
{
 if ( !is_numeric( $msg ) )
 {
if ( get_magic_quotes_gpc() ) $msg = stripslashes( $msg );
$msg = $quote . mysql_real_escape_string( $msg, $dbLink ) . $quote;

 }
 return $msg;

}

session_start();

$dbLink = mysql_connect( 'a', 'b', 'c' ) or die( mysql_error() );
mysql_select_db( 'd' ) or die( mysql_error() );

if ( isset( $_POST['submit_login'] ) )
{
 $postUser = dbEscape( $_POST['username'], '\'', $dbLink );
 $postPass = sha1( $_POST['password'] );

 $dbPassQry = "SELECT password_sha1 FROM users WHERE username = $postUser;";
 $dbPassRes = mysql_query( $dbPassQry ) or die( mysql_error() );
 $dbPassRow = mysql_fetch_row( $dbPassRes ) or die( mysql_error() );
 $dbPass = $dbPassRow[0];

 if ( !strcmp( $dbPass, $postPass ) )
 {
$_SESSION['auth'] = TRUE;
$_SESSION['user'] = $postUser;
 }
}

// så lenge $_SESSION['auth'] er TRUE er bruker logget inn.
// brukernavn kan sjekkes mot $_SESSION['user'];

?>

Endret 2. februar 2008 av grimjoey

South_Bridge · 2. februar 2008

takk skal du ha grimjoey!

på sider jeg vil beskytte, noe ala:

<?php

session_start();

if ( $auth = $_SESSION['Lars'] ) 
{
echo "Klarte vi det?";

}
else
{
echo "vi klarte det ikke";
}

?>

grimjoey · 2. februar 2008

heller

<?php

session_start();

if ( $_SESSION['auth'] )
{
 print "Bruker {$_SESSION['user']} har logget seg på!";
}

?>

South_Bridge · 2. februar 2008

og logout blir seende noe slik ut: (???)

<?php

$_SESSION['auth'] = false;

?>

BigJackW · 2. februar 2008

Nei.

session_destroy();

Crowly · 2. februar 2008

Fant denne logout rutine for en stund tilbake

if (isset($_SESSION['auth'])) unset($_SESSION['auth']);
 $_SESSION = array(); // Unset all of the session variables.

// If it's desired to kill the session, also delete the session cookie.
// Note: This will destroy the session, and not just the session data!
if (isset($_COOKIE[session_name()])) 
 setcookie(session_name(), '', time()-42000, '/');

// Finally, destroy the session.
session_destroy();

grimjoey · 2. februar 2008

Jeg ville gjort som du skriver south_bridge. $_SESSION['auth'] = FALSE eller unset( $_SESSION );

Ernie · 2. februar 2008

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

Hadde bare verden vært så enkel så. Problemet er at SSL ikke løser hele det problemet. Det hinderer helt klart uvedkommende å lese data mellom klient og server, men bare hvis dette skjer via SSL. Hva hvis angriper f.eks sitter på samme trådløse nettverk og får brukeren til å gå til den sikre siden uten bruk av SSL/TLS? Selv om domenet ikke har noen server som betjener port 80 vil du alikevel klare å lese f.eks cookie som er satt ... ;-)

Forøvrig, det å hindre session hijacking når man bruker session (som i det GET/cookie-baserte opplegget i PHP) er komplett umulig. Dvs. du kan til en viss grad forhindre at det skjer, men du oppnår aldri en bombesikker verifisering av brukeren. Spesielt gjelder det for servere du deler med andre. Blandt annet blir det å sette session_path til noe annet enn /tmp e.l i stor grad et naivt tiltak uten mål og mening, siden dette uannsett må være filer og mapper andre også vil kunne lese via PHP (eller helt korrekt webserveren).

I bunn og grunn oppnår man tilfredstillende sikkerhet ved å sette en varighet på session som er fornuftig i forhold til bruk og ved å lagre unna IP i session (ev. annet foretrukken metode) og sjekke dette for hver req.

Ja, også bør såklart ikke session være «web accessible», men det er ivaretatt allerede i utgangspunktet.

grimjoey · 2. februar 2008

Du får levere ut kodebrikker som gir brukeren engangspassord. Så kan du verifisere disse ved bruk av sensitive tjenester

Ernie · 2. februar 2008

Litt «irriterende» å måtte kreve ny kode for hver handling som skal utføres, men det er jo faktisk nesten den eneste måten å være helt sikker på.

Logg inn

Beskyttelse mot session hijacking...?

Anbefalte innlegg

j000rn

Lenke til kommentar

Videoannonse

ze5400

Lenke til kommentar

South_Bridge

Lenke til kommentar

grimjoey

Lenke til kommentar

South_Bridge

Lenke til kommentar

grimjoey

Lenke til kommentar

South_Bridge

Lenke til kommentar

grimjoey

Lenke til kommentar

South_Bridge

Lenke til kommentar

BigJackW

Lenke til kommentar

Crowly

Lenke til kommentar

grimjoey

Lenke til kommentar

Ernie

Lenke til kommentar

grimjoey

Lenke til kommentar

Ernie

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Opprett konto

Logg inn

Populær nå

Trump 2025 1 2 3 4 169

Hvem er aktive 0 medlemmer