[SSL] zin en onzin van SSL

[ZeilDude]

Ik ben bezig een webapplicatie op te zetten in ASP. Basis hiervoor is het inloggedeelte, dat als volgt werkt:
- met een formulier stuurt de gebruiker naam + password naar een asp-pagina;
- de asp-pagina vergelijkt of de naam en pass voorkomen in de database (database staat in een beveiligde directory);
- indien de login correct is, wordt er een sessievariabele aangemaakt (serverside);
- de gebruiker heeft middels de sessievariabele toegang tot de pagina's op de website.

Aardig veilig lijkt me zo. Zwak punt is echter dat gebruiksersnaam en wachtwoord via een onbeveiligde verbinding naar de asp-pagina worden verzonden. Dit kan veiliger lijkt mij.

Ik ben niet bekend met SSL en ik kan hier ook geen duidelijke informatie over vinden. Wat ik van SSL weet, is dat het de verbinding tussen gebruiker en server veiliger maakt. Hoe het precies werkt en wat je ervoor nodig hebt weet ik niet.

Is het nu nodig om de verbinding de gehele tijd via SSL te laten gaan, of alleen tijdens het inloggen? Bij Hotmail bijvoorbeeld, wordt ie alleen even secure tijdens het inloggen, daarna schakeld ie weer terug naar een normale verbinding.

Mijn provider ondersteunt tegen meerprijs SSL. Ik heb geen idee of dit geld voor één enkele verbinding of dat ik er meerdere gebruikers tegelijk mee kan ondersteunen. Moet ik iets speciaals toevoegen aan mijn ASP-pagina's voor het SSL-verhaal?

Tot slot... wordt mijn inlogsysteem hier nu wel veiliger van, of kan ik het beter op een andere manier aanpakken?

[Equator]

SSL versleuteld de verbinding tussen de client en de server.

Dat betekend dat alle data versleuteld worden verstuurd. M.a.w. Op het moment dat jij je inlogsysteem via ssl laat lopen dan worden username en wachtwoord dus niet meer als plain text over de lijn gegooid maar versleuteld.

Inweze hoef je dus ook neits meer toe te voegen aan je pagina. SSL is een instelling op de server, en iets wat tussen de server en de client tot stand komt.. Je ASP pagina heeft daar niets mee van doen.

Dus ja, in weze wordt het er veiliger van.
De vraag is, vind jij het die meerprijs waard om veiliger in te loggen.

[axis]

Je kunt zelf weten of je al het verkeers over HTTPS laat lopen of alleen de inlogprocedure, je kunt zelf redirecten naar http://www.site.nl/pagina of httpS://www.site.nl/pagina..

De afweging is of je het inderdaad het geld waard vindt.. Voordeel van die encryptie is dat de username en pass niet meer sniffbaar zijn, en het kan ook voor je eindbezoekers een goed gevoel geven (je kunt zelfs ook nog met secure logo's gaan patsen om deze reden), technisch maakt het allemaal niet zoveel uit..

[ZeilDude]

Pfff, krijg zojuist bericht van mijn provider. Het activeren van SSL kost maar EUR 20 per jaar. Voor dat geld kan ik een zogenaamde gratis 'self signed certificate', in dat geval is uw verbinding wel beveiligd, maar krijgen bezoekers aan de site wel steeds een foutmelding te zien dat de authenticity van de SSL verbinding niet kan worden vastgesteld.
Wil ik een certificaat zonder de foutmelding (128 bits), dan ben ik maar liefst EUR 400 kwijt! Kan ik zo'n certificaat elders goedkoper krijgen, of ben ik hierin afhankelijk van mijn provider?

[Jaap-Jan]

ZeilDude schreef op donderdag 14 juli 2005 @ 10:21:
Pfff, krijg zojuist bericht van mijn provider. Het activeren van SSL kost maar EUR 20 per jaar. Voor dat geld kan ik een zogenaamde gratis 'self signed certificate', in dat geval is uw verbinding wel beveiligd, maar krijgen bezoekers aan de site wel steeds een foutmelding te zien dat de authenticity van de SSL verbinding niet kan worden vastgesteld.
Wil ik een certificaat zonder de foutmelding (128 bits), dan ben ik maar liefst EUR 400 kwijt! Kan ik zo'n certificaat elders goedkoper krijgen, of ben ik hierin afhankelijk van mijn provider?

Dan moet je rondsnuffelen bij Thawte, Verisign enzovoort. Dat zijn die bedrijven waarvan veel browsers standaard een certificaat van hebben.

[RM-rf]

ZeilDude schreef op donderdag 14 juli 2005 @ 10:21:

Wil ik een certificaat zonder de foutmelding (128 bits), dan ben ik maar liefst EUR 400 kwijt! Kan ik zo'n certificaat elders goedkoper krijgen, of ben ik hierin afhankelijk van mijn provider?

Zelf zo'n certifcaat aanschaffen kost eenmalig een bedrag van rond de 130 euro en dan jaarlijks eenzelfde bedrag ...
het verschil is dat je certficaat gecontroleerd wordt door een onafhankelijke instantie, dat garanderd dat je ook werkelijk op het moment van het maken van de verbinding contact hebt met de server dei is waarvoor hij zich uitgeeft ...

Verder, de versleuteling zelf, gebeurt ook met een ongeldig certificaat, dus an sich is een verbinding met een ongeldig certificaat net zo veilig als eentje met een ongeldig certificaat...
enkel de identificatie van de server waarmee de versleuteling wordt uitgewisseld, is beter geregeld

Voor banken en verzekeringsfirma's of bedrijven die een grote clientele bedienen die over hun internetverbiding financiele transacties bekijken is zoiets essentieel, anders toch een stuk minder (ik heb zelf voor een grote internationale financiele instelling gewerkt die zelfs ook langere tijd een ongeldig certificaat voor de SSL.-versleuteling benutten, ook al was het project zelf meerdere miljoenen euro qua investering..., dat was ook weer een beetje overdreven spaarzuchtig)...

Overigens, ik zou altijd een versleuteling over alle pagina's doen, stel je voor dat je wel het password/gebruikersnaam-request versleuteld maar daarna niet meer, dan kan nog altijd probleemloos een session-id 'afgeluitsred worden en is de 'veiligheid' wel heel erg oppervlakkig

[axis]

RM-rf schreef op donderdag 14 juli 2005 @ 10:33:
[...]


Zelf zo'n certifcaat aanschaffen kost eenmalig een bedrag van rond de 130 euro en dan jaarlijks eenzelfde bedrag ...
het verschil is dat je certficaat gecontroleerd wordt door een onafhankelijke instantie, dat garanderd dat je ook werkelijk op het moment van het maken van de verbinding contact hebt met de server dei is waarvoor hij zich uitgeeft ...

Je hebt ze al goedkoper, maar dan moet je goed shoppen..

En sja, voor die paar euro heb je wel een fatsoenlijk certificaat, beetje lullig als alle bezoekers van je site elke keer 30 sec moeten wachten, en door een warning heen moeten klikken.

Ligt er ook aan.. als het een besloten site is, is dat geen probleem.. Je kunt ook zelf certificaten genereren (die self-signed waar je het over had) in linux of met een windows server, en dan geef je je gebruikers een kopietje van het 'root certificate'.. Als ze die vertrouwen, krijgen ze nooit meer een error op jouw certificaten. Maarja, dat doe je ook alleen maar met een select groepje mensen..

Overigens, ik zou altijd een versleuteling over alle pagina's doen, stel je voor dat je wel het password/gebruikersnaam-request versleuteld maar daarna niet meer, dan kan nog altijd probleemloos een session-id 'afgeluitsred worden en is de 'veiligheid' wel heel erg oppervlakkig

Dat klopt opzich wel, maar dat neemt ook weer serverbelasting met zich mee.. En als je 100 bezoekers per dag hebt boeit dat niet, maar als je eenmaal 50k bezoekers per dag hebt.. Weet ook niet over wat voor site de TS het heeft..

[ Voor 4% gewijzigd door axis op 14-07-2005 10:43 ]

[aZuL2001]

Je certificaat is wel geldig, de verificatie van het certificaat gebeurt alleen niet door een "trusted" party, vandaar de waarschuwing. (en dus geen foutmelding)

/miereneuken

[reinhrst]

Het certificaat dat geen warning genereert moet uitgegeven worden door een registered Certificate Authority, zoals Verisign. Deze controleert jouw identiteit (zodat je niet een certificaat kan aanvragen op de naam Microsoft of zo), en dat kost geld. Er zit zeker wel concurrentie in deze markt dus je zou eens kunnen gaan shoppen, maar de vraag is of jouw provider wel toestaat dat je je eigen certificaat aanlevert.

Overigens hoeft een self-signed certificaat maar 1 keer geaccepteerd te worden per browser (als deze tenminste op accept permanently klikt).

De vraag is trouwens sowieso in hoeverre SSL de site nou ECHT veiliger maakt. Als ik een adsl abbo van XS4all heb en jouw site staat bij www.xnet.com kan het verkeer alleen onderschept worden door xnet.com, xs4all zelf of de amsterdam internet exchange, en deze partijen zullen waarschijnlijk weinig baat hebben bij het afluisteren van het verkeer met jouw website.
Anders is het als een gebruiker via een onbeschermd accesspoint verbinding maakt, bijv een tmobile of huphop AP. Dan kan iedereen met een wlan kaartje in de buurt de verbinding afluisteren en dan kan ssl dus wel extra beveiliging betekenen.

Naast ssl zijn er nog andere manieren om het wachtwoord te beveiligen. Je zou het wachtwoord op de client door javascript samen met het sessie_id (of zo) kunnen laten hashen en deze hash op de server controleren. Het is wel wat extra werk om het goed te krijgen maar is wel goedkoper

Overigens is de reden om niet een hele site op ssl te laten draaien voornamelijk de resources die ingenomen worden door de ssl encryptie en weer decryptie aan de client kant. Maar als de server toch niet van jou is is dat minder een probleem natuurlijk ;-)

[Polderdijk]

Nou ik weet niet hoe ze aan die € 400,- komen, maar ik kan (nu tijdelijke actie via via) een SSL krijgen voor $ 15,- eerste jaar. Daarna $ 30,- per jaar. Je site is dan voor $ 10.000 verzekerd tegen fraude.
Dit is wel een single certificaat, dus kan maar op 1 hostheader werken, dus bijvoorbeeld www.jouwdomein.nl.

Dus even goed zoeken en je hebt voor een paar tientjes per jaar een SSL. Let wel op dat je hoster ook nog het één en ander moet doen om jou dat certificaat te kunnen laten gebruiken. Dus overleg vóór aanschaf goed met je hoster om problemen te voorkomen!)

[axis]

reinhrst schreef op donderdag 14 juli 2005 @ 10:56:
Overigens hoeft een self-signed certificaat maar 1 keer geaccepteerd te worden per browser (als deze tenminste op accept permanently klikt).

Yup, maar dat knopje zit volgens mij (nog) niet in IE.. Weet niet wat de doelgroep van zijn site is?

De vraag is trouwens sowieso in hoeverre SSL de site nou ECHT veiliger maakt. Als ik een adsl abbo van XS4all heb en jouw site staat bij www.xnet.com kan het verkeer alleen onderschept worden door xnet.com, xs4all zelf of de amsterdam internet exchange, en deze partijen zullen waarschijnlijk weinig baat hebben bij het afluisteren van het verkeer met jouw website.

Euh? De request wordt door de client geencrypt, naar de server gestuurd, en op de webserver gedecrypt. De reply weer de andere kant op.. xs4all of de AMS-IX zien alleen een geencrypte stream.. Dus je hebt wel degelijk veiligheid in dat opzicht. De vraag is of het NODIG is..

Naast ssl zijn er nog andere manieren om het wachtwoord te beveiligen. Je zou het wachtwoord op de client door javascript samen met het sessie_id (of zo) kunnen laten hashen en deze hash op de server controleren. Het is wel wat extra werk om het goed te krijgen maar is wel goedkoper

Klopt, maar als ik op hetzelfde wireless access point zit als een bezoeker, of ik ben een boze huisgenoot op dezelfde hub, zou ik zo'n pakketje alsnog kunnen sniffen, en valse requests kunnen maken met zijn sessieid en passwordhash. (correct me if I'm wrong) Met SSL kan dat niet.. Niemand die de moeite gaat doen, maar goed.

[ Voor 3% gewijzigd door axis op 14-07-2005 11:08 ]

[usr-local-dick]

Geen werving ofzo maar ik haal vaak certificaten bij www.xolphin.nl, dacht iets van 50 eu per jaar.
Wij doen alleen de inlog procedures via SSL, de rest van de content niet(nogal wat binaries en bovendien niet privay gevoelig) een beetje nutteloos is.

Voor twee geeltjes per jaar (per domein dus he) ga ik niet moeilijk doen, maar 400 dat is een beetje teveel van het goede.
Als je de hostname goed uitkiest kan je het cert ook voor een hoop andere dingen gebruiken.
Wij hebben 1 cert wat gebruikt wordt voor HTTPS, FTP/TLS, POP3S, IMAPS.
Daar heb jij waarschijnlijk niets aan, maar je kan dus meerdere vliegen in 1 klap slaan...

[ZeilDude]

RM-rf schreef op donderdag 14 juli 2005 @ 10:33:
[...]

Overigens, ik zou altijd een versleuteling over alle pagina's doen, stel je voor dat je wel het password/gebruikersnaam-request versleuteld maar daarna niet meer, dan kan nog altijd probleemloos een session-id 'afgeluitsred worden en is de 'veiligheid' wel heel erg oppervlakkig

Ok, dat is goede info. Ik wist dus niet dat sessievariabelen afgeluisterd konden worden. Een duidelijke reden om de gehele sessie te beveiligen, als ik inderdaad SSL wil gebruiken.

Ik lees verder hier over 'selftsigned' certifacten. Dat zijn naar ik begrijp, dus prima certificaten, alleen worst er een waarschuwing getoond dat hij niet gecontroleerd is door een onafhankelijke partij als Verisign.
In mijn project gaat het een dienst voor bedrijven, waarbij ik zorgvuldig wil omspringen met contactgegevens. Ik schat dat ik in eerste instantie deze diens aan ga bieden voor zo'n 10 bedrijven die hooguit wekelijks zullen inloggen. Wellicht is voor het voor hen acceptabel als zij zo'n foutmelding krijgen, mits ik die duidelijk aankondig. In een later stadium kan ik altijd overstappen op 'echte' certificaten.

Topantwoorden trouwens hier, handig als mensen kennis van zaken hebben!

usr-local-dick schreef op donderdag 14 juli 2005 @ 11:58:
Geen werving ofzo maar ik haal vaak certificaten bij www.xolphin.nl, dacht iets van 50 eu per jaar.
Wij doen alleen de inlog procedures via SSL, de rest van de content niet(nogal wat binaries en bovendien niet privay gevoelig) een beetje nutteloos is.

Voor twee geeltjes per jaar (per domein dus he) ga ik niet moeilijk doen, maar 400 dat is een beetje teveel van het goede.
Als je de hostname goed uitkiest kan je het cert ook voor een hoop andere dingen gebruiken.
Wij hebben 1 cert wat gebruikt wordt voor HTTPS, FTP/TLS, POP3S, IMAPS.
Daar heb jij waarschijnlijk niets aan, maar je kan dus meerdere vliegen in 1 klap slaan...

Hoe controleer jij dan of iemand is ingelogd? Met een sessie-variabele? Zo ja, vind jij dat dan wél veilig genoeg (in tegenstelling tot RM-rf)? Zo nee, wat is jouw oplossing?

[ Voor 33% gewijzigd door ZeilDude op 14-07-2005 12:04 . Reden: reactie op post ]

[P_de_B]

Als zij jouw certificaat in hun browser als trusted markeren, krijgen ze de foutmelding niet weer. Misschien een optie?

[Standeman]

comlpeet offtopic.

de asp-pagina vergelijkt of de naam en pass voorkomen in de database (database staat in een beveiligde directory);

Kijk wel uit voor sql-injection.. Anders heb je nog niets aan je certificaat

[ZeilDude]

Standeman schreef op donderdag 14 juli 2005 @ 13:37:
comlpeet offtopic.


[...]


Kijk wel uit voor sql-injection.. Anders heb je nog niets aan je certificaat

Bedankt voor de tip! Weinig kans trouwens, omdat ik formuliervelden meestal afvang met reguliere expressies, zeker in geval van login en pass. Extra beveiliging om te scannen op SQL-instructies is inderdaad wél een extra beveiliging voor 'open' formuliervelden.

Overigens heb ik inmiddels leuke dingen gelezen over MD5, salt, hashes, challenges en aanverwanten. Allemaal mogelijkheden om het login-verhaal te verbeteren.

Blijft staan, het verhaal na de login: Toegang wordt dan gecontroleerd op basis van een sessie-id. Hoe gemakkelijk is deze te spoofen of te faken? Een optie, is zoals eerder gezegd SSl, maar zijn er ook andere opties?

[pierre-oord]

ZeilDude schreef op donderdag 14 juli 2005 @ 14:28:
[...]


Bedankt voor de tip! Weinig kans trouwens, omdat ik formuliervelden meestal afvang met reguliere expressies, zeker in geval van login en pass. Extra beveiliging om te scannen op SQL-instructies is inderdaad wél een extra beveiliging voor 'open' formuliervelden.

Overigens heb ik inmiddels leuke dingen gelezen over MD5, salt, hashes, challenges en aanverwanten. Allemaal mogelijkheden om het login-verhaal te verbeteren.

Blijft staan, het verhaal na de login: Toegang wordt dan gecontroleerd op basis van een sessie-id. Hoe gemakkelijk is deze te spoofen of te faken? Een optie, is zoals eerder gezegd SSl, maar zijn er ook andere opties?

Faken kan je heel gemakkelijk, zeker als het sessieid via GET gaat ipv met een cookie. Er zijn topics over een betere controle tegen sessie kaping (bijvoorbeeld van de orginele persoon ook opslaan welke browser die gebruikt, even eventueel vanaf welk ip adres die komt, maar dat kan weer nadeel zijn als deze persoon een proxy server gebruikt met meerder ip's).

Via een javascriptje kun je het password ook al MD5 gecodeerd over de lijn sturen, zodat het plaintekst password niet te zien is en mensenn minder makkelijk bijvoorbeeld email van de persoon kunnen gaan ophalen. Alsnog: Als iemand de MD5 afluisterd kan deze natuurlijk ook zo inloggen, dus voor de site zelf is het eigenlijk geen beveiliging.

SSL is gewoon het mooiste: Passwords/sessies: allemaal gecodeerd

[Verwijderd]

Ik zou nooit alleen met sessie werken, hoeft er maar 1 ding gespoofed worden. Denk ook eens aan een combinatie van:

- Cookies
- Sessie
- Referer
- IP
- User Agent

Je kan als een bezoeker op de inlog pagina komt het scherm herladen dmv een form met variablen erin (uiteraard md5ven oid). Je controleert of de referer wel van dezelfde pagina is en dat het ip nog hetzelfde is. Voordat de pagina herladen wordt laat je alle sessies en cookies verwijderen. Dus zodra de pagina herladen is weet je dat:
- gespoofte sessies en cookies weg zijn
- het dezelfde gebruiker is (IP)
- gebruiker van een veilige/vertrouwde pagina komt (Referer)

Kleine kans dat er dan iemand inlogt met gespoofte gegevens. Ik heb het niet geprobeerd, even m'n grijze massa laten werken. Dit is niet bepaald handig als je veel bezoekers krijg, dus denk ook na over de performance.

Interessante SSL info:
- http://www.freesll.com
- http://www.verisign.com
- http://www.thawte.com
- http://www.geotrust.com/

[reinhrst]

axis schreef op donderdag 14 juli 2005 @ 11:07:
Euh? De request wordt door de client geencrypt, naar de server gestuurd, en op de webserver gedecrypt. De reply weer de andere kant op.. xs4all of de AMS-IX zien alleen een geencrypte stream.. Dus je hebt wel degelijk veiligheid in dat opzicht. De vraag is of het NODIG is..

Ik bedoelde hier wat er gebeurt in het geval van een un-encrypted verbinding, inderdaad niet duidelijk in mijn verhaal....

Klopt, maar als ik op hetzelfde wireless access point zit als een bezoeker, of ik ben een boze huisgenoot op dezelfde hub, zou ik zo'n pakketje alsnog kunnen sniffen, en valse requests kunnen maken met zijn sessieid en passwordhash. (correct me if I'm wrong) Met SSL kan dat niet.. Niemand die de moeite gaat doen, maar goed.

Je moet inderdaad niet alleen het password hashen, maar een string geconcateerd van het password met een random string die je hebt gegenereerd en tijdelijk op de server in de sessie opslaat. Vervolgens moet je in de sessie wel checken of deze nog steeds van hetzelfde ip nummer afkomt. Niet de allermakkelijkste methode, en nog steeds niet waterdicht als beide computers op hetzelfde ip zitten, dmv bijv een NAT.

Verwijderd schreef op donderdag 14 juli 2005 @ 21:11:
Ik zou nooit alleen met sessie werken, hoeft er maar 1 ding gespoofed worden. Denk ook eens aan een combinatie van:

- Cookies
- Sessie
- Referer
- IP
- User Agent

Naar mijn idee zijn cookies en sessie hetzelfde:als iemand je sessie_id weet te achterhalen zal hij ook weinig problemen hebben met je andere cookies jatten. Ook UserAgent en Referer vallen onder dit rijtje. Hiermee wil ik niet zeggen dat het niet nuttig is, het kan onbedoeld sessie-overname voorkomen maar zal in geval iemand daadwerkelijk je sessie probeert over te nemen deze persoon niet tegen kunnen houden.

Over referer valt overigens nog wel meer te zeggen. Checken op referer kan grote problemen voorkomen. Stel een bericht kan je verwijderen via de link http://www.Asite.nl/deletemessage.php?id=12345. Uiteraard checkt deze php file op het ingelogd zijn. Wat nou als www.Bsite.nl/pagina.php een iframe opent naar die link. Er is een kans dat je perongeluk nog ingelogd bent en dus een bericht verwijdert (of erger) zonder dat je het wil of weet. Een referer check zou in dit geval kunnen helpen;
Er is echter iets vervelends: sommige browsersettings en firewalls (bijv. Norton) verwijderen de referer uit de HTTP headers waardoor deze check niet werkt.....

Op ip-nummer zou ik altijd checken (maw: sla het ip nummer bij het aanmaken van de sessie op in de sessie variabele, en check dit bij elke request). Het is waar dat deze methode niet werkt als er via proxies gesurft wordt, maar in nederland komen proxies nauwelijks meer voor. In America zijn echter nog wel wel mensen die via AOL proxie surfen.

[Gomez12]

Verwijderd schreef op donderdag 14 juli 2005 @ 21:11:
Ik zou nooit alleen met sessie werken, hoeft er maar 1 ding gespoofed worden. Denk ook eens aan een combinatie van:

- Cookies

Kan een gebruiker uit hebben staan

- Sessie

sessies zijn over het algemeen al cookies

- Referer

wordt door enkele tools geblokkeerd ( symantec etc ) en is dus lang niet altijd aanwezig

- IP

Zoals al eerder gezegd, als je mensen met proxy's met variabele ip's hebt ( AOL is hier berucht om ) zegt dit niks

- User Agent

Is vrij algemeen, de User agent van IE6 heeft denk ik 50% van de gemiddelde pagina bezoeker ongewijzigd staan

Je kan als een bezoeker op de inlog pagina komt het scherm herladen dmv een form met variablen erin (uiteraard md5ven oid). Je controleert of de referer wel van dezelfde pagina is en dat het ip nog hetzelfde is. Voordat de pagina herladen wordt laat je alle sessies en cookies verwijderen. Dus zodra de pagina herladen is weet je dat:
- gespoofte sessies en cookies weg zijn
- het dezelfde gebruiker is (IP)
- gebruiker van een veilige/vertrouwde pagina komt (Referer)

Kleine kans dat er dan iemand inlogt met gespoofte gegevens. Ik heb het niet geprobeerd, even m'n grijze massa laten werken. Dit is niet bepaald handig als je veel bezoekers krijg, dus denk ook na over de performance.

Dit is btw niet als kritiek bedoeld, maar meer dat je moet nadenken over een waarderingssysteem van de bovengestelde eisen. Als je echt alle 5 de gegevens nodig acht, dan mis je denk ik een hoop bezoekers, want die voldoen niet aan alle 5, als je 1 van de 5 nodig acht mis je je beveiliging, want 1 is heel makkelijk te spoofen. Ik denk in dit voorbeeld meer iets van dat er 3 van de 5 nodig zijn, dan weet je vrij zeker dat het dezelfde persoon is.

Maar zoek ook eens naar challenge/respons.

[Verwijderd]

reinhrst schreef op donderdag 14 juli 2005 @ 21:38:

Naar mijn idee zijn cookies en sessie hetzelfde:als iemand je sessie_id weet te achterhalen zal hij ook weinig problemen hebben met je andere cookies jatten.

Als iemand een sessie id weet te achterhalen is er al iets goed mis. Dan is er iemand vreselijk slordig geweest met pagina's die hij heeft opgrvraagd, of hij heeft een URL met zijn sessie id verspreid. Een stukje extra veiligheid is dan het koppelen van een sessie aan een ip adres. Dat betekent wel dat je zorgt dat gebruikers met een wisselend IP adres elke keer weer moeten inloggen. Bij een forum is dat vreselijk irritant, aangezien het vaak niet belangrijk genoeg is.

Ook UserAgent en Referer vallen onder dit rijtje. Hiermee wil ik niet zeggen dat het niet nuttig is, het kan onbedoeld sessie-overname voorkomen maar zal in geval iemand daadwerkelijk je sessie probeert over te nemen deze persoon niet tegen kunnen houden.

Over referer valt overigens nog wel meer te zeggen. Checken op referer kan grote problemen voorkomen. Stel een bericht kan je verwijderen via de link http://www.Asite.nl/deletemessage.php?id=12345. Uiteraard checkt deze php file op het ingelogd zijn. Wat nou als www.Bsite.nl/pagina.php een iframe opent naar die link. Er is een kans dat je perongeluk nog ingelogd bent en dus een bericht verwijdert (of erger) zonder dat je het wil of weet. Een referer check zou in dit geval kunnen helpen;

Enkele jaren geleden was dit vaak nog mogelijk met fora, en dergelijke websites waarbij de bezoeker content aan kan leveren. Je kunt beter niets doen met de referrer, en zorgen dat belangrijke formulieren met een POST request verstuurd worden, en dat deze een unieke, niet te "raden" code meestuurt, toevallig is het sessie id hier uitermate geschikt voor.
Voor echt belangrijke requests, bijvoorbeeld het wijzigen van een gebruikersprofiel, zul je sowieso moeten zorgen dat de gebruiker zijn wachtwoord in moet vullen.

Er is echter iets vervelends: sommige browsersettings en firewalls (bijv. Norton) verwijderen de referer uit de HTTP headers waardoor deze check niet werkt.....

Genoeg reden om nooit te vertrouwen op de aanwezigheid van een geldige referrer. En dat geldt ook voor de user agent header.

Op ip-nummer zou ik altijd checken (maw: sla het ip nummer bij het aanmaken van de sessie op in de sessie variabele, en check dit bij elke request). Het is waar dat deze methode niet werkt als er via proxies gesurft wordt, maar in nederland komen proxies nauwelijks meer voor. In America zijn echter nog wel wel mensen die via AOL proxie surfen.

Maar inbellen komt nog wel voor. Koppel een sessie alleen aan een ip adres als de gebruiker daarom vraagt, of als de applicatie belangrijk genoeg is.

[Verwijderd]

Gomez12 schreef op donderdag 14 juli 2005 @ 21:40:

Kan een gebruiker uit hebben staan

Gebruikers die cookies uit hebben staan kiezen ervoor om niet in te loggen, en zullen bij elke belangrijke request hun wachtwoord dan maar moeten opgeven.

sessies zijn over het algemeen al cookies

Nee, ze maken vaak gebruik van cookies om de gebruikers te kunnen tracken. Sessies kunnen ook in bijvoorbeeld de URL's worden bijgehouden. Voor cookies geldt mijn eerste opmerking. Van sessies in de URL meegeven ben ik geen voorstander. Cookies zijn gewoon het meest geschikt.

Rest van je opmerkingen ben ik het redelijk mee eens.

[ Voor 9% gewijzigd door Verwijderd op 14-07-2005 21:57 ]

[Johnsel]

k weet niet of het nog nodig is maaar, veel mensen denken dat alleen input velden filteren op sql genoeg is, maar drop-down boxes niet hoeven... FOUT!
je kan nl ook zelf een pagina brouwen die andere waarden hebbe voor drop-down dingen..

[mulder]

Johnsel schreef op vrijdag 15 juli 2005 @ 15:59:
k weet niet of het nog nodig is maaar, veel mensen denken dat alleen input velden filteren op sql genoeg is, maar drop-down boxes niet hoeven... FOUT!
je kan nl ook zelf een pagina brouwen die andere waarden hebbe voor drop-down dingen..

Ik denk zelfs dat je mag zeggen dat je alle input moet controleren Johnsel! Never trust user input! Op de barricade!


...Thank god it's friday..