Zelf was ik er altijd van overtuigd dat session variables "safe" waren.
Met safe bedoel ik dat de waarde van een session niet overschreven kan worden zonder een serverside language.
Ik weet wel dat als iemand je sessionID te pakken krijgt (hoe maakt ff niet uit), hij je session kan overnemen, maar dat is hier niet van belang.
Ik wil gewoon weten of je de waarde van een sessie kan aanpassen.
Natuurlijk probeerde ik webdevtoolabr, maar daarin stond alleen het sessionID wat ik kon aanpassen, er stond niets van de overige gestarte sessions.
Als dus eea WEL te doen is door clienteel, kan je dan zeggen hoe, zodat ik het zelf kan testen/beveiligen?
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.
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.
: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
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:)
Op mn localhost (wamp) lukt dit iig niet, ik kan local de ini natuurlijk zelf aanpassen, maar dat kan ik niet op de host.
wat die 'hash' precies doet is me niet helemaal duidelijk, ik zie gewoon een nummer bij het de value van het sessionid.
Ik weet dus niet of het op een "echte" host dus wel gaat werken, maar ik neem aan van wel
Verder denk ik dat gewoon die ipcheck al voldoende is om hijacking tegen te gaan.
Oke dat tuurlijk.
Maar de reden dat ik altijd me save_path buiten me htdocs zet is omdat.
Stel dat er 1 authenticated user is met kwaadaardige bedoelingen. Deze heeft dan in ieder geval het recht om de sessie directorie te lezen als deze binnen de htdocs is gedefinieerd.(is meer als voldoende om schade aan te richten).
Plaats je deze buiten je HTDocs dan weet je in ieder geval 100% zeker dat deze niet zomaar gelezen/bewerkt wordt.
en zoals jij al zegt werk jij op WAMP(=windows) maar '/pad/buiten/htdocs/' is een unix based path. vandaar het conflict waarschijnlijk.
jij zou iets van C:/xamp/sessions/ kunnen gebruiken als session path.
Verder is vaak inderdaad een IP check wel voldoende om sessies te checken.
Ik gebruik dat ini_set enkel en alleen maar zodat ik alle opties per website(in mijn cms) kan aanpassen:)
Sommige websites willen bijvoorbeeld sessies zelf bijhouden in de database bijvoorbeeld.
en kreeg daar het exacte pad te zien, ik heb dezelfde file toen even op mn host gezet, en daar kwam er helemaal niets te staan.
Dus dat zal denk ik wel (be)veilig(t) zijn
Zit een beetje te brainstormen, maar volgens mij is alleen een ipcheck niet 100% veilig?
Want "stel" dat je van iemand het sessionID weet, dan hoef je alleen zelf een keer in te loggen zodat die ip-session geset wordt en daarna handmatig het sessionID aan te passen via webdevtoolbar....toch?
SessionID van een sessie via webdevtoolbar aanpassen kan niet
Dit geld alleen voor cookies een cookie is ook gewoon een sessie maar dan client side.
Dit verklaart de SESSIONID in de webdevtoolbar
Zend-Auth zou inderdaad een superieure oplossing zijn!
Alleen is dit voor vinTage niet echt relevant.
Aangezien hij volgens mij verder geen Zend Framework gebruikt in deze code.
Bovendien is Zend-Auth groot en vrij complex. En zal vinTage meer werk opleveren dan nodig is op dit moment.
Maar je inzet wordt vast en zeker zeer gewaardeerd... in ieder geval door mij
SessionID van een sessie via webdevtoolbar aanpassen kan nietÂ
Maar ik kan dat wel aanpassen naar het id van iemand anders en dan ben ik nog "binnen", hetzelfde als je met het id in de url zou prutsen
Mondje vol die zend_auth dingens, daar ben ik wel even zoet mee
edit, ik maak idd geen gebruik van zend of eender welk php framework.
Aangezien ik wel een redlijk groot project maak had ik me beter wel kunnen verdiepen, maarja, das voor V2
Maar server side kan dit niet.
En bovendien niemand kan zomaar de SESSIEID opvragen van een sessie op de server.
Daarom is je session save_path zo belangrijk:)
Stel, gebruiker A logt in. Zijn ip wordt opgeslagen in een sessie om hijacken te voorkomen.
Gebruiker B wil de sessie hijacken. Hij komt achter het sessie ID van A, en stelt deze in als zijn sessie ID. De waarde van $_SESSION['ip'] zal dus het IP zijn van gebruiker A, welke ongelijk is aan het IP van gebruiker B.
Als gebruiker B al was ingelogd, heeft zijn $_SESSION['ip'] de waarde van zijn eigen IP, ja, maar als hij dan de sessie van gebruiker A hijacked, krijgt hij ook $_SESSION['ip'] van gebruiker A, welke dan anders is.
Dus nee, als de hijacker zelf inlogt, lukt het trucje ook niet
1) Het is ingelogd, niet ingelogged, dat is een misbaksel van het engels
2) Hoe laat je van die color-coding zien op je site? (Ik heb binnenkort ook zoiets nodig)
3) Wat zie ik daar? Ik zie alleen wat de sessionID is, en wat m'n naam en ip is. Maar wat zie ik verder? Hoe laat je hier mee zien dat je niet kan hijacken? (Of is dat niet je bedoeling?)
1) wtf @ engels, het is maar een testscriptje.
2) zie de code ? (laatste regel)
3) als je nou op computer 1 daarheen gaat en geeft daar een naam in en ramt op go.
Met computer 2 ga je ook daarheen en session id die boven in beeld staat bij computer 1 zet je in computer 2 middels de webdevtoolbar als value voor het SESSIONID cookie, refrech de page op comp2 en check de dump onderin, je hebt daar de sessionnaam van computer 1.
Voordat er geroepen gaat worden, ik heb het met 2 verschillende computers gechecked die alletwee een ander ip hadden
En om het nog harder te bewijzen, log in met een naam, onthoud de naam en plaats hier het sessionid, als de session nog bestaat ten tijde dat ik het hier check, dan zeg ik welke naam je in hebt gevoerd daar.
Een sessie is een bestand op de server, met als naam een hash van tijd en ip adres (ofzo). Dezelfde hash staat op de computer van de gebruiker in een cookie. Die zou in principe kunnen aanpassen, maar dan moet je de hash van een andere sessie weten. Dit kan je in ieder geval voorkomen door alle gebruikerinput te checken en escapen etc.
REMOTE_ADDR is voor zover ik weet te vervalsen (kheb even wat gegoogled), dus dit is niet echt de beste manier om het te beveiligen.
Een echt volledig veilige sessie maken is voor zover ik weet onmogelijk, maar als je de userinput goed controleert is er een gigantisch kleine kans dat iemand het nog hackt.
dr komt helemaal geen userinput in.
En je hebt zeker niet het voorgaande scriptje getest ? Ik neem daar zo je session over (mits ik het session_id weet natuurlijk en dat is niet zomaar te achterhalen).
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
