[PHP] Security ontwerp

[MLM]

Voor een systeem (dat nog in ontwerp is) dat moet gaan draaien op Apache, PHP & MySQL, wil ik user-authentication gebruiken. Nu zat ik me af te vragen in hoeverre het mogelijk is om ZONDER SSL een waterdicht systeem te bouwen (of in elk geval zo dichtbij mogelijk)

Punten waar ik al aan gedacht had:
- username/password niet plaintext verzenden, bijvoorbeeld door clientside SHA1 + salt te gebruiken (met JavaScript bijvoorbeeld)
- wanneer iemand inlogt een session aanmaken en daar rechten enz. in opslaan
- de gegevens in de session gebruiken om de user wel/niet toe te laten

Onoplosbare Problemen:
- het is mogelijk om de session te hijacken, moeilijker te maken door bijvoorbeeld de session aan een IP te verbinden (maar een IP kan je ook spoofen afaik)

Klopt het dat dit probleem (nogmaals: zonder SSL) onoplosbaar is?

[BasieP]

ik denk dat je het probleem een beetje de verkeerde kant op brengt
als jij een site maakt die gebruik maakt van sessies en client side encrypted dataverzending, dan is het wat jouw betreft klaar.
als de client vervolgens slordig is met hun eigen beveiliging, en zijn session laat hijacken dan is dit niet echt iets waar jij je druk over hoeft te maken denk ik

[TheRebell]

Mbt het onoplosbare probleem; je zit dan nog met pc's die achter NAT zitten... Die hebben hetzelfde ip adres wat je nu (misschien) vast gaat leggen. Iemand anders kan dus niet vanaf datzelfde ip adres op het systeem inloggen/komen.
Je hebt ook nog van die handige mensen die hun browser gewoon sluiten en waarvan het systeem dus niet weet of die persoon nog actief is of niet....

als de client vervolgens slordig is met hun eigen beveiliging, en zijn session laat hijacken dan is dit niet echt iets waar jij je druk over hoeft te maken denk ik

ik denk dat hij graag zou willen weten hoe je het eea hiervan zou kunnen voorkomen. Ik denk niet dat iemand zijn sessie zal 'laten hijacken', dus zich hier bewust van is. Hoe kun je dit voorkomen is denk ik de bedoeling..

hey, uni collega hoeveelste jaars ben je?

[ Voor 32% gewijzigd door TheRebell op 24-12-2005 22:15 ]

[TheBorg]

TheRebell schreef op zaterdag 24 december 2005 @ 22:12:
Mbt het onoplosbare probleem; je zit dan nog met pc's die achter NAT zitten... Die hebben hetzelfde ip adres wat je nu (misschien) vast gaat leggen. Iemand anders kan dus niet vanaf datzelfde ip adres op het systeem inloggen/komen.

Ik zit ook achter NAT en gebruik praktisch hetzelfde systeem, ik heb er nog nooit problemen mee gehad.

[MLM]

Ik denk dat het niet handig is om maar 1 session per IP toe te laten (NAT-probleem oa), maar ik dacht om per sessie het IP op te slaan. mocht er dan een request komen van een ander IP, maar wel met het goeie session-id kan je alsnog die persoon weigeren. Dat voorkomt ook "domme" mensen die een link met sessionID op een forum posten, zodat iedereen zijn account kan gebruiken

Maar een session-hijack kan je in principe dus niet "voorkomen"?

@TU/er: 2e

[ Voor 3% gewijzigd door MLM op 24-12-2005 23:43 ]

[TheRebell]

TheBorg schreef op zaterdag 24 december 2005 @ 22:32:
Ik zit ook achter NAT en gebruik praktisch hetzelfde systeem, ik heb er nog nooit problemen mee gehad.

Als je achter NAT zit met meerdere mensen en je slaat het ip adres op, dan heb je potentieel (er even vanuit gaande dat er meerdere gebruikers zitten) dat je hetzelfde ip adres meerdere keren hebt. Oke je onthoudt niet alleen het ip adres maar ook bv wat login gegevens, maar dan heb je potentieel toch een gat

Ik gebruik nu ook een combinatie met oa het ip van de gebruiker en een versleutelde login, hiernaast hou ik het sessie_id ook bij en (oa) de gebruikersnaam. Het wordt al lastiger om vanaf een andere plek van hetzelfde systeem gebruik te kunnen maken. Hiernaast zit er ook iets in dat voorkomt dat iemand (een domme gebruiker ) zo'n browser niet goed afsluit en iemand na hem dezelfde browser nog zou kunnen gebruiken en in het systeem kan komen.

Heeft de TS ook al nagedacht over alles _na_ het inloggen? Hoe ga je dat doen met beveiliging als iemand bv het pad naar een belangrijke pagina weet en direct intikt?

[MLM]

TheRebell schreef op zondag 25 december 2005 @ 00:03:
[...]

Als je achter NAT zit met meerdere mensen en je slaat het ip adres op, dan heb je potentieel (er even vanuit gaande dat er meerdere gebruikers zitten) dat je hetzelfde ip adres meerdere keren hebt. Oke je onthoudt niet alleen het ip adres maar ook bv wat login gegevens, maar dan heb je potentieel toch een gat

Je hebt gelijk, maar ik zie geen manier om dat op te lossen, immers als NATted persoon 1 een session heeft lopen, kan NATted persoon 2 gewoon zijn session "hijacken", je kan als server gewoon het verschil tussen die 2 mensen niet meer zien. Of heb jij hier wel een goede oplossing voor?

(je kan 1 sessie per IP toestaan, maar dan kunnen dus nooit 2 mensen NATted tegelijk gebruik maken van je systeem... moeilijke afweging)

[TheBorg]

-edit-
Laat maar zitten, lezen is ook een vak.

[ Voor 78% gewijzigd door TheBorg op 25-12-2005 00:30 ]

[TheRebell]

MLM schreef op zondag 25 december 2005 @ 00:20:
Je hebt gelijk, maar ik zie geen manier om dat op te lossen, immers als NATted persoon 1 een session heeft lopen, kan NATted persoon 2 gewoon zijn session "hijacken", je kan als server gewoon het verschil tussen die 2 mensen niet meer zien. Of heb jij hier wel een goede oplossing voor?

(je kan 1 sessie per IP toestaan, maar dan kunnen dus nooit 2 mensen NATted tegelijk gebruik maken van je systeem... moeilijke afweging)

naast 1 ip voor meerdere NAT poppetjes kun je natuurlijk nog meer gegevens in dezelfde/andere sessie opnemen. Op die manier kun je het eea wel uniek maken denk ik. Natuurlijk geen logingegevens opslaan maar iets van het gebruikers nummer of zijn naam.
Je hebt dan evt hetzelfde sessie id maar wel verschillende namen/id's

[Priet]

Je kan je sessies/cookies wel zo inrichten dat er meerdere mensen achter één NAT tegelijk in kunnen logggen op dezelfde website. Maak daarvoor gebruik van koppeling met IP + een willekeurige tekenreeks (validatie) + gebruikers ID. (validatie en/of ID).

Maar hiermee voorkom je niet dat mensen de cookie handmatig wijzigen en het ID wijzigen in een ander ID dat met dat IP al was ingelogd...

[markvt]

Waarom zou je links hebben met het sessieid eraan vast ? kan je dat niet anders uitlezen ?

[Hans1990]

Als ik een inlog systeem moet maken wat een beetje veilig is maak ik altijd een random string (hash, gewoon md5(microtime()) :-)) aan. Die random string zet ik in de sessie of cookie. In de database zet ik ook die random string in een aparte tabel session . Die tabel session bevat ook nog userID, IP etc. En wanneer je systeem checkt of de gebruiker ingelogd is check je gewoon of er een record is met de bezoekers IP & hash code. Zoja, zet je in diezelfde query nog een JOIN naar user tabel .

Zo doe ik het altijd en heb het op diverse sites gedaan en nog nooit iemand echt door heen gekomen (in de zin van: wel geprobeerd, niet gelukt ). Het voordeel is natuurlijk dat een sessie IP gelocked is en die unieke string in de sessie (of cookie) staat. Wanneer de cookie word gejat (of aangepast) hebben ze nog niks want de sessie is IP gelocked. Maar volgens mij moet je niet zo in zitten over 'cookies jatten', dat is de verantwoordelijkheid van de eigen gebruiker zou ik zo zeggen.

[ Voor 4% gewijzigd door Hans1990 op 25-12-2005 10:59 ]

[frickY]

Priet schreef op zondag 25 december 2005 @ 10:15:
Je kan je sessies/cookies wel zo inrichten dat er meerdere mensen achter één NAT tegelijk in kunnen logggen op dezelfde website. Maak daarvoor gebruik van koppeling met IP + een willekeurige tekenreeks (validatie) + gebruikers ID. (validatie en/of ID).

Maar hiermee voorkom je niet dat mensen de cookie handmatig wijzigen en het ID wijzigen in een ander ID dat met dat IP al was ingelogd...

Bij het gebruik van sessies heb je in je cookie alleen het sessie-id. Die kun je wijzigen, maar de kans is klein dat je een sessieID weet te raden welke op dat moment ook actief is. Als ook het IP in de sessie is opgeslagen, en bij elke request wordt vergeleken, heb je dat ook afgeschermt.
IP adressen kun je mijns inziens niet spoofen. Je KUNT het wel spoofen, waardoor het request vanaf een ander adres lijkt te komen, maar de respons gaat dan ook naar dat gespoofde adres, waardoor de 'attacker' geen zicht heeft op wat er gebeurd.

[Skaah]

- username/password niet plaintext verzenden, bijvoorbeeld door clientside SHA1 + salt te gebruiken (met JavaScript bijvoorbeeld)

Heb je er aan gedacht dat mensen zonder Javascript ook wel willen inloggen? Voor een backend waar je sowieso JS voor nodig hebt misschien niet zo'n probleem, maar voor een forum of een KB natuurlijk wel.

Wat de rest zegt: hash verzinnen, in cookie en & db zetten, en dan maar kijken of de hash + ip combinatie bestaat.

Je KUNT het wel spoofen, waardoor het request vanaf een ander adres lijkt te komen, maar de respons gaat dan ook naar dat gespoofde adres, waardoor de 'attacker' geen zicht heeft op wat er gebeurd.

Voor sommige requests is dat ook niet nodig natuurlijk!
http://www.example.com/admin/delete.php?id=3. Zonder antwoord is de schade ook al gedaan.

[ Voor 29% gewijzigd door Skaah op 25-12-2005 12:24 ]

[mr_star]

Skaah schreef op zondag 25 december 2005 @ 12:23:
Voor sommige requests is dat ook niet nodig natuurlijk!
http://www.example.com/admin/delete.php?id=3. Zonder antwoord is de schade ook al gedaan.

En iedereen die op deze manier dingen laat verwijderen zonder bevestiging te vragen moeten ze afschieten Zonder bevestiging kan dit uiteraard op nog eenvoudigere manieren te misbruiken zijn. Daar hoef je niet eens een IP adres voor te spoofen.

[jochemd]

MLM schreef op zaterdag 24 december 2005 @ 22:01:
- username/password niet plaintext verzenden, bijvoorbeeld door clientside SHA1 + salt te gebruiken (met JavaScript bijvoorbeeld)

Ga nou niet zelf met Javascript prutsen. Dat zit gewoon in het HTTP protocol ingebouwd. Zie Digest Authentication in RFC 2617.

[jochemd]

Skaah schreef op zondag 25 december 2005 @ 12:23:Voor sommige requests is dat ook niet nodig natuurlijk!
http://www.example.com/admin/delete.php?id=3. Zonder antwoord is de schade ook al gedaan.

Ken je protocollen: ook daar is een geldige retourweg nodig. De volgorde is nog atijd:

code:

Client              Server
Syn          ->
             <-     Ack/Syn
Ack/Request  ->
                    verwerkt Request

Als de Ack/Syn van de server nooit op de client aankomt omdat het IP gespoofed is zal de client nooit het HTTP request kunnen versturen.

[MLM]

jochemd schreef op zondag 25 december 2005 @ 13:03:
[...]

Ga nou niet zelf met Javascript prutsen. Dat zit gewoon in het HTTP protocol ingebouwd. Zie Digest Authentication in RFC 2617.

Digest Authentication (net als basic authentication) kan heel slecht uitgelogged worden (manier, als die er is, verschilt per browser). Ik denk dat dat een groter gat maakt dan het oplost...

[BasieP]

MLM schreef op zondag 25 december 2005 @ 13:47:
[...]


Digest Authentication (net als basic authentication) kan heel slecht uitgelogged worden (manier, als die er is, verschilt per browser). Ik denk dat dat een groter gat maakt dan het oplost...

true, bovendien zijn er genoeg kant en klare scripts die bijv md5 of sha1 encryptie kunnen toepassen