Sessies en de veiligheid ervan

[alienfruit]

Ik heb een webapplicatie gemaakt in PHP versie 5 waarbij de gebruiker een serie formulieren moet invullen die vervolgens worden opgeslagen. Op het moment dat de gebruiker de webapplicatie start wordt er een sessie aangemaakt die wat gebruikers specifieke informatie opslaat zoals klant code e.d.

Nu moet de gebruiker een hele serie formulieren invullen met persoonlijke informatie deze informatie wordt tijdelijk in de sessie opgeslagen totdat de gebruiker de formulier correct heeft ingevuld. De voornaamste redenen hiervoor is dat ik niet onnodig de database wilde aanspreken bij conditionele vragen. Omdat zowel de webapplicatie als de server binnenkort wordt gecontrolleerd door de IT afdeling van de klant wordt gecheckt op veiligheid, vroeg ik me af of dit misschien nog een probleem kon zijn. De site draait zelf al wel in/met een Premium SSL certificaat. Wat qua veiligheid waarschijnlijk ook wel zou moeten helpen

Verder worden de sessie bestanden voor elke klant in een aparte encrypted disk file opgeslagen (bcrypt) en verder wordt er nog een poging tot IP blocking gedaan. Alleen IP adressen die opgegeven zijn door klant kunnen de webapplicatie benaderen.

[ Voor 9% gewijzigd door alienfruit op 23-12-2005 16:36 ]

[Grijze Vos]

Als je een sessie aan een IP koppelt wordt het al betrekkelijk lastig om die sessie te hijacken. Zeker als dat allemaal over een SSL tunnel gaat.

[JHS]

De vraag is of de gebruiker de data in de sessie kan krijgen, of dat je alleen op de server toegang hebt tot de data, met behulp van de sessiecode of iets dergelijks. Dat je de data later teruggeeft maakt verder niet uit... Want dan zie ik niet waarom sessies onveilig zouden zijn. Als je alles opslaat in de database en dan teruggeeft lijkt me net zo onveilig...

edit:

Oh, wacht, hijacking. Tja, met ip-koppeling wordt het al moeilijker, maar koppelen aan domein gegevens is natuurlijk nog een stuk veiliger, alleen ligt het volledig aan de omgeving (intranet) of dat aanwezig is... Alleen geld dat nog steeds net zo hard voor databasetoegang via een applicatie, waarbij je lijkt me ook met sessies zal werken...

[ Voor 34% gewijzigd door JHS op 23-12-2005 16:49 ]

[alienfruit]

De gegevens kunnen dmv. een key en een wachtwoord door de gebruiker worden ingezien om de status van de reportage te controleren. Maar dat dmv. een simpele challenge-response login systeem. Het wachtwoord (plus mijn geboortedatum als salt ) als een SHA-1 hash opgeslagen in de database. De sessie gegevens worden eigenlijk alleen gebruikt om te kijken of vraag y moet worden weergegeven als vraag x antwoord z heeft. Verder wordt het ip adres opgeslagen in de sessie en bij elke post gecontrolleerd of het nog hetzelfde is en dat het in het lijstje met toegestane ip adressen staat. Dit is volgens mij wel dubbel op omdat dit ook al gebeurd door de SSL encryptie/verbinding.

De gebruiker heeft wel de data omdat als hij een vraag verkeerd heeft ingevuld de overige antwoorden opnieuw worden ingevuld. Tijdens het creeëren van de sessie wordt er een simpele hash gemaakt dmv. sha1( time() . SALT_AND_PEPPER . '-' . CLIENT_CODE_HASH ); die geld als de unieke code voor de reportage vervolgens krijgt de gebruiker de eerste 9 karakters als zijn code. Op deze manier krijg ik een behoorlijk unieke code terug, tot heden nog geen dubbele gekregen.

[ Voor 32% gewijzigd door alienfruit op 23-12-2005 16:59 ]

[Woy]

alienfruit schreef op vrijdag 23 december 2005 @ 16:51:
Het wachtwoord (plus mijn geboortedatum als salt ) als een SHA-1 hash opgeslagen in de database.

Het is denk verstandiger om voor elke gebruiker een aparte salt te nemen en deze bij het wachtwoord in de database op te slaan. Als je namenlijk altijd dezelfde salt gebruikt kun je nog steeds zien of mensen dezelfde wachtwoorden hebben als je de hash kunt bekijken. Eventueel zou je in je code een vaste salt erbij kunnen doen plus de salt die in de database staat.

[alienfruit]

Hmm, lijkt mij een goed idee :-)

[Verwijderd]

Ik komt op mij een beetje over dat het veilig moet zijn en er dús maar wat veiligheidsmaatregelen zijn genomen.

Premium SSL certificaten, IP blocking, encrypted files, password salten. Allemaal nuttige technieken maar het komt op mij over dat de TS eigenlijk het verband tussen de veiligheidsmaatregelen niet ziet.

Bij beveiliging begin je met een risico analyse en bepaal je waar je je tegen wilt beveiligen. Daarna kies je een set van methodes die op elkaar aansluiten. Hier lijkt het alsof de TS zonder duidelijke doelen aan het beveiligen is geslagen en simpelweg alles waar hij van gehoord heeft is gaan gebruiken zonder daarbij echt na te denken over het hoe en waarom van die technieken.

En dat is (IMHO) bijna net zo erg als geen beveiliging. Ik denk (en dat blijkt eigenlijk ook wel uit dit topic) dat de TS niet weet hoe hij zijn keuzes naar het auditing team moet gaan verdedigen. Met een duidelijk beveiligingsplan is het én voor het controlerende team makkelijker om te zien wat er wel en niet gedaan is én voor de TS eenvoudig om de keuzes te motiveren. Dan kan er altijd iets over het hoofd gezien zijn, maar de controlerende partij kan dat zélf dan (hopelijk) snel zien en aanvullende eisen stellen.

Als het de klant echter niet duidelijk wordt welke aspecten zijn afgedekt, kan die echter maar op twee manieren reageren.
- Op hoop van zege de applicatie in gebruik nemen.
- De applicatie afwijzen.

Dus ongeacht de mate van beveiliging zou ik op basis van wat ik hier lees al met een onprettig gevoel het gesprek ingaan. Of ik nu zou moeten controleren of gecontroleerd wordt.

$0.02

[alienfruit]

Het project is jammerlijk genoeg niet op zo'n manier verlopen dat er vooraf een risico analyse gemaakt is, eerder was er aan het begin niet eens bekend dat het aan zulke strenge eisen moest worden voldaan. Het was eerst een proof of concept wat nu commercieel wordt uitgebuit. Ik houd er bij een proof of concept niet rekening mee dat er mogelijk in de toekomst moet worden voldaan aan eisen die wereldwijd worden gesteld aan zulke systemen. Verder was ik niet bekend met het bestaan van zulke eisen toen het proof of concept werd gemaakt. Het team uit Amerika was erg content met de beveiliging bij de data centre in Amsterdam, nu moet alleen de applicatie nog worden gecontroleert dmv. een black box, en Crystal box methode.

[ Voor 46% gewijzigd door alienfruit op 27-12-2005 00:35 ]