Session Fixation

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Functioneel Applicatiebeheerder

Wij van CNB zijn op zoek naar een leergierige Functioneel Applicatiebeheerder CNB is de grootste dienstverlener in de markt van bloembollen en vaste planten. In deze markt verricht CNB de volgende diensten: bemiddeling, veilen en het koelen en prepareren van bloembollen. Vanuit ons hoofdkantoor in Lisse werken bijna 100 collega’s dag in dag uit aan de bemiddeling van bloembollen. In Bovenkarspel vindt het koelen en prepareren van de bloembollen plaats. Wij zijn op zoek naar een enthousiaste Functioneel Applicatiebeheerder die naast een applicatie, ook sfeer kan bouwen! Jij: Vindt het leuk om binnen een klein IT-team aan de slag te

Bekijk vacature »

Fullstack developer

Zie jij mogelijkheden om onze tooling technisch te verbeteren en uit te bouwen? Over Jobmatix Jobmatix is een innovatieve en internationale speler op het gebied van jobmarketing. Onze jobmarketing automation tool helpt organisaties bij het aantrekken van nieuw talent door vacatures digitaal, geautomatiseerd en op een efficiënte manier te adverteren en onder de aandacht te brengen bij de doelgroep op 25+ jobboards. Volledig performance-based, waarbij organisaties betalen op basis van cost per click of cost per applicant. Maandelijks wordt onze jobmarketing automation tool al gebruikt door vele directe werkgevers, intermediairs en mediabureaus, waaronder Picnic, Rijkswaterstaat, AdverOnline, Schiphol, DPA, Teleperformance en

Bekijk vacature »

Oracle APEX developer

Wat je gaat doen: Als Oracle APEX ontwikkelaar bij DPA werk je samen met collega’s aan de meest interessante opdrachten. Je zult je ervaring met SQL, PL/SQL, JavaScript, HTML en CSS inzetten om wensen van opdrachtgevers te vertalen naar technische oplossingen. Je werk is heel afwisselend, omdat DPA zich niet beperkt tot een specifieke branche. Zo ben je de ene keer bezig binnen de zorgsector, de andere keer is dit bij de overheid. Wat we vragen: Klinkt goed? Voor deze functie breng je het volgende mee: Je hebt een hbo- of universitaire opleiding afgerond Je hebt 2 tot 5 jaar

Bekijk vacature »

.NET Developer Azure

Dit ga je doen Het ontwerpen en bouwen van diverse applicaties (C#, ASP.NET, MVC); Het ontwikkelen van Webservices (WCF); Het meewerken aan de transitie naar Azure; Het samenwerken met collega's binnen een Scrumteam en meedenken over de User Stories; Het bouwen van unittesten; Meedenken over nieuwe tooling, ontwikkelingen en technologieën in de markt. Hier ga je werken Je komt te werken bij een organisatie die verantwoordelijk is voor de ontwikkeling van verschillende portalen. Deze portalen worden gebruikt door diverse partijen en jouw taak is om ervoor te zorgen dat deze optimaal functioneren. Je wordt onderdeel van een Scrumteam en werkt

Bekijk vacature »

Full Stack C#.NET developer

Functieomschrijving Wij zijn op zoek naar een gepassioneerde Full Stack C#.NET Software Developer. Als Software Developer ben je verantwoordelijk voor het ontwikkelen van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Je werkt samen met andere ontwikkelaars en engineers om de sensoren in machines uit te lezen en deze data om te zetten in management informatie voor jullie klanten. Taken en verantwoordelijkheden: Ontwikkelen en onderhouden van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Testen en valideren van de ontwikkelde software. Actief deelnemen aan code reviews en bijdragen aan het verbeteren van de kwaliteit van de software. Je gaat aan

Bekijk vacature »

Developer Full Stack

Functie omschrijving Developer gezocht! Ben jij een enthousiaste developer die graag wil bijdragen aan ontwikkelingen binnen een mooie organisatie? Solliciteer dan snel. Wij zijn op zoek naar een Full Stack Developer uit de regio Nijkerk die gaat bijdragen aan het door ontwikkelen, onderhouden en optimaliseren van een SaaS applicatie. Je moet beschikken over beheersing van zowel de Nederlandse als Engelse taal aangezien je samen met de klant gaat werken. Bedrijfsprofiel Je komt te werken binnen een echt familiebedrijf dat al sinds 1925 actief is binnen de FMCG branche. Het bedrijf heeft 40 medewerkers en er heerst een platte communicatiestructuur waarbij

Bekijk vacature »

Softwareontwikkelaar Cleopatra

Functieomschrijving Voor de gemeente Amsterdam zijn wij op zoek naar een softwareontwikkelaar Cleopatra. De directie Verkeer en Openbare ruimte van de gemeente Amsterdam beschikt over een softwareapplicatie, "Cleopatra", waarmee geautomatiseerde handhaving plaatsvindt (op basis van kentekenherkenning) van bepaalde gebieden waarin toegangseisen worden gesteld aan het verkeer. Voorbeelden ervan zijn de milieuzones, de zone zwaar verkeer, handhaving van brom- en snorfietser op het fietspad en autoluwe gebieden. Voor de doorontwikkeling en uitbreiding ervan zijn gespecialiseerde softwareontwikkelaars nodig die helpen bij het programmeren van de handhavingsmodules voor nieuwe gebieden en het verbeteren en bijwerken van de bestaande onderdelen van de softwareapplicatie. Functie

Bekijk vacature »

Teamlead PHP Developer

Functieomschrijving Voor een gewaardeerde werkgever in de buurt van Middelburg zijn wij op zoek naar een gemotiveerde teamlead PHP developer met affiniteit met Symfony/Laravel. Een enthousiast persoon die het ontwikkelteam komt versterken met het aanpakken van uitdagende projecten. Ben jij op zoek naar een uitdaging waar je de tijd en ruimte krijgt jezelf te ontwikkelen en je eigen IT-team aan te sturen? Lees dan snel verder! Die ga je doen: Bijdragen aan de implementatie van aanpassingen, verbeteringen en aanvullingen in de PHP based applicaties; Ontwikkeling en beheer van de serviceportal in Symfony en de webshops in de tweede versie van

Bekijk vacature »

Android developer

De functie Schiphol is een plek om te reizen, te verblijven en te werken. Door middel van data en technologie richten we op al deze gebieden het leef- en werkklimaat optimaal in en zorgen we voor een slimmere en efficiëntere operatie. Wij ontwikkelen nieuwe producten en diensten vanuit de wensen en behoeften van onze klanten, voorspellen passagier flows en testen digitale oplossingen om rijen en andere pijnpunten in het proces te verminderen. Met slimme feedback van sensortechnologie maken we zelfs data van toiletten en stoelen inzichtelijk en bruikbaar. Het Commercial Platform bestaat uit multidisciplinaire teams met een end-2-end verantwoordelijkheid voor

Bekijk vacature »

Ervaren C#.NET developer

Functieomschrijving We zijn op zoek naar een ervaren C#.NET programmeur voor een moderne werkgever in de regio Prinsenbeek. Als programmeur zal je bezig zijn met het ontwikkelen van op maat gemaakte webapplicaties voor verschillende klanten, waarbij je ervoor zorgt dat complexe processen zo goed mogelijk worden ondersteund. Je takenpakket omvat onder andere: Werken met databases en dataopslagoplossingen, implementeren van beveiligingsoplossingen en het waarborgen van de beveiliging van applicaties en gegevens, evenals het schrijven van technische documentatie en gebruikershandleidingen. Het ontwikkelen en onderhouden van C#.NET-applicaties. Bijdragen aan het ontwerp en de architectuur van softwaretoepassingen. Het schrijven van hoogwaardige en herbruikbare codes.

Bekijk vacature »

Senior Java Developer

Als Senior Java Developer bij Sogeti ben je onderdeel van onze toonaangevende community die bestaat uit ruim 100 gepassioneerde Java professionals. In teamverband lever je mooie prestaties. Daarmee draag je aan bij de meerwaarde die wij leveren aan onze top-opdrachtgevers. Geen werkdag is hetzelfde! Je bent voortdurend bezig met het oplossen van allerlei complexe vraagstukken binnen bedrijfs kritische systemen voor onze klanten in regio Noordoost zoals DUO, ING, CJIB en Tendernet. Natuurlijk krijg jij de mogelijkheid je verder te certificeren in dit vakgebied. We organiseren regelmatig technische Meetups en doen veel aan kennisdeling. Sogetisten hebben plezier in hun werk en

Bekijk vacature »

Front-end developer (Vue.js) gezocht!

Functie Als Front-end developer is het jouw doel om efficiënte en effectieve frontend code te ontwerpen, ontwikkelen en onderhouden die goed aansluit bij de functionele behoefte vanuit de klant. Je zorgt voor optimale SEO-resultaten, sitespeed en frontend security. You build it, you run it, you own it! Je maakt deel uit van een DevOps Scrum team en werkt samen met back-end developers, test-engineers, interaction designers en een projectmanager. Er zijn verschillende groepen Scrum teams. Een roadmap team is jouw ‘’thuisbasis’’, daar wordt gewerkt aan doorontwikkeling van bestaande omgevingen voor een aantal klanten. Hiernaast zijn er projectteams waar nieuwe omgevingen worden

Bekijk vacature »

Embedded Developer C++

Functie omschrijving Ben jij op zoek naar een leuke uitdaging als Embedded Developer, zoek dan niet verder! Voor een leuke opdrachtgever in omgeving Rotterdam zijn wij op zoek naar een Embedded Developer die graag met Embedded Devices werkt. Je zult verantwoordelijk worden voor het ontwikkelen en onderhouden van diverse producten. Jouw specialisatie ligt op het vlak van software, hardware en back-end. Dit bedrijf is gespecialiseerd in het ontwerpen van software voor een unieke industrie. Wil jij betrokken worden bij een proces dat loopt van ontwikkeling tot installatie? Waarbij je bezig zult zijn met perfecte systemen die geleverd worden aan binnen

Bekijk vacature »

Backend Developer Scrummaster .NET

Samengevat: Deze werkgever is een ambitieus internetbedrijf met een passie voor digitale communicatie. Ben jij geschikt als Backend Developer? Heb je ervaring met .NET platform? Vaste baan: Backend Developer / SCRUM Master Scrum HBO WO €3.800 - €6.000 Deze werkgever is een innovatief bedrijf met enthousiaste mensen die jarenlang ervaring hebben met het ontwikkelen internet- en intranetoplossingen. Wij houden van korte lijnen en open en eerlijke communicatie. Wij zetten graag onze jarenlange ervaring in om perfect werkende oplossingen te ontwikkelen. Wij ondersteunen dienstverlenende organisaties bij het ontwikkelen en realiseren van een effectief, adaptief communicatieplatform. Je ontwikkelt met ons de meest

Bekijk vacature »

Senior Product Developer

Functieomschrijving Als senior Product Developer ben je verantwoordelijk voor bestaande mobiliteitsproducten en de ontwikkeling van nieuwe mobiliteitsconcepten. Met behulp van diverse klantonderzoeken, klantsessies en salesmeetings zorg je ervoor dat je de veranderende mobiliteitsbehoeften in de markt kent. Hier speel je op in door innovatieve, flexibele, efficiënte en duurzame vervoersoplossingen te bedenken, te ontwikkelen, te implementeren en uiteindelijk samen met Sales en Marketing collega’s in de markt te zetten. Je initieert en neemt deel aan (internationale en afdeling overschrijdende) projecten, vaak in de rol van projectleider. In die rol bewaak je de voortgang, coördineer je de activiteiten en zorg je voor

Bekijk vacature »

Pagina: 1 2 volgende »

Bo az

Bo az

21/02/2008 13:56:00
Quote Anchor link
Gisteren kwam ik een presentatie tegen van Ilia Alshanetsky over beveiliging in PHP. Daar kwamen een aantal punten in voor die ik graag met jullie wil delen en benieuwd ben naar jullie mening/aanpak.

Punt 1: Session Fixation
Session fixation is een manier om een sessie te stelen waarbij de aanvaller vooraf weet welk session id het slachtoffer krijgt. (Dus niet zoals bij session hijacking waarbij het session id achteraf gestolen wordt.) Dit is toe te passen met bijvoorbeeld een link als:
jouw.bank.com/?PHPSESSID=foobar
Als het slachtoffer nu op de link klikt denkt de website dat het sessie id foobar is en gaat hier alle gegevens aan koppelen, de aanvaller kan nu simpelweg dat sessie id ook gebruiken.
De oplossing die hierbij gegeven wordt is door simpelweg na het inloggen een nieuw sessie id toe te wijzen waardoor de aanvaller geen kans meer heeft:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
<?php
session_start();
// some login code
if ($login_ok) { // user logging in
session_regenerate_id(); // make new session id
?>


Punt 2: Session Hijacking
Een veel toegepaste techniek om session hijacking (en ook helpt om session fixation) te voorkomen is een sessie koppelen aan een gebruiker. Maar hoe kan je nu een sessie aan een gebruiker koppelen? Een veelgebruikte manier daarvoor is om de sessie aan het IP adres van de gebruiker te koppelen, maar dit heeft een paar nadelen waaronder:
- Er kunnen meerdere mensen met het zelfde ip adres zijn (denk aan thuis- of sommige bedrijfsnetwerken).
- Een IP adres kan vaak wisselen.
- Een IP adres is te spoofen.
In de presentatie wordt ook een voorbeeld met een alternatief gegeven voor het koppelen van een sessie aan een ip adres, namelijk het koppelen aan de browser signature:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
<?php
session_start();
$chk = @md5(
$_SERVER['HTTP_ACCEPT_CHARSET'] .
$_SERVER['HTTP_ACCEPT_ENCODING'] .
$_SERVER['HTTP_ACCEPT_LANGUAGE'] .
$_SERVER['HTTP_USER_AGENT']);
if (empty($_SESSION))
$_SESSION['key'] = $chk;
else if ($_SESSION['key'] != $chk)
session_destroy();
?>

Ook dit is niet helemaal water dicht omdat het vaker voor kan komen en door de gebruiker aan te passen is. Maar misschien is het een idee om ook nog het IP adres in de md5-hash mee te nemen?

Ik hoop dat iemand hier wat aan heeft of misschien zelfs wel andere manieren heeft om deze problemen te voorkomen/beveiligen.
Gewijzigd op 01/01/1970 01:00:00 door Bo az
 
PHP hulp

PHP hulp

29/03/2024 14:55:20
 
- SanThe -

- SanThe -

21/02/2008 14:06:00
Quote Anchor link
Interessant.
Bedankt voor deze info.
 
Lode

Lode

21/02/2008 14:21:00
Quote Anchor link
Er zijn maar een paar $_SERVER vars die je kan vertrouwen.
Alle andere zijn gevoelig voor injecties.
Bijvoorbeeld:
$_SERVER['PHP_SELF'], $SERVER['HTTP_HOST'] en nog veel meer...

vermijd deze dan ook!
Dit geldt ook voor bijvoorbeeld de functie getimagesize();
eveneens een verleden van problemen en parst eigenlijk gehele images en is dus gevoelig voor eventuele code daarin...

Mijn tip:
Wat betreft vaste paden e.d. 'hard' code ze in constanten c.q const
$_SERVER['PHP_SELF'] vervangen door basename(__FILE__);

Wat je wel kan vertrouwen is $_SERVER['REMOTE_ADDR'].
Maar goed dat deed ik na alle elllende eigenlijk toch al niet meer...
En bovendien wil ik weten of het om een IPv4 of IPv6 gaat.

Mocht je dergelijke $_SERVER vars gebruiken valideer de inhoud en wees consequent!

Cross-Site-Request-Forgery
Cross-Site-Scripting
Header-Forgery

Maken allemaal gebruik van dergelijke ingangen als het kan...
Dus zoals ik al vaker heb gezegd vertouw NIKS, zelfs geen $_SERVER vars!
wat je kan moet hard coden en de rest op z'n mist valideren...

Wat betreft Session-Fixation
En dat geldt voor zoveel dingen. Commen-Pratice is gevoeligheid.
php functie setcookie(); werkt met http 1.0 headers.
Omdat miljoenen mensen IE, sessions, md5, sha1 gebruiken zijn dit ook de grootste hack doelwitten...

Dus ik heb daar al lang afstand van gedaan persoonlijk...

Tuurlijk is alles te hacken en/of matchen, maar als je het anders doet, kan je mensen wel op een heel ander 'onverwacht' spoor zetten....
Gewijzigd op 01/01/1970 01:00:00 door Lode
 
Lode

Lode

21/02/2008 14:31:00
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
<?php
$_SERVER
['HTTP_ACCEPT_CHARSET']
$_SERVER['HTTP_ACCEPT_ENCODING']
$_SERVER['HTTP_ACCEPT_LANGUAGE']
$_SERVER['HTTP_USER_AGENT']
?>


Als je daar een Hash van maakt heb je inderdaad een goede 'fingerprint' van een gebruiker...

Dan heb je nog dingen als proxies.
welke eventueel gebruik kunnen maken van:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
<?php
$_SERVER
['HTTP_X_FORWARDED_FOR']
$_SERVER['HTTP_X_FORWARDED']
$_SERVER['HTTP_VIA']
$_SERVER['HTTP_PROXY']
$_SERVER['HTTP_PRAGMA']
$_SERVER['HTTP_FROM']
$_SERVER['HTTP_FORWARDED_FOR']
$_SERVER['HTTP_FORWARDED']
?>

Niet altijd het geval, maar voorkomen is beter als genezen..

En zo is er nog een hele waslijst met mogelijke $_SERVER vars voor proxies. En een aantal vaste poorten welke vaak/standaard gebruikt worden.
Dit soort bezoekers hebben bij mij iig geen rechten op 'ingelogt' blijven e.d.

Daarnaast heb je een aantal database welke te koop zijn met proxy ip's...

Er zijn genoeg lekken in Apache/php/mySql/pgSql... En ik ken er een hoop gelukkig maar zullen er altijd blijven....
 
Lode

Lode

21/02/2008 14:39:00
Quote Anchor link
nog een stap verder.... (wordt een tutorial ^^)

hashes:

http://www.php.net/hash bied alternatieven voor de eerder genoemde 'standaard' md5 / sha1 encrypties.

Daarnaast kan je gebruik maken van zogenaamde salt en pepper's...
appending / prepending opvullingen...

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
<?php
$salt
     = rand(100, 999);
$pepper  = rand(100, 999);
/*
dit zijn dus altijd random getallen van iig 3 cijfers!
*/


$hash = hash('whirlpool', 'random_hash'); //whirlpool is echt te zwaar!!!
$hash = substr($hash, strlen($salt), strlen($hash) - strlen($pepper));
$hash = $salt.$hash.$pepper;
?>


En zo kan je nog veel verder gaan...

Dit is iig een voorbeeld van goede hash zonder md5 / sha1 en dus ook heel anders is...

EDIT:

omdat jij de lengte van de salt / pepper weet kan je de hash matchen als je die er weer afgehaald hebt...
Anders is het gokken tot en met....
Gewijzigd op 01/01/1970 01:00:00 door Lode
 
- SanThe -

- SanThe -

21/02/2008 14:40:00
Quote Anchor link
Niet Bumpen.
Bumpen::
Twee of meer keer achter elkaar in een topic posten heet bumpen. Bumpen is pas na 24 uur toegestaan en kan een reden zijn voor de admins en moderators om een topic te sluiten. Gebruik indien nodig de Afbeelding knop om je tekst aan te passen.

SanThe.
 
Lode

Lode

21/02/2008 14:44:00
Quote Anchor link
Ik probeer (eindelijk) een beetje serieus te converseren over php... Ben een chaoot, dus sorry van mijn kant...
"Bumpen" klinkt nogal TMF, maar was iig niet de bedoeling...
 
Bo az

Bo az

21/02/2008 14:45:00
Quote Anchor link
Laten we het ook een klein beetje bij de eerder door mij genoemde punten blijven, anders kan ik ook nog wel een aantal andere voorbeelden uit de presentatie gaan geven waar veel mensen vast nog nooit over na gedacht hebben... (tenzij daar vraag naar is natuurlijk)
 
Lode

Lode

21/02/2008 14:59:00
Quote Anchor link
Oke...

Session-Fixation en de 'finger-printing' methode die je noemt zijn inderdaad erg nuttig!

Maar het gaat nog veel verder... Sorry dat ik daarop doordraai....
 
Mark Pieper

Mark Pieper

07/03/2008 16:25:00
Quote Anchor link
Ook bedankt voor de informatie, ik zal dit proberen te verwerken in mijn laatste script. Voor die fingerprint gebruikte ik alleen het ip-adres en de browser-agent, maar dit kan ik nu aanpassen.
 
Rick

Rick

07/03/2008 17:02:00
Quote Anchor link
Lode schreef op 21.02.2008 14:59:
Oke...

Session-Fixation en de 'finger-printing' methode die je noemt zijn inderdaad erg nuttig!

Maar het gaat nog veel verder... Sorry dat ik daarop doordraai....


Nou, niet echt :P Ik vind het wel interessant om wat meer diepgang te lezen over beveiliging in php, dus van mij mag je nog wel doordraaien ;)
 
Robert Deiman

Robert Deiman

07/03/2008 17:24:00
Quote Anchor link
Ik vind het wel interessant ja, dit wist ik nog niet.. Maar hoe ik daar mee om ga:

Er wordt niet Alleen op sessie-id gecontroleerd. Inderdaad gebruik ik de browser signature al in m'n login. Daarnaast wordt in de sessie het userid opgeslagen, samen met een unieke hash (combinatie van een paar dingen met de microtijd)

In de database sla ik die unieke hash op, samen met het userid, de browsergegevens en het ip-adres. Neemt iemand met een ander ip de sessie over, dan wordt dat geblokkeerd, wordt er met een andere browser (de signature hiervan) gekeken, dan wordt dat ook geblokkeerd. Daarnaast, pas je het ID aan dan wordt ook dat geblokkeerd.

In principe is het systeem dus voor beide hacking methoden wel goed beveiligd.


Wel bedankt voor het delen van de informatie
 
Patrick Niezen

Patrick Niezen

07/03/2008 18:04:00
Quote Anchor link
Interessant topic, bedankt voor de info inderdaad! Ik zal het van het weekend nog eens goed doorlezen :-)
 
Gebruiker PHP

Gebruiker PHP

09/03/2008 20:24:00
Quote Anchor link
Als een gebruiker bij mij inlogd krijg hij/zij te maken met de volgende zaken:
Anti-bruteforce, na 3 foutieve inlogpogingen word de toegang voor 15 minuten geblokkeerd. Hij/zij kan daarna pas weer een inlogpoging doen. Stopt de gebruiker na 2 foutieve inlogpogingen dan blijven deze 15 minuten staan.

Als het inloggen lukt dan wordt er een 50 tekens lange random code gegenereerd. Als de bezoeker gekozen heeft voor een cookie dan wordt deze direct geplaatst. Heeft de bezoeker gekozen voor een sessie dan wordt het sessie-id opnieuw gegenereerd en wordt de sessie geplaatst. De cookie/sessie wordt aan het IP, de host en de useragent gekoppeld om hijacking te voorkomen. Kort gezegd wordt er dus een gelockte cookie/sessie geplaatst welke geen gevoelige gebruikers-info bevat.

Alle wachtwoorden worden gehashed met een instelbaar algoritme, ikzelf heb sha512. Ik gebruik een salt welke minimaal 6 tekens lang is.
 
Jelmer -

Jelmer -

09/03/2008 20:57:00
Quote Anchor link
Het klinkt alsof SESSION-fixation puur gebaseerd is op PHPSESSID in de REQUEST-array. Als je die kan negeren, ben je er dan niet gewoon vanaf? (m.a.w. alleen PHPSESSID in cookies toelaten, niet GET of POST)

SESSION-hjiacking kan je van buiten het netwerk voorkomen door inderdaad die fingerprint in combinatie met het ip-adres. Die laatste is lastig te vervalsen volgens mij. Vertrouw niet op X_FORWARDED of varianten, want juist die zijn heel gemakkelijk te vervalsen. Als je daarop checkt, controleer dan ook nog op REMOTE_ADDR of die niet geblokkeerd is. Van die get_ip() functies die mensen schrijven om 1 van de opties te selecteren zijn dan ook eigenlijk meer een verslechtering dan een verbetering van de veiligheid.

Ik denk niet dat je session-hjiacking vanuit het netwerk kan tegengaan. De persoon die dan aan het hacken is is ook in de positie om al het verkeer op het netwerk af te luisteren (met bijvoorbeeld WireShark) en kan gemakkelijk achter de cookies, en alle andere headers komen. Daarnaast heeft hij voor de server van de website hetzelfde adres. Misschien dat een https-verbinding het wat moeilijker maakt, maar dan nog is hij de 'man in the middle' en kan hij ook daarvan de key achterhalen. Een verbinding zoals SSH met public/private key is dan misschien nog een veilige oplossing omdat daar de key niet over het netwerk wordt verzonden. Ik denk dat die verbindingen niet zomaar af te luisteren en/of te manipuleren zijn. Maar aangezien dat niet haalbaar is met simpel HTTP en normale gebruikers, denk ik niet dat het mogelijk is om dit soort hacken vanaf de server tegen te gaan.


Wat ikzelf eerder interessant vind is hoe ver wil je gaan? Als iemand iedere dag van ip-adres wisselt, dan is lang ingelogd blijven & controleren op IP niet mogelijk. Kies je dan voor de extra veiligheid van een ip-gebonden sessie, of voor het gebruiksvriendelijke 'ingelogd blijven' van de gebruiker. Voor betaal-sites en privacy-gevoelige sites is dit een makkelijke vraag, maar voor een forum zou ik persoonlijk kiezen voor de meest gebruiksvriendelijke oplossing.

ik bedenk me net: bij iedere request een nieuw 'id', een soort van request-token opslaan is ook een oplossing. Op die manier kunnen er niet 2 personen op 1 account tegelijk bezig zijn. Nadeel is echter - en dit is een groot nadeel - dat je geen 2 browsers meer kan openen. Zou je in browser a op een link klikken, dan is de cookie met de token in browser b niet meer geldig. Voordeel is dat wanneer iemand aan bladeren is, en een hacker neemt de sessie over, de hacker (en de gebruiker) direct uitgelogd zijn zodra de gebruiker weer op een link drukt (ervan uitgaande dat de hacker de laatste pagina heeft aangeroepen en de laatste token dus in z'n bezit heeft) want de token van de gebruiker is dan al ongeldig verklaard. Token ongeldig -> sessie ongeldig -> uitgelogd.
 
Bo az

Bo az

09/03/2008 21:12:00
Quote Anchor link
Jelmer:
Het klinkt alsof SESSION-fixation puur gebaseerd is op PHPSESSID in de REQUEST-array. Als je die kan negeren, ben je er dan niet gewoon vanaf? (m.a.w. alleen PHPSESSID in cookies toelaten, niet GET of POST)

Hoeft niet natuurlijk, als het mogelijk is om javascript te injecteren in een site kan je ook een cookie plaatsen om SESSION-fixation toe te passen (al is hier dus al een extra lek voor nodig).

Jelmer:
Wat ikzelf eerder interessant vind is hoe ver wil je gaan?

Dat is een interessante vraag die ook al vaker in andere toppics voor bij is gekomen zeker als het gaat om een sessie aan een IP te binden.
Met name om deze reden vond ik het dus een aardig idee om naar de browser signature te kijken zoals in mijn eerste toppic het 2e code voorbeeld. Hierdoor hou je toch nog een stukje veiligheid over zonder aan het IP te koppelen.
Gewijzigd op 01/01/1970 01:00:00 door Bo az
 
Gebruiker PHP

Gebruiker PHP

09/03/2008 21:23:00
Quote Anchor link
Bij mijn inlogsysteem kan maximaal 1 iemand per account ingelogd zijn, ook dit zie ik meer als een voor- dan nadeel.

Ik zou toch zo ver gaan om de sessie/cookie aan het IP te koppelen, 1x per dag opnieuw inloggen is immers een kleine moeite en zorgt toch voor een relatief groot beveiligingsverschil.
 
TJVB tvb

TJVB tvb

09/03/2008 21:39:00
Quote Anchor link
1* per dag inloggen is niet erg. Maar als je op een school zit met meerdere accespoints die geregeld uitvallen en extern ook meerdere ip adressen hebben is het minder fijn.
Het gaat er dus echt wel om wat wel en niet nodig is.
 
Jelmer -

Jelmer -

09/03/2008 21:43:00
Quote Anchor link
Ivo van B. schreef op 09.03.2008 21:23:
Bij mijn inlogsysteem kan maximaal 1 iemand per account ingelogd zijn


Hoe controleer je of je met 1 of meerdere personen op 1 account te maken hebt? M.a.w. wat scheidt de personen van elkaar?

Boaz schreef op 09.03.2008 21:12:
Dat is een interessante vraag die ook al vaker in andere toppics voor bij is gekomen zeker als het gaat om een sessie aan een IP te binden.
Met name om deze reden vond ik het dus een aardig idee om naar de browser signature te kijken zoals in mijn eerste toppic het 2e code voorbeeld. Hierdoor hou je toch nog een stukje veiligheid over zonder aan het IP te koppelen.


Eigenlijk zou iemand eens moeten testen welke headers er allemaal verzonden worden, welke eigenschappen hoe uniek zijn. Volgens mij valt dit toch tegen, al is het wel effectief wanneer iemand het niet verwacht (amerikaanse hacker die nederlander probeert te hacken weet niet waarom het mislukt)
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
 
Gebruiker PHP

Gebruiker PHP

09/03/2008 21:58:00
Quote Anchor link
@ Jelmer
Elke keer als er eimand inglogd worden de huidige inloggegevens overschreven.
 
Jelmer -

Jelmer -

09/03/2008 22:28:00
Quote Anchor link
Maar daar voorkom je SESSION-hjiacking nog niet mee. Je weet nooit zeker hoeveel mensen er van die ene sessie gebruik maken.
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.