Hoofdcategorieën

[RSS] Index » Nieuws » Pro » Maatschappij » Privacy & beveiliging » 'Cookies van grote sites te onderscheppen' - Update

'Cookies van grote sites te onderscheppen' - Update

Door Bart Veldstra, woensdag 12 september 2007 18:26
Submitter: Forau, views: 26.397

Het US-CERT claimt een kwetsbaarheid gevonden te hebben in de manier waarop cookies gebruikt worden voor gebruikersidentificatie. Het is echter niet duidelijk waarom het CERT dit als 'nieuws' presenteert; deze kwetsbaarheid bestaat al sinds het eerste koekje op het internet verscheen.

Sleutels - veiligheid (kleiner)Veel websites gebruiken cookies met een uniek identificatienummer om te voorkomen dat gebruikers zich bij iedere nieuwe pagina moeten identificeren. Deze cookie wordt met iedere request naar de server gestuurd als authenticatiemiddel. Hoewel de inlogprocedure voorafgaand aan het versturen van een cookie bij de meeste sites via een versleutelde verbinding loopt, heeft CERT geconstateerd dat de cookie zelf regelmatig in plain text-formaat verzonden wordt. Een kwaadwillende hacker kan de cookie onderscheppen en vervolgens gebruiken om zich voor te doen als de ingelogde gebruiker.

De constatering van het US-CERT komt echter niet als een verrassing, hoewel de organisatie wel flink wat ophef rond de 'ontdekking' maakt; de kwetsbaarheid van het cookie-mechanisme is al langer bekend. Veel webmasters kiezen er echter bewust voor om wel de loginprocedure - aangezien met een login en wachtwoord vaak meer schade aangericht kan worden, ook op andere sites - via een versleutelde https-verbinding te laten lopen, maar niet het verdere dataverkeer waartoe ook de identificatiecookie behoort.

De belangrijkste reden hiervoor is dat het versleutelen van al dit verkeer een behoorlijke belasting op de webservers kan leggen en dat het lastiger wordt om loadbalancers in te zetten om de belasting over een heel serverpark te verdelen. Vaak wordt daarom wel de mogelijkheid geboden om een cookie aan een ip-adres te verbinden. Hoewel dit ip-adres ook vervalst kan worden, vergt dit al flink wat meer inspanning en kennis van de aanvallers.

Gebruikers kunnen bovendien hun steentje bijdragen aan de beveiliging van hun gegevens, door niet met gevoelige gegevens in te loggen op onbekende of onbetrouwbare netwerken. Bovendien kan het versleutelen van de wifi-verbinding met behulp van wpa al heel wat kwaadwillenden tegenhouden. De enige correcte manier om deze kwetsbaarheid op te lossen, zou er echter uit bestaan http volledig te dumpen en over te stappen op https, met heel wat extra kosten voor serverhardware en certificaten tot gevolg.

Update 18.30u: De oorspronkelijke tekst presenteerde de 'ontdekking' van het US-CERT als nieuws. In de aangepaste versie werd wat nuancering en een kritische noot toegevoegd om een en ander in breder perspectief te plaatsen.

Volgende 21:34
Vorige 17:56

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 64 reacties zichtbaar640 Off-topic / Irrelevant: 61 reacties zichtbaar61+1 On-topic: 20 reacties zichtbaar20+2 Informatief: 15 reacties zichtbaar15+3 Must-read: 0 reacties zichtbaar0
«  1  2  »

Door Muthas, woensdag 12 september 2007 15:51

Score: 0
Gek dat zo'n groot internetbedrijf als Google hier kwetsbaar voor is.

Door FreezeXJ, woensdag 12 september 2007 15:56

Score: 0
helemaal niet, omdat ook zij fouten maken, maar deze sites druk bezocht worden. Hierop wordt dus veel geprobeerd, terwijl http://mijnkleineprivesite.nl over het algemeen geen interesse wekt. Ook Google maakt fouten...

Door Nijn, woensdag 12 september 2007 15:58

Score: 2
Kwetsbaar is een erg groot woord. Dit is een storm in een glas water. Inderdaad, de cookies worden vaak over een open verbinding verstuurd. Echter moet je wel redelijk wat voor elkaar krijgen wil je hier gebruik van kunnen maken.

Het is niet zo dat een cookie automatisch toegang verleent. Er worden veel meer controles uitgevoerd. Vaak gebruikte zijn controle of de browser gelijk is gebleven, controleren of het IP gelijk is gebleven en controleren of de sessie nog wel actief is. Bovendien zie je vaak dat cookies worden vervangen bij ieder bezoek.

Overigens is Tweakers zelf hier ook "kwetsbaar" voor.

[Reactie gewijzigd door Nijn op woensdag 12 september 2007 15:58]

Door Niels Sijm_IA, woensdag 12 september 2007 16:20

Score: 1
Bij het inloggen op Tweakers.net kun je kiezen om je sessie aan je IP-adres te koppelen. Hierdoor ben je niet meer vatbaar voor deze aanval.

Door TRRoads, woensdag 12 september 2007 16:52

Score: 1
Als de hacker al zo ver is dat hij verkeer naar jouw PC/IP kan onderscheppen (en dus de cookie kan opvangen) dan kan hij vast en zeker ook verkeer aanmaken alsof het vanuit jouw IP adres werd verzonden (immers kan hij de return ook weer opvangen).

Door arjankoole, woensdag 12 september 2007 20:35

Score: 1
dat is zo extreem moeilijk dat het eigelijk het overpeinzen niet waard is. de enige manier waarop dit hanteerbaar is is als de hacker in je eigen netwerk geinfiltreerd is.

Door i-chat, woensdag 12 september 2007 20:57

Score: 0
Open Wifi verbindingen ?????

Door arjankoole, woensdag 12 september 2007 21:03

Score: 0
Open Wifi verbindingen ?????
is heel specifiek, dat kun je niet bij ieder willekeurig doelwit toepassen.

[Reactie gewijzigd door arjankoole op woensdag 12 september 2007 21:03]

Door TRRoads, woensdag 12 september 2007 22:10

Score: 0
@arjankoole:

Man-in-the-middle attacks zijn de meest voorkomende manier om een cookie te onderscheppen en dan is het erg simpel om je eigen verkeer te laten lijken alsof het van het gebruikers IP af komt.

Dat een man-in-the-middle attack sowieso moeilijk is om uit te voeren is een feit, dat wordt dan ook (na de update) genoemd, het is dus een storm in een glas water, de aanval is erg moeilijk uit te voeren.

IP beveiliging is dus niet iets wat hierbij heel erg veel helpt, maar het helpt wel iets dus waarom niet?

Door arjankoole, woensdag 12 september 2007 23:27

Score: 0
IP beveiliging is dus niet iets wat hierbij heel erg veel helpt, maar het helpt wel iets dus waarom niet?
Oh, ik zeg ook absoluut niet dat je niet alle moeite moet getroosten om aan beveiliging te doen. (mits het binnen het redelijke blijft natuurlijk). Ik zelf gebruik in m'n sessie/cookie code een hele reeks aan checks, maar als iemand een sessie kaapt is daar inderdaad weinig tegen te doen.

Door TRRoads, donderdag 13 september 2007 02:15

Score: 2
Maar het faken van gegevens alsof het van de gebruiker af kwam is dus niet zo moeilijk als je het laat voorkomen, zeker niet als je te maken hebt met een hacker die een goede man-in-the-middle attack heeft uitgevoerd.

Zeker wanneer het een non-technische hack betreft (een hack die berust op de 'domheid' van de gebruiker) is het natuurlijk doodsimpel.

Voorbeeldje:

Stap 1 - Schrijf een trojan (of haal een kant en klare van het web of gebruik een trojan generator) die de hosts file van je slachtoffer bijwerkt en zodoende bijvoorbeeld tweakers.net laat doorverwijzen naar jouw eigen server (en zorg dat deze trojan bij de gebruiker terecht komt, kan nooit heel moeilijk zijn gezien de gemiddelde gebruiker)

Stap 2 - Zet een simpel proxy systeempje op (zijn ook genoeg kant en klaar te vinden op het web) zodat wanneer het slachtoffer op jouw server terecht komt ook daadwerkelijk tweakers.net te zien krijgt

Stap 3 - Wacht rustig af totdat de gebruiker op tweakers.net gaat kijken (kan nooit heel lang duren). Gebruiker is uitgelogd denkt: "Huh uitgelogd, najah whatever" en logt rustig in.

Nu heb je door het challange response systeem niet het wachtwoord van de gebruiker, maar als het goed is wel zijn sessie id. Je hebt nu alle rechten die de gebruiker ook heeft en de sessie is verbonden aan jouw eigen IP adres dus je hoeft technisch niets raars te doen om zijn sessie te gebruiken.

Dat is dus een relatief simpele manier om een man-in-the-middle attack te doen en zodoende de gebruiker z'n sessie te kapen en de ip beveiliging te foppen.

Als je echt fancy wil zijn zorg je ook nog eens dat op de sessiepagina van t.net het IP van de gebruiker even vervangen wordt van jouw eigen IP naar je slachtoffer z'n IP. Maar dan moet je echt een goede proxy hebben of een eigen systeem maken.

Alle tooltjes zijn kant en klaar te vinden door iedereen die Google weet te gebruiken, en verder doet de gebruiker alles voor je. Natuurlijk vertrouw je een beetje op de domheid van de gebruiker, maar dat gebruikers dom zijn is een feit.

[Reactie gewijzigd door TRRoads op donderdag 13 september 2007 02:26]

Door omixium, donderdag 13 september 2007 09:29

Score: 0
dan lijkt een keylogger mij handiger.

Door Roland684, donderdag 13 september 2007 09:42

Score: 0
Dat is erg naïef, ip-adressen zijn te spooffen.

Door AW_Bos, woensdag 12 september 2007 16:50

Score: 0
T.net heeft een Challenge systeem hiervoor gemaakt, om onderschepping tussendoor met sniffers enzo onmogelijk te maken.

Door Bor de Wollef, woensdag 12 september 2007 19:16

Score: 0
En dan zijn er nog legio mogelijkheden: man in the middle, het stelen van de info waarop de challenge wordt berekend etc.

Door TRRoads, woensdag 12 september 2007 19:38

Score: 0
@Arien:

Dat gaat over het inloggen, niet over het koekje waarin de sessie identifier zit, als je die onderschept kun je jezelf eenvoudig voordoen als de andere gebruiker.

Door JortK, woensdag 12 september 2007 15:57

Score: 0
Uit de experimenten van het US-CERT is gebleken dat onder andere gebruikers van de Google- en Microsoft-websites kwetsbaar zijn voor dergelijke aanvallen. Hierbij gaat het wel om proeven die begin deze maand zijn uitgevoerd en ondertussen al achterhaald kunnen zijn.
Ik gok dat deze gaten al weer gedicht zijn :+

Door MarcoTC, woensdag 12 september 2007 16:07

Score: 0
Ik weet niet of ik het goed begrijp maar werkt dit dus als een hacker in staat is om traffic te sniffen EN hij de verbinding naar de betreffende website niet secure is? Dan lijkt het me een storm in een glas water.

Als dat zo is kan hij net zo goed wachten tot het username en password voorbij komen bij de login. Lijkt me makkelijker.

Door Niels Sijm_IA, woensdag 12 september 2007 16:22

Score: 0
Een storm in een glas water is het niet.

Op een Wifi-netwerk zonder encryptie is het een eitje om traffic te sniffen. Uitzoeken wie er naar Google surft is ook niet zo moeilijk uit te zoeken.

De oplossingen zijn even simpel als talrijk. Koppel een sessie aan een IP-adres, en laat de verbinding over SSL lopen.

Door Bloodshot, woensdag 12 september 2007 16:43

Score: 0
Leuk voorbeeld, alleen werkt het dan niet meer als je meelift op diezelfde Wifi-verbinding: Dan heb je immers hetzelfde (geNATte) afzenderadres.

Door Niels Sijm_IA, woensdag 12 september 2007 16:50

Score: 0
Dat hangt af of NAT wordt toegepast of niet.

Zo ja, dan kun je controleren of de User Agent gelijk blijft. Maar de moraal van het verhaal blijft, dat je zonder encryptie (WPA op je Wifi of SSL bovenop je HTTP-verbinding) kwetsbaar blijft.

Door Bor de Wollef, woensdag 12 september 2007 19:09

Score: 0
User agent is in de meeste gevallen het zelfde en bovendien met de hand te spoofen. Sterker nog, er zijn gewoon firefox plugins voor.

Door Janoz, woensdag 12 september 2007 16:52

Score: 1
Als dat zo is kan hij net zo goed wachten tot het username en password voorbij komen bij de login. Lijkt me makkelijker.
Dat klopt helemaal en aan die gegevens heb je veel meer. Het verschil is echter dat het security aspect van het versturen van username en wachtwoord vaak wel onderkent wordt en dat hiervoor vaak een https verbinding wordt gebruikt (bv bij google).

Wat het US-CERT nu aangeeft is dat vervolgens vaak vergeten wordt oom ook het verstuurde cookie goed te beveiligen en dat dit dus alsnog een security risico met zich meebrengt.

Door arjankoole, vrijdag 14 september 2007 00:08

Score: 0
Wat het US-CERT nu aangeeft is dat vervolgens vaak vergeten wordt oom ook het verstuurde cookie goed te beveiligen en dat dit dus alsnog een security risico met zich meebrengt.
Nee, niet vergeten, bewust niet gedaan. Als je doet wat jij zegt, en een beveiligde cookie verstuurd, kan die alleen nog maar voor beveiligde verbindingen gebruikt worden, dus zul je al je verkeer 100% SSL moeten maken, en dat vreet ongeloofelijk veel resources. Een verdubbeling van het serverpark is iets wat zelfs google en microsoft zich niet kunnen permiteren.

Door uid0, woensdag 12 september 2007 16:10

Score: 2
Like, duh. Dat is een probleem wat al 30 jaar oud is.

Maar bedrijven als Google en Microsoft kiezen daarvoor, de enige redelijke beveiliging zou namelijk zijn om al het verkeer via https te laten lopen. Dan kunnen ze hun serverparken wel verviervoudigen, SSL is zo goedkoop niet (wat betreft processorkracht).

Een tussenoplossing zou zijn dat 1x per 5 minuten een omleiding naar https plaatsvindt om een nieuwe "onveilige" cookie voor de volgende 5 minuten op te halen. Maar ook dat biedt geen echte beveiliging.

Jammer dat CERT het naar voren brengt als "de ontdekking van de eeuw"

[Reactie gewijzigd door uid0 op woensdag 12 september 2007 16:10]

Door killercow, woensdag 12 september 2007 16:37

Score: 0
je zou een ssl accelerator of een Sun server met niagara cpu kunnen gebruiken als gateway naar je andere servers, dan hebben die geen last van de ssl versleutelingen.

Door GrooV, woensdag 12 september 2007 18:44

Score: 0
En wie betaald dat? ;)

Door Bor de Wollef, woensdag 12 september 2007 19:10

Score: 0
Het probleem met SSL accelerators is dat je uberhaubt totaal voorbij gaat aan de essentie van het servercertificaat die dan namelijk niet meer de server identificeert maar de accelerator. Min of meer oplichting van de gebruiker dus.

Door froggie, woensdag 12 september 2007 19:42

Score: 2
Een certificaat garandeerd alleen de identiteit van een (sub)domein en meestal niet de specifieke node uit het cluster wat daadwerkelijk dat domein serveert. Een accelerator maakt gewoon onderdeel uit van dat cluster en de enige plaats waar een aanvaller dan nog verkeer zou kunnen onderscheppen is tussen de accelerator en servers. In dat geval heeft de partij die dat cluster gebruikt/beheerd een groter probleem dan dat een identiteit in verkeerde handen valt.

Door arjankoole, woensdag 12 september 2007 21:08

Score: 2
Het probleem met SSL accelerators is dat je uberhaubt totaal voorbij gaat aan de essentie van het servercertificaat die dan namelijk niet meer de server identificeert maar de accelerator. Min of meer oplichting van de gebruiker dus.
Volgens die redenering zou je dus een SSL cert aan niet meer dan 1 server mogen hangen ( geloof me, je wilt het gebruiken op een cluster / loadbalanced omgeving) en mogen wildcard SSL certs ook niet uitgegeven worden.

Beide methoden zijn heel gangbaar en volledig geaccepteerd door de de organisaties die SSL bedacht hebben en beheren. (lees: IETF, Verisign, Thawte, anybody met een root-ca)

Je certificeert namelijk de verbinding met een subdomein, en het cert dient om jou te laten zien dat dat subdomein te vertrouwen is. het hangt allemaal op dat woordje vertrouwen. Als jij verisign (als opper Root-Certificate Authority) niet vertrouwd, wat ik je overigens helemaal niet kwalijk zou nemen, stopt het hele verhaal. (maar dan kun je in principe geen enkele SSL certificaat meer vertrouwen, behalve je eigen)

Door Dannydeman, woensdag 12 september 2007 16:20

Score: 0
Handig. Misschien is het zo wel mogelijk om een belangrijkere betastaus te krijgen in het MS beta programma als je simpel een cookie van iemand anders hebt die hoger is :)

Door killercow, woensdag 12 september 2007 16:36

Score: 0
geloof er geen bal van,

Werkelijke elke sessie manager verbindt de unieke code ook aan het IP van de gebruiker, wat het sniffen (tenzij het op een lan gebeurt) nutteloos maakt.

Door T_E_O, woensdag 12 september 2007 16:42

Score: 0
Of op een wireless lan... en dat zie je toch behoorlijk vaak. Alle publieke hotspots van bv. T-Mobile hebben ook encryptie "gewoon" uitstaan.

Door Muthas, woensdag 12 september 2007 16:46

Score: 0
IP's zijn te spoofen, het is echt veel moeilijker als het sniffen van een cookie en ook echte niet 1 2 3 te doen.

Verder, in Amerika heb je ook providers (AOL bijv.) die je een heel dynamisch IP geven, kunnen van de ene op de andere request veranderen. Aangezien MS en Google internationaal zijn hebben ze het koppelen aan IP adressen misschien uitgeschakeld.

Door Janoz, woensdag 12 september 2007 16:56

Score: 2
Werkelijke elke sessie manager verbindt de unieke code ook aan het IP van de gebruiker
Onzin. Veel session handlers hebben dit er niet standaard inzitten of hebben dat niet standaard aanstaan. Daarnaast wil je dat ook lang niet altijd. Mijn laptop gebruik ik op verschillende locaties, dus met verschillende ip adressen, maar ik wil toch wel ingelogd blijven. Wat dacht je daarnaast van mensen die via een proxy park gaan (zoals AOL) waarbij het IP telkens kan veranderen?

@Muthas:
IP spoofen in deze context kan niet. Een IP spoofen is misschien wel leuk en aardig, maar dat werkt alleen wanneer je een halve verbinding wilt opzetten zonder dat er ook maar een bitje data over verstuurd wordt. Als je immers niet je eigen IP gebruikt is het voor de server onmogelijk te achterhalen dat hij die data eigenlijk naar jou moet sturen.

Door Ravek, woensdag 12 september 2007 19:31

Score: 0
We gingen uit van de situatie dat iemand in staat was je cookie te bemachtigen en dus kan packet sniffen. Dus kan je prima je IP spoofen en alles wat terug verzonden wordt opsniffen en beantwoorden.

Door arjankoole, vrijdag 14 september 2007 00:13

Score: 0
We gingen uit van de situatie dat iemand in staat was je cookie te bemachtigen en dus kan packet sniffen. Dus kan je prima je IP spoofen en alles wat terug verzonden wordt opsniffen en beantwoorden.
dan ga je als je slim bent niet spoofen ( er is genoeg apperatuur die het weigert om een pakketje te versturen als het source-ip geen IP van hun is). Dan ga je met hetzelfde lek waardoor je snift via een root-kit of andere remote access hack op die machine zitten en stuur je het daar vandaan. Ergo, niets geen spoofing.

Spoofing werkte vroeger alleen toen ISP's hun routers niet beveiligden tegen het verzenden van pakketjes waarvan het source-ip niet een eigen reeks was. (dat was tot dat moment ook niet nodig). Het enige waarvoor het werkte was een DoS attack. (want daar hoefde je het antwoord niet van te hebben). Heel veel SYN en geen enkele ACK ( niet bij jou dus ).

Nu heeft spoofing proberen net zoveel nut als in een leeg zwembad springen. het levert je alleen maar veel pijn op ;)

Door Little Penguin, woensdag 12 september 2007 18:33

Score: 0
De enige correcte manier om deze kwetsbaarheid op te lossen, zou er echter uit bestaan http volledig te dumpen en over te stappen op https, met heel wat extra kosten voor serverhardware en certificaten tot gevolg.
HTTP hoeft alleen gedumpt te worden voor sites waar het belangrijk is om persoonlijke gegevens ook persoonlijk te houden - populaire webmail, web-office en andere tools dus.

Voor sites die wel een HTTPS verbinding nodig zouden hebben geldt verder dat een SSL-certificaat helemaal niet overdreven duur hoeft te zijn en dat de server-hardware inmiddels krachtig genoeg is om de SSL-versleuteling te realiseren.

Door Kees, woensdag 12 september 2007 18:44

Score: 2
Nee, dat is de server hardware niet. Als voorbeeld tweakers.net. We zouden alles (plaatjes, javascript, css, alle html, rss feeds) allemaal via https moeten sturen, ook grote downloads van files, want bij elke http request op *.tweakers.net zal het tweakers.net cookie door de browser meegestuurd worden.

Op dit moment doen wij vrijwel geen https verkeer, maar als ik zie hoeveel zwaarder dat is ten opzichte van normaal verkeer, dan moeten wij zeker ons server park verdubbelen in grootte om dat aan te kunnen.

Verder zou je het nodig moeten hebben op elke site waar je op kan inloggen, en mag de gebruiker van het domein waar het cookie staat ook niets onbeveiligd downloaden. Dus ook voor sites als youtube (tenzij je wil dat iemand video's onder jouw naam kan posten).

En als jij als hostings bedrijf iemand een eigen domein geeft + een adminpanel op dat domein, dan moet je daar weer een apart certificaat voor hebben (of alles op 1 domein draaien).

Kortom, een enorme storm in een vingerhoedje water daar bij het CERN, ik snap niet dat ze met goed fatsoen zoiets naar buiten durven brengen. Het is bijna net zo idioot als proberen de 'hyperlink' te patenteren vandaag.

Door Little Penguin, woensdag 12 september 2007 19:03

Score: 0
Nee, dat is de server hardware niet. Als voorbeeld tweakers.net. We zouden alles (plaatjes, javascript, css, alle html, rss feeds) allemaal via https moeten sturen, ook grote downloads van files, want bij elke http request op *.tweakers.net zal het tweakers.net cookie door de browser meegestuurd worden.
Volgens mij kun je externe plaatjes, css, javascript en RSS feeds gewoon via een normale verbinding laten lopen - voor al die zaken is geen cookie noodzakelijk.

Alleen de normale inlog-pagina + eventueel aangepaste CSS zul je via een ssl verbinding moeten laten lopen.

Verder is er tegenwoordig ook speciale hardware waarmee je de versleuteling kunt uitvoeren, waardoor dat je normale servers niet extra belast worden.

Overigens is het stelen van een cookie volgens mij alleen een issue voor de wifi-verbinding bij mensen thuis, alle andere verbindingen gaan via een praktisch niet af te luisteren draadje - als je de tussenliggende schakels niet kan/wil vertrouwen dan kun je het gehele internet wel opdoeken...

Door Yoeri, woensdag 12 september 2007 19:06

Score: 1
Het is niet noodzakelijk, maar dat weet je browser niet. Elke browser zal dan ook bij elk verzoek naar *.tweakers.net (ook bij verzoeken voor plaatjes, css, ...) het bijhorende cookie meesturen, en daar gaat je veiligheid...

[Reactie gewijzigd door Yoeri op woensdag 12 september 2007 19:06]

Door crisp, woensdag 12 september 2007 19:37

Score: 2
Dat is natuurlijk af te vangen door een ander domein te gebruiken voor je static content waarvoor geen authenticatie noodzakelijk is.

Wat een veel groter probleem is is dat browsers dan weer beginnen te mekkeren over 'mixed content'; dat probleem heb je met je banners en Adsense trouwens ook.

Door Little Penguin, woensdag 12 september 2007 19:55

Score: 0
Met een secure cookie kun je volgens mij voorkomen dat de cookie die gezet is vanaf een HTTPS-sessie over een niet beveiligde verbinding verstuurd wordt - dus dat mag geen probleem zijn.

Wat je dan natuurlijk wel kan krijgen is het probleem dat crisp hieronder beschrijft wanneer je voor een splitsing kiest tussen html en non-html (dynamisch en non-dynamische) content.

Overigens heeft Kees hierboven ook wel gelijk dat het een storm in een glas water is - het overgrote deel van het internet verkeer is in de praktijk niet af te luisteren...

Door arjankoole, woensdag 12 september 2007 20:46

Score: 2
Volgens mij kun je externe plaatjes, css, javascript en RSS feeds gewoon via een normale verbinding laten lopen - voor al die zaken is geen cookie noodzakelijk.
IE begint volgens mij dan gelijk te piepen over 'mixed content' en adviseert in de laatste versies zelfs om de site niet meer te bezoeken.
Verder is er tegenwoordig ook speciale hardware waarmee je de versleuteling kunt uitvoeren, waardoor dat je normale servers niet extra belast worden.
Heb je enig idee hoe duur dergelijke apperatuur is? Als ik alleen maar kijk naar relatief eenvoudige loadbalancers van Cisco, dan is de SSL terminating / offloading variant al snel 2x zo duur. Dat betekend dus dat je 4x zo veel geld uit mag geven (want je wilt natuurlijk wel redundante loadbalancers).

de meeste sites hebben echt niet een dusdanig groot budget dat dat haalbaar is. Zelfs t.net niet denk ik. (alhoewel ik niet de t.net budget begroting kan kijken natuurlijk)

Ik werk bij een toko waar we behoorlijk specialistische hosting doen, en de enkele keer dat een klant er om vraagt haakt ie af als ie hoort wat de kosten zijn.

[Reactie gewijzigd door arjankoole op woensdag 12 september 2007 20:47]

Door Bitage, woensdag 12 september 2007 18:41

Score: 0
Als bedrijf is het zoiezo niet echt geoorloofd om zulke belangrijke informatie in cookies te gooien, daar kun je gewoon de serverside oplossing $_SESSION voor gebruiken (in PHP dan). Desnoods, als je dat echt zou willen om je gebruikers aan de hand van hun IP te kunnen identificeren, is zelfs een DB-oplossing nog beter.

Door Yoeri, woensdag 12 september 2007 18:43

Score: 2
En wat denk je dat door $_SESSION gebruikt wordt? ;)

Juist ja, het Sessie-id wordt inderdaad op de server bijgehouden en gekoppeld aan de correcte login nadat de correcte logingegevens verstrekt zijn. Als jij vervolgens naar een andere pagina doorklikt, ruikt die server echter ècht niet zomaar dat jij weer diezelfde gozer bent hoor, maar bepaalt hij dat door het Sessie-id (dat, juist ja, niet-geëncrypteerd) doorgestuurd wordt samen met het request voor de pagina :)

Door chaos.be, woensdag 12 september 2007 19:31

Score: 0
Sessies worden vooral opgeslagen in cookies. Maar in het geval dat de gebruiker geen cookies aanvaard, kan het sessie-id opgeslagen worden in query's of form-data.

Niet dat dit een grotere beveiliging is hoor. Wanneer iemand jouw cookie onderschept, of een query met een sessie-id in, heeft deze persoon steeds jouw sessie te pakken.

Door tuxdapinguin, woensdag 12 september 2007 19:32

Score: 0
Nu ben ik geen beveiligings expert maar als je nou bijvoorbeeld je wachtwoord laat opslaan als md5sum dan heeft de hacker er toch niets aan?

Door Little Penguin, woensdag 12 september 2007 20:14

Score: 0
Dit bericht gaat niet over het wel/niet opslaan van een wachtwoord (waarbij het opslaan van een wachtwoord als plain-text ook al dom is overigens; MD5 of SHA hash is dan vele malen beter), maar om het feit dat de inhoud van een sessie-cookie misbruikt kan worden voor het spoofen van de afzender.

De kans dat je zo'n cookie te pakken krijgt is echter niet zo groot, tenzij dat er tussen jouw client en de server een gehackte machine zit of je gebruik maakt van een onbeveiligde wifi-verbinding.

Nu is het erg dom om een onbeveiligde WiFi verbinding te gebruiken en als je dat wel doet ligt er al gauw meer op straat dan alleen een sessie-cookie van t.net, gmail e.d.

Voor wat betreft een gehackte server, als een server bij jouw ISP, de backbone (AMS-IX,LINX of anders IX) of de hoster gehackt is dan is er ook meer aan de hand en moet er onverwijld actie worden ondernomen.

Door arjankoole, woensdag 12 september 2007 20:51

Score: 0
De kans dat je zo'n cookie te pakken krijgt is echter niet zo groot, tenzij dat er tussen jouw client en de server een gehackte machine zit of je gebruik maakt van een onbeveiligde wifi-verbinding.
Ik ben het helemaal met je verhaal eens, maar ik heb nog 1 kleine aanvulling: wat dacht dat van het feit dat het door simpelweg het volume haast niet haalbaar is om het juiste setje pakketjes te sniffen waardoor je zo'n cookie te pakken krijgt? Zo'n cookie is misschien 128 bytes lang, dus dat zit heerlijk encapsulated in een 1500 bytes packet. Knappe jongen die apperatuur heeft om de juiste packets eruit te sniffen.

(uitzondering is natuurlijk als ie in je eigen netwerk zit, net voor je uplink, daar gaat zo weinig verkeer overheen dat het een peuleschil is, maar dan moet je wel tussen client en uplink kunnen zitten - ook niet makkelijk zonder dat het opvalt).

Door moto-moi, donderdag 13 september 2007 01:20

Score: 2
Een sniffer kan dat beetje verkeer wel efficient verstouwen hoor, je hebt tenslotte niet elk stukje data nodig wat over de lijn gaat ;)

[Reactie gewijzigd door moto-moi op donderdag 13 september 2007 01:20]

Door arjankoole, vrijdag 14 september 2007 00:16

Score: 0
Een sniffer kan dat beetje verkeer wel efficient verstouwen hoor, je hebt tenslotte niet elk stukje data nodig wat over de lijn gaat
probeer jij eens een sniffer te draaien op de backbone uplink van een grote ISP?

ik durf je te wedden dat je machine een zeer pijnlijke, rokende dood sterft.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 21:34
Vorige 17:56
VNU Media logo Powered by True

© 1998 - 2009 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van: