Is session niet gewoon het zelfde als post? Je kan het niet zien, maar volgensmij is het mogelijk om aan te passen.

Tadaa: KLIKSKE

Oftewel, sessie staat serverside, zodra je de user-input in de sessie zet controleer deze dan eerst goed, sessie ID zouden ze kunnen doorgeven via een cookie, maar je bent niet al te slim als je dat doet.

Daarin staat exact wat ik al zei.
Ik ben heus wel bekend met sessions, en weet dat ze serverside staan, ik ben alleen bezig met een app waarbij ik niet wil dat er geknoeid kan worden met de inhoud van een sessie die ik ze geef.

Standaard zijn sessions veilig.
Hetzelfde als standaard een database veilig is.

Maar ga je gebruikersinput toevoegen aan je sessie of je database dan controleer je die op "evil" input, anders zouden er wel eens dingen kunnen lopen zoals je niet wilt.

Dan zal ik gewoon voor HTTPS gaan:) Als het echt heel erg gevoelige data is dan leg je dit niet vast in een sessie lijkt mij.

Die https komt er idd ook, maar dat is toch meer voor dat je op een veilige lijn zit (kan niet sniffen bv) maar het "probleem" blijft toch hetzelfde? (als er al een probleem is natuurlijk)

De sessions krijgen door mij een inhoud toegewezen, ik zie "voorlopig" niet hoe hun zelf die waarde kunnen aanpassen, dat is mijn enige probleempje.
Ik ging er al vanuit dat het veilig was, maar had ooit ergens een gelezen (geen idee meer waar) dat sessions te manipuleren waren, dit wil ik dus uitsluiten.

Als je iets in de aard doet van:
$_SESSION['username'] = $_POST['username']

En ergens echo $_SESSION['username']; dan zie je de bui al hangen natuurlijk.

Maar natuurlijk kan dat geen andere session variabele verranderen.

:P
Nee, de session krijgt een inhoud uit mijn database, die ik daar zelf inzet.
Het wordt gewoon een soort wachtwoord.

Mijn ding is: stel dat iemand random die wachtwoorden kan uitproberen, dan krijgt die mss informatie of rechten die helemaal niet bij hem horen.
De sessions ken ik toe als er is ingelogged met het juiste emailadres en wachtwoord (niet "dat" wachtwoord)

php code - Bekijk de code zonder highlighting - Klap code in

<?php
session_start();
ini_set('session.save_path', '/pad/buiten/htdocs/');
//dit verwijs je in ieder geval naar een directorie waar niemand bij kan.
ini_set('session.name', 'hash'); # try to hide the session name..
//hiermee geef je aan of de naam van de sessie encrypted moet zijn of niet.
if (!isset($_SESSION['ip']))
  $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR'];
  trigger_error("Session Capture detected!", E_USER_WARNING);
?> 

<?php
session_start();
ini_set('session.save_path', '/pad/buiten/htdocs/');
//dit verwijs je in ieder geval naar een directorie waar niemand bij kan.
ini_set('session.name', 'hash'); # try to hide the session name..
//hiermee geef je aan of de naam van de sessie encrypted moet zijn of niet.
if (!isset($_SESSION['ip']))
  $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR'];
  trigger_error("Session Capture detected!", E_USER_WARNING);
?>

 

$_SERVER['REMOTE_ADDR'] is het echte IP adres! Zodra deze anders is als $_SESSION['ip'].
Dan weet je in ieder geval zeker dat de sessie gefaked is.
Dus wat je moet doen... is een sessie bijhouden waar het IP adres van de ingelogde gebruiker in staat.

Door deze code voorkom je gegarandeerd dat sessies te faken zijn:)

Sessies worden op de server opgeslagen en zijn dus niet aanpasbaar voor iemand die geen toegang heeft tot de server. 

@Koen,

Een sessie is ook niet te bewerken.
Maar hij is wel te hijacken.
En mijn bovenstaande oplossing voorkomt dit.