[SSL] Veiligheidsonderzoek.

[BierPul]

Voor mn werk hebben we een site draaien waarop mensen hun gegevens kunnen bekijken en eventueel kunnen wijzigen.

Dat verloopt allemaal via SSL dus dat zit allemaal wel ok.

Maar nu vraag ik me af of het wel helemaal waterdicht is.

Bijvoorbeeld.

Ik open de website via een frame waar ik een frame van een pixel tussengooi.

In dat frame draai ik een stukkie javascript wat de source uit de onderliggende pagina haalt (iets van een for each op getEelementByID) dat doorstuurd aan zich zelf (document.loction.href(bla.php?value=de waarde). en vervolgens opslaat in de database of wat dan ook.

Dan is het helemaal niet zo lastig dus om bijvoorbeeld die gegevens eruit te regexen

Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site

[ Voor 4% gewijzigd door BierPul op 06-09-2003 14:04 ]

[crisp]

Javascript kan niet cross-domain gebruikt worden; het standaard javascript security model verbied dat.
Wat natuurlijk wel mogelijk is, is dat je met een ander soort tool de pagina's binnenhaalt. SSL zegt alleen iets over de veiligheid van de verbinding, eenmaal op de client is alles natuurlijk gewoon zichtbaar en dus ook bruikbaar.
Als ik jou was zou ik eea gewoon beveiligen met een login en daaraan rechten op bepaalde gegevens hangen, dan weet je zeker dat derden er niet bij kunnen komen.

[BierPul]

Dat is al het geval zelfs de formulieren checken vanaf welke plaats de submit komt.

Daar heb ik een lijst van "trusted domains" die de post mogen uitvoeren anderen worden simpelweg geblocked

Ik neem aan dat je bedoeld dat er een tool vanaf een ander domein tussenkomt

Of is dit zelfs na te bootsen (Dan kan het wel gevaarlijk zijn )

Ben blij dat mn filesofie niet opgaat

Wat natuurlijk wel mogelijk is, is dat je met een ander soort tool de pagina's binnenhaalt. SSL zegt alleen iets over de veiligheid van de verbinding, eenmaal op de client is alles natuurlijk gewoon zichtbaar en dus ook bruikbaar.

Maar dit geintje gaat natuurlijk in elk geval op ook al gebruik je 6 wachtwoord beveiligings lagen

[ Voor 14% gewijzigd door BierPul op 06-09-2003 14:20 ]

[Verwijderd]

SSL is bij mijn weten maar 128 bit dus voor een fanaat of een overheid valt dat met een supercomputer of distributed computing zo te kraken.

In de security wereld is het een ongeschreven regel dat jij op verbindingen die veilig moeten zijn, alle active content deactiveerd. Javascript kan je idd inteugelen met het verbieden van cross-domainscripting, maar soms laten veiligheidsgaten in de browser zulke dingen toch toe.

Het is dus geen goed idee om die SSL verbinding te gaan benutten met IE.

Maar er loert een nog veel groter gevaar. ActiveX en Javaapplets zijn ook active content en die kan nog veel meer. Het is meestal voor jouw soort sites niet nodig dus disable dat vooral.

Dit probleem speelt zich ook af bij anonymous proxies. Op de site van JAP zeiden ze ook al dat je active content moet deactiveren, en dat bijv. een trojan op je de die pagina's ook gewoon kan lezen.

Als bijv. de AIVD bewijs tegen je wil verzamelen en ze zien dat al je pakketen gencrypt zijn, dan kunnen ze gewoon een site openen met voor jou interessante content (bijv. criminele zaken, terrorisme, spionage). Als je niet oplet kunnen ze dmv active content gewoon uitzoeken dat jij het bent.

[Spider.007]

BierPul schreef op 06 September 2003 @ 14:00:
Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site

Grappig; hoe wilde je het ooit 'veilig' op de site tonen? Gewoon ge encrypt erop zetten en de users het uit hun hoofd laten decrypten?

[Verwijderd]

Het voordeel van SSL is dat de gevensstroom die plaatsvind tussen de client en jouw server niet gesniffed kan worden en niemand dus ooit zal zien wat er heen en weer gaat. Dit wil niet zeggen dat de content op je pagina beveiligd is, hiervoor zal je een login systeem moeten bedenken (had je geloof ik al). Het mooie is dat er nooit iemand zal zijn die de gebruikers naam en wachtwoord van de client zal kunnen afvangen, dus zal er ook niemand zijn die een javascript(proxy) kan maken wat met die login gegevens inlogt en dan jou een gefilterd (geregex'ed) document opstuurt.

[BierPul]

Spider.007 schreef op 06 September 2003 @ 14:30:
[...]

Grappig; hoe wilde je het ooit 'veilig' op de site tonen? Gewoon ge encrypt erop zetten en de users het uit hun hoofd laten decrypten?

Jij bent scherp net zoals altijd

uuhhm maar wat ik bedoel is anders denk ik .

Mensen kunnen bij ons op de site zien met welke gegevens ze lid zijn .

Naam : Melp
Straat : melp
Banknummer : melp

Met deze gegevens kan je in principe een incasso doen op een rekening , officieel niet maar er zijn genoeg bureaus die dat oogluikend toestaan

Zoals op mijn mannier beschreven kan je aardig wat gegevens opslaan en een leuk incasso documentje maken

Maar aangezien dat niet kan heb ik geen probleem om over na te denken

[ Voor 48% gewijzigd door BierPul op 06-09-2003 15:08 ]

[Grijze Vos]

BierPul schreef op 06 september 2003 @ 15:06:
[...]
Met deze gegevens kan je in principe een incasso doen op een rekening , officieel niet maar er zijn genoeg bureaus die dat oogluikend toestaan

En die incasso kan evengoed zo weer ongedaan gemaakt worden. Dan moet je echt al in 1x alles incasseren, en naar het buitenland toegaan, wil je zoiets flikken.

En dat soort dingen gebeuren nou niet echt ontzettend vaak...

[martijn_brinkers]

Vaak wordt aangenomen dat als een verbinding via SSL gaat het dus wel veilig zal zijn. SSL zorgt (in het algemeen) voor 2 zaken nl encyption van data en authentication (kan zowel authetication zijn van client als server hoewel client authentication meestal niet gebruikt wordt). Als er een SSL verbinding tot stand is gebracht zit het vaal wel goed met de encryption tussen client en server. Waar echter voor op moet worden gepast is het zgn 'man in the middle attack'. Stel client C wil een velige verbinding opzetten met server S. Dus:

C <-> S

achter C zijn DNS is gehacked en ipv dat hij een verbinding legt met S legt hij een verbinding met M

C <-> M <-> S

M doet zich verder voor als transparant proxy waardoor C en S niet merken dat M ertussen zit. Op deze manier is alle data tussen C en M en M en S encrypted maar M kan echter wel alles lezen / aanpassen. Een inlog scherm op zich is dus niet voldoende om iemand zn gebruikersnaam en wachtwoord te beschermen.

Het mooie is dat er nooit iemand zal zijn die de gebruikers naam en wachtwoord van de client zal kunnen afvangen

Om dit 'man in the middle attack' probleem op te lossen zal je dus gebruik moeten maken van Authetication. Dus van het certificaat in combinatie met trusted roots. Degene die verbinding legt met de server is het aan te raden om ook daadwerkelijk op het slotje (rechtsonder IE) te drukken om zo te controleren of het certificaat wel echt behoord aan de site waarmee je verbinding wil leggen.

PS. het geheel zit wat ingewikkelder in elkaar omdat in een certificaat ook nog vermeld staat op welk domein het certificaat is uitgegeven om de kans op een 'man in the middle attack' kleiner te maken.

SSL is bij mijn weten maar 128 bit dus voor een fanaat of een overheid valt dat met een supercomputer of distributed computing zo te kraken

Dit soort dingen worden te pas en te onpas geroepen. Kan je dit ook staven met verwijzingen naar artikelen?

[ACM]

Verwijderd schreef op 06 September 2003 @ 14:23:
SSL is bij mijn weten maar 128 bit dus voor een fanaat of een overheid valt dat met een supercomputer of distributed computing zo te kraken.

We hebben het niet over een simpel vast gegeven wat interessant is om te kraken, maar om een hele stroom van data...

128bits is niet voor niets in sommige landen verboden om te gebruiken of te exporteren, het is te lastig te kraken. Ook voor overheden is het lastig en als je een huis-tuin-en-keuken bedrijfje hebt, dan boeit die factor geen ruk, de kans dat jij ergens van verdacht wordt is vrij klein lijkt me dan.
In zo'n geval biedt SSL wel degelijk dat beetje meer dat je goed kan gebruiken.

Wat echter niet zegt dat SSL het enige is wat het gebruik veilig maakt, meestal alleen de verbinding en soms de authenticatie.

In de security wereld is het een ongeschreven regel dat jij op verbindingen die veilig moeten zijn, alle active content deactiveerd. Javascript kan je idd inteugelen met het verbieden van cross-domainscripting, maar soms laten veiligheidsgaten in de browser zulke dingen toch toe.

Javascript kan je helemaal niet inteugelen, vanaf de server gezien en crossdomainscripting kan je al helemaal niet verbieden lijkt me zo... Je biedt _zelf_ bepaalde content aan op die server. Ik mag toch hopen dat je daar op zijn minst van aan durft te nemen dat die betrouwbaar is (niet bugvrij, maar wel enigszins betrouwbaar), als je dat al niet kan doen kan je maar beter geen webapplicaties aanbieden

Het is dus geen goed idee om die SSL verbinding te gaan benutten met IE.

Want?
't Voegt toch veiligheid toe? 't Maakt het niet ineens onkraakbaar, maar het voegt wel degelijk wat toe!.

Maar er loert een nog veel groter gevaar. ActiveX en Javaapplets zijn ook active content en die kan nog veel meer. Het is meestal voor jouw soort sites niet nodig dus disable dat vooral.

Sure... Heb je het nu over de client of de server? Als de server actieve clientside content nodig heeft, bijvoorbeeld om de interface te vereenvoudigen dan is er geen enkele reden om dat niet te doen, lijkt mij...

Dit probleem speelt zich ook af bij anonymous proxies. Op de site van JAP zeiden ze ook al dat je active content moet deactiveren, en dat bijv. een trojan op je de die pagina's ook gewoon kan lezen.

Euh... Ik zou toch proberen te vermijden om een willekeurige anonieme proxy te gebruiken als je gaat lopen SSL-en, maar zelfs dan is het nog niet zomaar te kraken hoor.
En een trojan is altijd een gevaar, ongeacht of je wel of geen actieve content hebt en dergelijke.

Als bijv. de AIVD bewijs tegen je wil verzamelen en ze zien dat al je pakketen gencrypt zijn, dan kunnen ze gewoon een site openen met voor jou interessante content (bijv. criminele zaken, terrorisme, spionage). Als je niet oplet kunnen ze dmv active content gewoon uitzoeken dat jij het bent.

Waar HEB je het nou eigenlijk over? De AIVD gaat toch niet jouw server kraken om de content daar te wijzigen zodat je te identificeren bent?
En actieve content kan heus niet zoveel als je suggereert...

Ik zou graag wat uitgebreidere onderbouwing zien van je statements, maar ik heb het idee dat je gewoon een rijtje angstwekkende gedachtes oplepelt die eigenlijk helemaal niet relevant zijn voor bovenstaand probleem

[Verwijderd]

We hebben het niet over een simpel vast gegeven wat interessant is om te kraken, maar om een hele stroom van data...

Daar heb je gelijk in maar het lijkt me dat, mocht het onwaarschijnlijke geval zich voordoen dat iemand een bepaalde transactie wil kunnen inzien, (bijv. een crimineel die weet dat rond een bepaalde tijd er bankgegevens over jouw bedrijf heen en weer gaan) die persoon wel continue snifft en alles opslaat voor later onderzoek.

128bits is niet voor niets in sommige landen verboden om te gebruiken of te exporteren, het is te lastig te kraken. Ook voor overheden is het lastig en als je een huis-tuin-en-keuken bedrijfje hebt, dan boeit die factor geen ruk, de kans dat jij ergens van verdacht wordt is vrij klein lijkt me dan.
In zo'n geval biedt SSL wel degelijk dat beetje meer dat je goed kan gebruiken.

Je doet net of ik beweer dat 128 bits totaal geen veiligheid biedt. Natuurlijk is het veiliger dan niks maar het gaat er om dat mocht iemand het echt willen, het praktisch onmogelijk word om de encryptie te kraken. 128 bits is dan niet echt extreem sterk, begrijp je hopelijk wel.

Wat echter niet zegt dat SSL het enige is wat het gebruik veilig maakt, meestal alleen de verbinding en soms de authenticatie.

Dat beweer ik ook niet.

Javascript kan je helemaal niet inteugelen, vanaf de server gezien en crossdomainscripting kan je al helemaal niet verbieden lijkt me zo...

Ik heb het over de client en niet over de server. De financiele gegevens staan niet open en bloot op jouw server (als het goed is). Bovendien draaien servers helemaal geen JavaScript.

Mooie browser heb jij dan, als je dat niet kunt verbieden ! Kijk voor de grap maar eens bij je veiligheidszones in IE en security settings in Mozilla. Ik zie daar toch echt opties om javascript veiligheidsrisico's te beheersen.

Zoals een ander al zei, staat cross domain scripting standaard AF bij iedere fatsoenlijke browser. En jij beweert dat je dat niet kan verbieden ???

quote: Het is dus geen goed idee om die SSL verbinding te gaan benutten met IE.

Want?

Zucht... Zoal ik al heb gezegd, omdat dmv veiligheidsgaten in de browser zaken als crossdomain scripting wél worden toegestaan. IE heeft een reputatie op het gebied van security bugs, en zeker mbt crossdomain scripting (denk aan de IFRAME-bug).

't Voegt toch veiligheid toe? 't Maakt het niet ineens onkraakbaar, maar het voegt wel degelijk wat toe!.

Ja ? Ontken ik dat soms ??

quote: Maar er loert een nog veel groter gevaar. ActiveX en Javaapplets zijn ook active content en die kan nog veel meer. Het is meestal voor jouw soort sites niet nodig dus disable dat vooral.


Sure... Heb je het nu over de client of de server?

. Draait jouw server ActiveX en Javaapplets ? Wow dat wil ik wel eens zien !

Als de server actieve clientside content nodig heeft, bijvoorbeeld om de interface te vereenvoudigen dan is er geen enkele reden om dat niet te doen, lijkt mij...

Als de server (...) ? De server heeft daar toch niks mee te maken ? De active content is per defenitie clientside en bied enkel een (zoals jij al zegt: gebruiksvriendelijke) interface naar de PHP/PL/CGI/JSP/ etc scripts die aan de serverkant draaien.
Maar "nodig" is het natuurlijk theoretisch nooit.

Als er nooit word ingebroken op jouw server en je weet zeker dat je klanten zeer veilige security policies hebben op hun browser dan is het niet gebruiken van active content idd onzin. Maar dat kun je natuurlijk nooit garanderen...

Het is dus de afweging van de topicstarter of hij dit theoretische risico voor lief neemt. Ik ben het in zoverre met je eens dat dit gevaar minimaal is, maar de topicstarten heeft zélf dit topic geopent om zijn zorgen rondom dit probleem te uiten.

quote: Dit probleem speelt zich ook af bij anonymous proxies. Op de site van JAP zeiden ze ook al dat je active content moet deactiveren, en dat bijv. een trojan op je de die pagina's ook gewoon kan lezen.


Euh... Ik zou toch proberen te vermijden om een willekeurige anonieme proxy te gebruiken als je gaat lopen SSL-en, maar zelfs dan is het nog niet zomaar te kraken hoor.

JAP is niet willekeurig. Het is van een Duitse Uni, en er word duidelijk bewezen dat zij je niet kunnen achterhalen op de site. Het programma is open-source en bestaat uit geavanceerdere technieken dan het door jouw geschetste gebruiken van simpele proxies.

Ik zeg ook niet dat de topicstarter moet "gaan zitten SSL'en" via een proxy. Ik noemde slechts een geval waarbij confidentiele gegevens ook in gevaar worden gebracht door active content. Dat heeft voor de rest niks met het probleem te maken.

En een trojan is altijd een gevaar, ongeacht of je wel of geen actieve content hebt en dergelijke.

Ja, dat is logisch natuurlijk. Ontken ik dat soms ? Nee, sterker nog ik noemde dat helemaal niet in één zucht met active content ! Zoals duidelijk zichtbaar, was dit een zijdelingse opmerking aangaande de veiligheid vertrouwelijke gegevens bij het gebruik van anonieme proxies.

quote:Als bijv. de AIVD bewijs tegen je wil verzamelen en ze zien dat al je pakketen gencrypt zijn, dan kunnen ze gewoon een site openen met voor jou interessante content (bijv. criminele zaken, terrorisme, spionage). Als je niet oplet kunnen ze dmv active content gewoon uitzoeken dat jij het bent.


Waar HEB je het nou eigenlijk over? De AIVD gaat toch niet jouw server kraken om de content daar te wijzigen zodat je te identificeren bent?

Als bijv. de AIVD bewijs tegen je wil verzamelen en ze zien dat al je pakketen gencrypt zijn, dan kunnen ze gewoon een site openen met voor jou interessante content (bijv. criminele zaken, terrorisme, spionage)

Lezen is schijnbaar heel moeilijk voor jou....

BTW: De AIVD laat het echt niet om een server te kraken als dat nodig is hoor. Dat zou mooi zijn voor de terroristen van deze wereld . Alleen voor een bedrijfssituatie is dat niet relevant, aangezien de AIVD geen misbruik gaat maken van de financiele gegevens van je klanten. En als ze dat wel zouden willen kunnen ze dat natuurlijk al op 1001 manieren doen.

Dit stukje tekst ging zoals overduidelijk over anonimiserende proxies.

En actieve content kan heus niet zoveel als je suggereert...

Be amazed. Ontken het dan als je wilt: een ActiveX object of JavaApplet kan écht wel jouw werkelijke ip achterhalen hoor. Het lijkt me sterk dat je dat niet snapt...

Mogelijk Flash zelfs ook, alleen dat kan ik niet zeggen.

[ Voor 3% gewijzigd door Verwijderd op 07-09-2003 20:15 . Reden: typo's, quote niet goed gelezen ]

[mbravenboer]

Cybarite: Het lijkt me sterk dat je dat niet snapt...

Het lijkt mij sterk dat je al veel in nieuwsgroepen en fora hebt gezeten, anders heb je een erg druk bestaan als je altijd op deze manier discussieert.

Het heeft geen nut om een beetje te gaan discussieren wie hier nu het slimste is. Als je opmerkingen bestreden worden, kan je daar gewoon inhoudelijk op ingaan zonder stompzinnig welles-niets-jij-bent-dom spelletje te gaan spelen.

Verder is het wel handig om even te kijken tegen wie je uitvalt voor dat je begint aan zo'n 'jij bent dom en ik ben slim' post .

[ACM]

Verwijderd schreef op 07 September 2003 @ 20:09:
Daar heb je gelijk in maar het lijkt me dat, mocht het onwaarschijnlijke geval zich voordoen dat iemand een bepaalde transactie wil kunnen inzien, (bijv. een crimineel die weet dat rond een bepaalde tijd er bankgegevens over jouw bedrijf heen en weer gaan) die persoon wel continue snifft en alles opslaat voor later onderzoek.

Zoals je zegt, een onwaarschijnlijk geval.
Nog afgezien van het feit dat je nooit precies kunt zeggen welk deel van de datastroom relevant was en je dus de complete stroom moet kraken trouwens.

Maar wat ik al probeerde te vertellen, we kijken hier vanaf de kant van de site-aanbieder, niet vanaf de gebruiker.

Je doet net of ik beweer dat 128 bits totaal geen veiligheid biedt. Natuurlijk is het veiliger dan niks maar het gaat er om dat mocht iemand het echt willen, het praktisch onmogelijk word om de encryptie te kraken. 128 bits is dan niet echt extreem sterk, begrijp je hopelijk wel.

De encryptie van het kanaal is idd 128bits, de gebruikte keys zijn iets groter. Anyway, op het moment dat de aanvaller echt wil is er idd een kansje dat het te kraken is. De kans is echter wat groter dat ie eerst op zoek gaat naar andere, simpelere gaten...

Ik heb het over de client en niet over de server. De financiele gegevens staan niet open en bloot op jouw server (als het goed is). Bovendien draaien servers helemaal geen JavaScript.

Maar dit topic gaat wel over de serverside, uiteraard met het organisatorische aspect erbij dat je de gebruikers goed moet informeren.
Maar ik betwijfel het of de serverside een browser kan dwingen wat voor setting aan te nemen dan ook, hooguit dat ie wat stricter met content werkt zodra er SSL gebruikt wordt.

Zoals een ander al zei, staat cross domain scripting standaard AF bij iedere fatsoenlijke browser. En jij beweert dat je dat niet kan verbieden ???

Op de server niet nee...

Zucht... Zoal ik al heb gezegd, omdat dmv veiligheidsgaten in de browser zaken als crossdomain scripting wél worden toegestaan. IE heeft een reputatie op het gebied van security bugs, en zeker mbt crossdomain scripting (denk aan de IFRAME-bug).

Maar wat is het hele verhaal met de serverside hierin? Je moet dus je gebruiker dwingen de javascript, java etc allemaal uit te zetten? Fijne gebruikservaring heeft het internet dan, allerlei pagina's die op javascript leunen die het ineens niet meer doen.
Als IE zo'n slechte reputatie heeft, verbied daar het gebruik dan van op je eigen site...

. Draait jouw server ActiveX en Javaapplets ? Wow dat wil ik wel eens zien !

Serverside... En met een MS server weet je het maar nooit wat ie aan activex enzo op de server uitvoert

Als de server (...) ? De server heeft daar toch niks mee te maken ? De active content is per defenitie clientside en bied enkel een (zoals jij al zegt: gebruiksvriendelijke) interface naar de PHP/PL/CGI/JSP/ etc scripts die aan de serverkant draaien.

De server heeft alles met ons verhaal te maken.
Zie in de topicstart dit stukje:

Voor mn werk hebben we een site draaien waarop mensen hun gegevens kunnen bekijken en eventueel kunnen wijzigen.

Het is dus de afweging van de topicstarter of hij dit theoretische risico voor lief neemt. Ik ben het in zoverre met je eens dat dit gevaar minimaal is, maar de topicstarten heeft zélf dit topic geopent om zijn zorgen rondom dit probleem te uiten.

Ja, maar hij heeft het gestart uit het "wij draaien een site, doen we dat zo goed?"-oogpunt. NIET uit het "hoe kunnen wij zo veilig mogelijk internetten?"-oogpunt.

JAP is niet willekeurig. Het is van een Duitse Uni, en er word duidelijk bewezen dat zij je niet kunnen achterhalen op de site. Het programma is open-source en bestaat uit geavanceerdere technieken dan het door jouw geschetste gebruiken van simpele proxies.

Waar heb je het over?

Lezen is schijnbaar heel moeilijk voor jou....

Voor jou nog erger denk ik...

BTW: De AIVD laat het echt niet om een server te kraken als dat nodig is hoor. Dat zou mooi zijn voor de terroristen van deze wereld . Alleen voor een bedrijfssituatie is dat niet relevant, aangezien de AIVD geen misbruik gaat maken van de financiele gegevens van je klanten. En als ze dat wel zouden willen kunnen ze dat natuurlijk al op 1001 manieren doen.

Ik snap sowieso niet waarom je uberhaupt de AIVD erbij moest halen, de uitstap naar de policies bij de gebruiker en het verzuimen van kijken uit het content-aanbieder-oogpunt is al erg genoeg...

Dit stukje tekst ging zoals overduidelijk over anonimiserende proxies.

Ja en het doel ontgaat mij iig nog steeds.

Be amazed. Ontken het dan als je wilt: een ActiveX object of JavaApplet kan écht wel jouw werkelijke ip achterhalen hoor. Het lijkt me sterk dat je dat niet snapt...

Euh? De activex en javaapplets kunnen mijn ip achterhalen? So what? Is _dat_ tegenwoordig al gevaarlijk? Dan kan je maar beter niet meer gaan internetten gok ik zo
Maar dan nog, we hebben het nog steeds over de serverside. Er is niet of nauwelijks te garanderen dat je gebruikers geen gekke dingen met hun PC doen... En je kan ze op zo'n moment ook niet de toegang ontzeggen, want je kan niet op hun PC kijken.

[Verwijderd]

Ik zeg niet dat ik slimmer ben ofzo.

Echter ik word aangevallen door iemand dmv ongefundeerde blaat.

Moet ik dan soms de helft van zijn beweringen laten voor wat ze zijn ?

Ik heb een hekel aan mensen die niet nuttig bijdragen aan een discussie maar die een ander op ieder detail proberen af te troeven.

Daar begon ACM mee, ik niet.

Het heeft geen nut om een beetje te gaan discussieren wie hier nu het slimste is. Als je opmerkingen bestreden worden, kan je daar gewoon inhoudelijk op ingaan zonder stompzinnig welles-niets-jij-bent-dom spelletje te gaan spelen.

Dat is precies wat ik doe (het laatste dan ).

Idd als ik dat altijd zal doen, ook als het niet tegen mij gericht is, ben ik lang bezig .

Voor de rest heb ik niks tegen ACM, ik ken de man/vrouw voor de rest niet.

[elevator]

Verwijderd schreef op 07 September 2003 @ 20:09:
JAP is niet willekeurig. Het is van een Duitse Uni, en er word duidelijk bewezen dat zij je niet kunnen achterhalen op de site. Het programma is open-source en bestaat uit geavanceerdere technieken dan het door jouw geschetste gebruiken van simpele proxies.

Kuch: http://www.securityfocus.com/archive/1/334382

[Verwijderd]

Maar dit topic gaat wel over de serverside, uiteraard met het organisatorische aspect erbij dat je de gebruikers goed moet informeren.
Maar ik betwijfel het of de serverside een browser kan dwingen wat voor setting aan te nemen dan ook, hooguit dat ie wat stricter met content werkt zodra er SSL gebruikt wordt.

OK ik begrijp wel wat je punt is, maar je haalde er dingen bij die gewoon client-side zijn (zoals javascript). Het komt er op neer dat de veiligheid van iets zowel aan de client als aan de serverkant goed moet zijn.

Ik bedoelde dus niet dat de server afdwingt dat de gebruiker een goede veiligheidsinstelling krijgt, maar dat er in het algemeen het 'gevaar' is dat de client een slechte beveiliging heeft. Daar moet je dus op letten meende ik te zeggen.

quote: Zoals een ander al zei, staat cross domain scripting standaard AF bij iedere fatsoenlijke browser. En jij beweert dat je dat niet kan verbieden ???


Op de server niet nee...

Maar maakt dus niet uit , want daar heb ik en de topicstarter het helemaal niet over.

quote:. Draait jouw server ActiveX en Javaapplets ? Wow dat wil ik wel eens zien !


Serverside... En met een MS server weet je het maar nooit wat ie aan activex enzo op de server uitvoert

Ja de server kan het wel draaien maar ik wil maar zeggen dat de server het niet draait bij het puur funtioneren als webserver. En zelfs met een MS-Server zou hij dat ook niet moeten doen met ActiveX .

quote:Als de server (...) ? De server heeft daar toch niks mee te maken ? De active content is per defenitie clientside en bied enkel een (zoals jij al zegt: gebruiksvriendelijke) interface naar de PHP/PL/CGI/JSP/ etc scripts die aan de serverkant draaien.


De server heeft alles met ons verhaal te maken.
Zie in de topicstart dit stukje:

quote: Voor mn werk hebben we een site draaien waarop mensen hun gegevens kunnen bekijken en eventueel kunnen wijzigen.

Met 'daar niets mee te maken' heb ik het over active content, niet over het hele verhaal. En dat zijn site op een server draait is ook het hele verband met javascript (zie zijn vraag)...

quote:Het is dus de afweging van de topicstarter of hij dit theoretische risico voor lief neemt. Ik ben het in zoverre met je eens dat dit gevaar minimaal is, maar de topicstarten heeft zélf dit topic geopent om zijn zorgen rondom dit probleem te uiten.


Ja, maar hij heeft het gestart uit het "wij draaien een site, doen we dat zo goed?"-oogpunt. NIET uit het "hoe kunnen wij zo veilig mogelijk internetten?"-oogpunt.

Of hij het goed doet is dus nogmaals zijn eigen afweging. Ik maak echter alleen duidelijk dat het niet perfect is, zodat hij dat in ieder geval doorheeft bij zijn afweging. Ik maak toch niet de beslissingen voor anderen ?

quote:JAP is niet willekeurig. Het is van een Duitse Uni, en er word duidelijk bewezen dat zij je niet kunnen achterhalen op de site. Het programma is open-source en bestaat uit geavanceerdere technieken dan het door jouw geschetste gebruiken van simpele proxies.


Waar heb je het over?

Over anonimiserende proxies, die ook onveilig worden door active content. Ik zei al dat dit slechts zijdeling met het onderwerp te maken had, alleen jij ging er op in door te beweren dat ik zei dat de topicstarten maar moest gaan SSL'en door een proxy, die je niet kent.

quote:Lezen is schijnbaar heel moeilijk voor jou....


Voor jou nog erger denk ik...

Geef dan maar eens aan wat ik fout lees .

quote:BTW: De AIVD laat het echt niet om een server te kraken als dat nodig is hoor. Dat zou mooi zijn voor de terroristen van deze wereld . Alleen voor een bedrijfssituatie is dat niet relevant, aangezien de AIVD geen misbruik gaat maken van de financiele gegevens van je klanten. En als ze dat wel zouden willen kunnen ze dat natuurlijk al op 1001 manieren doen.


Ik snap sowieso niet waarom je uberhaupt de AIVD erbij moest halen, de uitstap naar de policies bij de gebruiker en het verzuimen van kijken uit het content-aanbieder-oogpunt is al erg genoeg...

Die 'uitstap' is dus betrekkelijk, omdat de vraag van de topicstarter over onveilige javascripts gaat. De policies van de gebruiker zijn daarbij van groot belang, zeker bij het toelaten van cross-domain scripting. Bij een bedrijf gaat het immers om de klant, en niet alleen om de veiligheid van de gegevens van het bedrijf zelf.

Het oogpunt van de content aanbieder is nu niet het punt. Alhoewel ik weldegelijk de zaak vanuit dat oogpunt heb belicht, door te noemen dat er altijd een theoretisch gevaar bestaat voor inbraak op de server.

De AIVD haal ik er bij om een reeel scenario te schetsen waarin active content de gegevens van de gebruiker van een anonimiserende proxy kan blootleggen, ondanks SSL.

quote: Dit stukje tekst ging zoals overduidelijk over anonimiserende proxies.

Ja en het doel ontgaat mij iig nog steeds.

Het doel is, zoals ik intussen al 10x heb gezegd, de topicstarter te wijzen op een ander geval waarin active content anonimiserende proxies privacyonveilig maakt. Dit om te tonen dat encryptie van data tijdens communicatie altijd zwak is aan het eind waar de gedecrypte data op het scherm word getoond, en ook nog eens gemakkelijk kan worden achterhaalt en verzonden dmv active content.

quote: Be amazed. Ontken het dan als je wilt: een ActiveX object of JavaApplet kan écht wel jouw werkelijke ip achterhalen hoor. Het lijkt me sterk dat je dat niet snapt...


Euh? De activex en javaapplets kunnen mijn ip achterhalen? So what? Is _dat_ tegenwoordig al gevaarlijk? Dan kan je maar beter niet meer gaan internetten gok ik zo
Maar dan nog, we hebben het nog steeds over de serverside. Er is niet of nauwelijks te garanderen dat je gebruikers geen gekke dingen met hun PC doen... En je kan ze op zo'n moment ook niet de toegang ontzeggen, want je kan niet op hun PC kijken.

Als een site, volledig gericht op verboden informatie, kan aantonen dat jouw ip er is geweest, heb je niets aan het feit dat de verboden data geencrypt verstuurt is. Of je moet de rechter wijs kunnen maken dat je 1000x een niet verboden logoplaatje hebt opgevraagd ...

Je hebt gelijk dat je nooit kan weten wat een gebruiker allemaal doet terwijl ie op de site zit, maar het gaat er om dat je als bedrijfseigenaar later niet geconfronteerd wilt worden met boze gebruikers die door een zwakte aan de client-side financieel gedupeerd is door een bende oplichters.

Dat gevaar bestaat nou eenmaal altijd, en ik probeer dus de topicstarter duidelijk te maken dat het gaat om keuzes maken en dat de perfecte oplossing niet bestaat (dus SSL is niet heilig ---> en ja dat beweer jij natuurlijk ook niet).

Ontopic: (4 regels )

Topicstarter: je kunt dus je klanten proberen aan te sporen zo veilig mogelijk te werken, en zelf het gevaar beperken. Maar aangezien dat dus niet afdoende is, kun je mischien in je algemene voorwaarden voor toegang tot de site zetten dat jullie niet aansprakelijk zijn voor schade die is aangericht door een veiligheidszwakte bij de eindgebruiker ?

Edit:

Kuch: http://www.securityfocus.com/archive/1/334382

Dat wist ik allang en is ondertussen al tijden lang verwijderd. Aangezien het open-source is kan je dit zo achterhalen als je paranoide bent.

Tja we leven in een maatschappij hé ? Het was best wel naai die backdoor ja maar als de rechter je dat oplegt en je verplicht dat je je mond er over moet houden wat wil je dan nog doen....

[ Voor 4% gewijzigd door Verwijderd op 07-09-2003 21:37 ]

[ACM]

Voor ik in een welles-nietes verval, eerst een on-topic reactie

BierPul schreef op 06 September 2003 @ 14:00:
Maar nu vraag ik me af of het wel helemaal waterdicht is.

Het zal nooit helemaal waterdicht worden, maar SSL zorgt iig voor een veilige verbinding.

Ik open de website via een frame waar ik een frame van een pixel tussengooi.

In dat frame draai ik een stukkie javascript wat de source uit de onderliggende pagina haalt (iets van een for each op getEelementByID) dat doorstuurd aan zich zelf (document.loction.href(bla.php?value=de waarde). en vervolgens opslaat in de database of wat dan ook.

Dan is het helemaal niet zo lastig dus om bijvoorbeeld die gegevens eruit te regexen

Als het goed is laten browsers dat dus niet toe

Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site

Als banken het aandurven, dan denk ik niet dat het een keus is tussen verstandig en onverstandig. Maar meer een keus, die als het nodig is, gaat tussen goed en niet goed genoeg
Als je je verbindingen via SSL hebt lopen en de gebruikers, met een zeer grote zekerheid, kunt identificeren en authenticeren. EN de gebruikers voor elke handeling geauthenticeerd en geindentificeerd zijn (en ook nog eens geautoriseerd natuurlijk), dan is het waarschijnlijk wel ok.

Mits er geen bugs in je software zitten natuurlijk

[elevator]

Verwijderd schreef op 07 September 2003 @ 21:29:
OK ik begrijp wel wat je punt is, maar je haalde er dingen bij die gewoon client-side zijn (zoals javascript). Het komt er op neer dat de veiligheid van iets zowel aan de client als aan de serverkant goed moet zijn.

Uiteraard moet zowel de client als de serverkant goed zijn, maar dat is niet de vraag die topicstarter had.

Als ik terug ga naar de basisvraag van topicstarter:

Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site

Dan is zijn vraag:
• Moet ik gegegevens tonen op een website als ik bang ben dat mensen ermee aan de haal gaan
• Heeft een beveiligde verbinding hier enig effect,

Het antwoord hierop is denk ik:
SSL heeft eigenlijk alleen als doel dat de informatie niet ergens terecht, of ergens vandaan komt, waar je niet wil dat het vandaan komt. Het voorkomt geen informatie diefstal. Als je zeker wil weten dat alleen je clients toegang hebben tot de data, zou je via client-certificaten kunnen werken - hiermee timmer je het geheel nog een beetje extra dicht omdat 'alleen' de url weten niet meer genoeg is

[over het verbieden van javascript ]
Maar maakt dus niet uit , want daar heb ik en de topicstarter het helemaal niet over.

TS' vraag is toch over de server kant, lijkt me? Hij vraagt hoe hij zijn gegevens kan beveiligen.

Dat wist ik allang en is ondertussen al tijden lang verwijderd. Aangezien het open-source is kan je dit zo achterhalen als je paranoide bent.

Als je dit dan wist - waarom verkondig je het een tijdje eerder dan als een hele veilige oplossing?

[ Voor 15% gewijzigd door elevator op 07-09-2003 21:47 ]

[ACM]

Verwijderd schreef op 07 September 2003 @ 21:29:
OK ik begrijp wel wat je punt is, maar je haalde er dingen bij die gewoon client-side zijn (zoals javascript). Het komt er op neer dat de veiligheid van iets zowel aan de client als aan de serverkant goed moet zijn.

Ik reageerde op jouw posting, dus alles wat ik "erbij haalde" had jij er al bijgehaald

Maar maakt dus niet uit , want daar heb ik en de topicstarter het helemaal niet over.

Dan interpreteer ik de topicstart toch heel anders

Geef dan maar eens aan wat ik fout lees .

De topicstart bijvoorbeeld.

De AIVD haal ik er bij om een reeel scenario te schetsen waarin active content de gegevens van de gebruiker van een anonimiserende proxy kan blootleggen, ondanks SSL.

Zou het voor de AIVD niet gewoon wat makkelijker zijn om de verbindingen simpelweg af te tappen, ipv die rare stunts met hackacties enzo?

Als een site, volledig gericht op verboden informatie, kan aantonen dat jouw ip er is geweest, heb je niets aan het feit dat de verboden data geencrypt verstuurt is. Of je moet de rechter wijs kunnen maken dat je 1000x een niet verboden logoplaatje hebt opgevraagd ...

Het aanbieden van dat soort zaken is doorgaans "meer" illegaal dan het opvragen of zelfs het opslaan ervan. Ik betwijfel of deze suggestie van een "verboden site" die je voor de rechter daagt erg zinvol is, hooguit dat een politieinstelling de loggegevens gebruikt voor verder onderzoek.

Je hebt gelijk dat je nooit kan weten wat een gebruiker allemaal doet terwijl ie op de site zit, maar het gaat er om dat je als bedrijfseigenaar later niet geconfronteerd wilt worden met boze gebruikers die door een zwakte aan de client-side financieel gedupeerd is door een bende oplichters.

Daar heb je een set algemene voorwaarden voor, de computer van de gebruiker is zijn eigen verantwoordelijkheid. Daar kan je de verantwoordelijkheid niet voor op je nemen. Je moet al het mogelijke (zover reeel, bijv ssl aanbieden) doen om te voorkomen _dat_ er wat misgaat, maar daarvoorbij is het de schuld van de klant.
Trojan horses zijn typisch iets dat de schuld is van de klant en nooit van de aanbieder, tenzij ie bijv in een cookie het password opgeslagen zou laten.

Dat wist ik allang en is ondertussen al tijden lang verwijderd. Aangezien het open-source is kan je dit zo achterhalen als je paranoide bent.

Tja we leven in een maatschappij hé ? Het was best wel naai die backdoor ja maar als de rechter je dat oplegt en je verplicht dat je je mond er over moet houden wat wil je dan nog doen....

Ik denk meer dat zijn punt is, dat er al een backdoor inzit en je de mensen van JAP niet al te goed kan vertrouwen daardoor, gezien het feit dat ze het eerst verzwegen.

[Verwijderd]

ls ik terug ga naar de basisvraag van topicstarter:

quote:Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site


Dan is zijn vraag:
# Moet ik gegegevens tonen op een website als ik bang ben dat mensen ermee aan de haal gaan
# Heeft een beveiligde verbinding hier enig effect,

In zijn beginpost heeft BierPul het toch echt over JavaScript wat de plaint text gegevens van je gebruikers van je site afleest.

quote:[over het verbieden van javascript ]
Maar maakt dus niet uit , want daar heb ik en de topicstarter het helemaal niet over.


TS' vraag is toch over de server kant, lijkt me? Hij vraagt hoe hij zijn gegevens kan beveiligen.

Hij heeft de beveiliging van de serverkant al redelijk gerealiseerd dmv SSL. De vraag is echter : er is toch een gevaar dat de gegevens in ongecodeerde staat bij de client gejat kunnen worden ?

quote:Dat wist ik allang en is ondertussen al tijden lang verwijderd. Aangezien het open-source is kan je dit zo achterhalen als je paranoide bent.


Als je dit dan wist - waarom verkondig je het een tijdje eerder dan als een hele veilige oplossing?

Hierom: Dat wist ik allang en is ondertussen al tijden lang verwijderd. Garanties heb je nooit, nee.

OK ik begrijp wel wat je punt is, maar je haalde er dingen bij die gewoon client-side zijn (zoals javascript). Het komt er op neer dat de veiligheid van iets zowel aan de client als aan de serverkant goed moet zijn.

Ik reageerde op jouw posting, dus alles wat ik "erbij haalde" had jij er al bijgehaald

Maar dan wél in de juiste context; dwz de client-side.

quote:Maar maakt dus niet uit , want daar heb ik en de topicstarter het helemaal niet over.


Dan interpreteer ik de topicstart toch heel anders

Inderdaad ja! Dan ben ik het toch nog over iets met je eens .

quote:Geef dan maar eens aan wat ik fout lees .


De topicstart bijvoorbeeld.

Naar jouw mening. Ik heb het tegendeel mijns inziens al aangetoond.

quote:De AIVD haal ik er bij om een reeel scenario te schetsen waarin active content de gegevens van de gebruiker van een anonimiserende proxy kan blootleggen, ondanks SSL.


Zou het voor de AIVD niet gewoon wat makkelijker zijn om de verbindingen simpelweg af te tappen, ipv die rare stunts met hackacties enzo?

1. We gingen er van uit de gebruiker SSL gebruikte. Zoals jij al zei heeft het nogal wat voeten in de aarde om dat te gaan ontsleutelen.
2. Nogmaals: ze hoeven niks te hacken.

quote:Als een site, volledig gericht op verboden informatie, kan aantonen dat jouw ip er is geweest, heb je niets aan het feit dat de verboden data geencrypt verstuurt is. Of je moet de rechter wijs kunnen maken dat je 1000x een niet verboden logoplaatje hebt opgevraagd ...


Het aanbieden van dat soort zaken is doorgaans "meer" illegaal dan het opvragen of zelfs het opslaan ervan.

Ja maar daar heb je niks aan als je eenmaal voor de rechter staat. Bovendien had ik het over de AIVD zelf die een site opent met voor een verdachte aantrekkelijke content. Lijkt me sterk dat die word afgesloten .

Ik betwijfel of deze suggestie van een "verboden site" die je voor de rechter daagt erg zinvol is, hooguit dat een politieinstelling de loggegevens gebruikt voor verder onderzoek.

1. Ik zeg ook niet dat de site verboden is, de gegevens er op kunnen (gedeeltelijk) officieel niet mogen.
2. Ik zei helemaal niet dat de site zelf je voor de rechter daagt, dat lijkt me nogal sterk he. Ik had het over de AIVD zoals je weet; en die kunnen de bewuste loggegevens opeisen als ze dmv active content hopen dat ze je ip te weten komen.

quote:Je hebt gelijk dat je nooit kan weten wat een gebruiker allemaal doet terwijl ie op de site zit, maar het gaat er om dat je als bedrijfseigenaar later niet geconfronteerd wilt worden met boze gebruikers die door een zwakte aan de client-side financieel gedupeerd is door een bende oplichters.


Daar heb je een set algemene voorwaarden voor, de computer van de gebruiker is zijn eigen verantwoordelijkheid. Daar kan je de verantwoordelijkheid niet voor op je nemen. Je moet al het mogelijke (zover reeel, bijv ssl aanbieden) doen om te voorkomen _dat_ er wat misgaat, maar daarvoorbij is het de schuld van de klant.
Trojan horses zijn typisch iets dat de schuld is van de klant en nooit van de aanbieder, tenzij ie bijv in een cookie het password opgeslagen zou laten.

En dat beaamde ik al in een latere post. Een goede tip voor BierPul dus.

quote:Dat wist ik allang en is ondertussen al tijden lang verwijderd. Aangezien het open-source is kan je dit zo achterhalen als je paranoide bent.

Tja we leven in een maatschappij hé ? Het was best wel naai die backdoor ja maar als de rechter je dat oplegt en je verplicht dat je je mond er over moet houden wat wil je dan nog doen....


Ik denk meer dat zijn punt is, dat er al een backdoor inzit en je de mensen van JAP niet al te goed kan vertrouwen daardoor, gezien het feit dat ze het eerst verzwegen.

Zoals ik al zei: Tja we leven in een maatschappij hé ? Het was best wel naai die backdoor ja maar als de rechter je dat oplegt en je verplicht dat je je mond er over moet houden wat wil je dan nog doen....

Bovendien werd het verkeer naar slechts één, Duits, crimineel ip geregistreerd. Niet erg Big Brother dus.

Mij maakt het niet veel uit dat dat ooit is gebeurd, ik ben geen duitse crimineel .

[ACM]

Verwijderd schreef op 07 September 2003 @ 22:06:
In zijn beginpost heeft BierPul het toch echt over JavaScript wat de plaint text gegevens van je gebruikers van je site afleest.

Misschien was een bepaalde zin in zijn posting je niet helemaal opgevallen, maar dat was een voorbeeld ter illustratie voor zijn vraag of het zin heeft de boel met SSL te encrypten.
Want als zijn voorbeeld uitvoerbaar zou zijn, dan heeft heel dat SSL geen zin. Gelukkig is in de eerste reactie al vermeld dat zijn voorbeeld over het algemeen niet werkt.

BierPul schreef op 06 September 2003 @ 14:00:
Bijvoorbeeld.

[...]In dat frame draai ik een stukkie javascript wat de source uit de onderliggende pagina haalt (iets van een for each op getEelementByID) dat doorstuurd aan zich zelf (document.loction.href(bla.php?value=de waarde). en vervolgens opslaat in de database of wat dan ook.

En daarna komt de echte vraag dus:

Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site

Wat, imho, niet echt meer over dat javascript gaat, maar om het algemene punt:
Als je SSL gebruikt, is het dan niet alsnog insecure bij de gebruiker?
Antwoord daarop is natuurlijk ja, maar het simpele voorbeeld waar hij mee aan komt is gelukkig niet mogelijk. De clientside beveiliging moet wel aardig doorbroken worden voor het echt gevaarlijk wordt.
De vraag houdt verder een meer organisatorisch puntje in, "zijn onze gegevens niet te gevoelig om via een website te tonen?". En dat is een punt dat zijzelf zullen moeten uitzoeken. Als een bank via een website de rekeningmutaties durft te laten verwerken, zou het dan niet redelijk betrouwbaar moeten zijn voor minder belangrijke (?) gegevens?

HTTP kent het een en ander aan haken en ogen, waar vooral de stateless werking af en toe erg lastig is. Gelukkig wordt dat deels door SSL afgevangen, met als gevolg dat het http-protocol en dus een website redelijk goed betrouwbaar is te maken.
Afhankelijk van de risico's en de gevoeligheid van de gegevens is het dus wel of niet raadzaam om een website te gebruiken ervoor.

Maar al met al blijft het zo dat de serverside (en daar lijkt het mij dat we het nog steeds over hebben), geen enkele garantie kan geven over de veiligheid bij de clientside. Maar dat de clientside doorgaans toch wel enigszins betrouwbaar probeert te zijn.

Overigens heb ik trouwens wel een goede reden voor je om bijvoorbeeld een javaapplet te gebruiken, gezien het feit dat die ook zelf een SSL-verbinding met de webserver kan opzetten kan je daarmee voorkomen dat externe applicaties eenvoudig de html-structuur kunnen namaken en daarmee ongein uit kunnen halen. De applet is uiteraard zelf weer hackbaar (of de communicatie) maar kan het eventueel wel moeilijker maken.

[Grijze Vos]

(weet niet zeker of dit al gezegd is, maar geen zin om alles door te lezen )

Als reply op Cybarite:
128 bits encryptie is sterk zat om niet on-the-fly gedecrypt te worden, en bij bijv, man-in-the-middle attacks, gaat het juist om dat element.

[Soultaker]

Grijze Vos schreef op 08 september 2003 @ 00:38:
128 bits encryptie is sterk zat om niet on-the-fly gedecrypt te worden, en bij bijv, man-in-the-middle attacks, gaat het juist om dat element.

Hoe bedoel je? Bij een man-in-the-middle attack is de sterkte van de gebruikte encryptie juist compleet irrelevant.

[bloody]

crisp schreef op 06 September 2003 @ 14:09:
Javascript kan niet cross-domain gebruikt worden; het standaard javascript security model verbied dat.

Ehh, wel eens gedacht aan het aanpassen van de mozilla-source en opnieuw compileren?

[ACM]

bloody schreef op 08 september 2003 @ 09:00:
Ehh, wel eens gedacht aan het aanpassen van de mozilla-source en opnieuw compileren?

Ik betwijfel of er veel gebruikers zijn die dat zullen doen... Maar als er een "geinfecteerde" Mozilla ergens verschijnt kan dat idd zeer schadelijk zijn.

[martijn_brinkers]

Ehh, wel eens gedacht aan het aanpassen van de mozilla-source en opnieuw compileren?

<sarcastic_mode>
Ehh, wel eens aan gedacht aan het aanpassen van je browser dat ie je harddisk gaat formateren?
</sarcastic_mode>

Kijk als iemand graag met een onveilige browser wil werken dan kan er van alles gebeuren. Het gaat er natuurlijk om dat je niet aan serverkant iets kan doen waardoor het aan de client kan onveilig wordt. Wat de client zelf voor stomme dingen doet is zijn eigen verantwoordelijkheid.

[BierPul]

Het lullige is daarin alleen dat de gene die de site runt (wij in dit geval) wel de lul zijn

Al is het niet redelijk de media is onverbiddelijk

[ACM]

BierPul schreef op 08 September 2003 @ 11:10:
Het lullige is daarin alleen dat de gene die de site runt (wij in dit geval) wel de lul zijn

Al is het niet redelijk de media is onverbiddelijk

Nee hoor, dat is niet waar. Als jij al het mogelijke doet wat redelijkerwijs van je verwacht kan worden, dan heb je voldoende gedaan. Meer kan je ook niet doen.

Dan hebben we het over het vrijwaren van je software van code-, sql- en html-injecties, het voorschrijven van goede passwords, het gebruik van ssl, etc.

Als de gebruiker een foute browser installeert is het enige wat je kan doen hem waarschuwen dat hij goed uit moet kijken dat zijn browser niet perse te vertrouwen is als ie ermee heeft zitten rommelen.
De meeste gebruikers gebruiken echter de standaard browser met de standaard instellingen (IE dus...) en hoewel ze die niet perse up-to-date houden is dat allemaal niet jouw fout.
Als men dat je al probeert aan te rekenen, dan wordt het wel heel erg...

Adviseer ze actief, zorg ervoor dat ze bij hun eerste bezoek duidelijk, behapbaar en kort en bondig wat informatie krijgen over browsers up-to-date maken en controleren of hun versies wel veilig zijn (bijv door een testpagina te maken met het door jou voorgestelde javascriptprobleem) en laat ze dan op een knop "ik beweer dat mijn browser veilig is na dit gelezen te hebben" drukken.
Vervolgens kan je bij elke login dan vermelden dat er wat gebeurd is (nieuwe bugs in IE6 of mozilla bijv) oid als de laatste login voor zo'n gebeurtenis was.

Maar als je bovenstaande allemaal doet, dan ga je in je service al vele malen verder dan wat de beide banken waar ik bij zit doen
Ga dus sowieso bij jezelf na of de informatie die jullie aanbieden het waard is aan te bieden via een website en ga dan na of die informatie het waard is "tot het uiterste te gaan" of alleen maar het waard is om "het gewoon goed te doen"

[BierPul]

We doen het dan gewoon goed

Daar kunnen we het dan bij laten

Iedereen bedankt voor de feedback..

[Verwijderd]

quote:
--------------------------------------------------------------------------------
Cybarite schreef op 07 September 2003 @ 22:06:
In zijn beginpost heeft BierPul het toch echt over JavaScript wat de plaint text gegevens van je gebruikers van je site afleest.

--------------------------------------------------------------------------------

Misschien was een bepaalde zin in zijn posting je niet helemaal opgevallen, maar dat was een voorbeeld ter illustratie voor zijn vraag of het zin heeft de boel met SSL te encrypten.

[q]Voor mn werk hebben we een site draaien waarop mensen hun gegevens kunnen bekijken en eventueel kunnen wijzigen.

Dat verloopt allemaal via SSL dus dat zit allemaal wel ok.

Maar nu vraag ik me af of het wel helemaal waterdicht is.[/q]

Oftewel hij gebruikt allang SSL, en vraagt zich af of dat wel waterdicht is.

Want als zijn voorbeeld uitvoerbaar zou zijn, dan heeft heel dat SSL geen zin. Gelukkig is in de eerste reactie al vermeld dat zijn voorbeeld over het algemeen niet werkt.

SSL heeft dan wel degelijk zin, zoals je zélf eerder al zei. Met SSL maak je de kans op het achterhalen van privacygevoelige gegevens dmv sniffing dermate klein, dat een normale crimineel zoals ze hier in NL voorkomen er geen nuttige gegevens aan kan achterhalen.

Tja daar hadden we het net over he, of het uitvoerbaar is (een aanval dmv javascript). Dat ligt dus geheel aan de client en is in de praktijk, gezien het lage aantal mensen wat iedere security update aan hun browser gaat installeren, best goed mogelijk. Vaak komt het niet voor maar ik bedenk me nu dat dat eigenglijk in contrast staat met de technische mogelijkheid daartoe (--> die is veel groter). Het is daarom ook niet verwonderlijk dat BierPul zich hier zorgen om maakt.

Maar het blijft gewoon je eigen afweging, en in de praktijk zal het gevaar niet zo groot zijn als je nu zou denken, zegt ACM ook al

quote:
--------------------------------------------------------------------------------
BierPul schreef op 06 September 2003 @ 14:00:
Bijvoorbeeld.

[...]In dat frame draai ik een stukkie javascript wat de source uit de onderliggende pagina haalt (iets van een for each op getEelementByID) dat doorstuurd aan zich zelf (document.loction.href(bla.php?value=de waarde). en vervolgens opslaat in de database of wat dan ook.

--------------------------------------------------------------------------------

En daarna komt de echte vraag dus:

quote:
--------------------------------------------------------------------------------
Ik vraag me dus af of we als bedrijf er wel verstandig aan doen om deze gegevens al dan niet secure te tonen op de site

--------------------------------------------------------------------------------

Mijn antwoord daarop is duidelijk, natuurlijk heeft dat zin. Maar wat bedoel je precies met 'secure' ? Een pagina laten zien dmv SSL ? Of op een of andere manier al het client-side gevaar in dammen ?

Wat, imho, niet echt meer over dat javascript gaat, maar om het algemene punt:
Als je SSL gebruikt, is het dan niet alsnog insecure bij de gebruiker?
Antwoord daarop is natuurlijk ja, maar het simpele voorbeeld waar hij mee aan komt is gelukkig niet mogelijk. De clientside beveiliging moet wel aardig doorbroken worden voor het echt gevaarlijk wordt.

Nou dat betwijfel ik dus. Ligt geheel aan de situatie van de client. Zoals ik boven al zeg: technisch gezien is het gevaar groter dan dat je in de praktijk tegen zal komen. Maar wil je dat risico lopen ?

De vraag houdt verder een meer organisatorisch puntje in, "zijn onze gegevens niet te gevoelig om via een website te tonen?". En dat is een punt dat zijzelf zullen moeten uitzoeken.

Interessant aspect ja ! Iedereen begrijpt wel dat alles in principe te kraken valt. Als je daar zo bang voor bent, moet je dan die gegevens wel tonen ? Ik ben het voor de verandering volledig met je eens op dit punt . Voor zover dat kan dan .

Als een bank via een website de rekeningmutaties durft te laten verwerken, zou het dan niet redelijk betrouwbaar moeten zijn voor minder belangrijke (?) gegevens?

Daar heb je gelijk in, maar mij grootmoe heeft mij altijd geleerd: "Je moet niet naar anderen kijken die het net zo slecht doen, je moet naar jezelf kijken en het beter doen." (mooie sig voor iemand BTW Zet er aub (c) Cybarite achter )

Dat die banken het risico willen lopen is goed te beargumenteren. Mocht het uitzonderlijke geval zich voordoen dat iemand aan de client-side gegevens weet te benutten, dan vergoed de bank dat wel. Denk aan de pinpasfraude. Het gaat waarschijnlijk toch om kleine bedragen, voor een bank dan.

HTTP kent het een en ander aan haken en ogen, waar vooral de stateless werking af en toe erg lastig is. Gelukkig wordt dat deels door SSL afgevangen, met als gevolg dat het http-protocol en dus een website redelijk goed betrouwbaar is te maken.
Afhankelijk van de risico's en de gevoeligheid van de gegevens is het dus wel of niet raadzaam om een website te gebruiken ervoor.

Om misbruik te maken van de stateless werking zul je pakketen moeten spoofen (en het sequence number moeten kraken, maar da's niet moeilijk). Je kan iig niet pakketen met gevoelige informatie naar jezelf redirecten, of je moet gebruik maken van de DHCP spoof exploit. Maar het lijkt me sterk dat een hacker deel is van het bedrijfsnetwerk. Als dat eenmaal zo is, kan hij net zo goed andere methoden hanteren. Maar ik ben het met je eens.

Overigens heb ik trouwens wel een goede reden voor je om bijvoorbeeld een javaapplet te gebruiken, gezien het feit dat die ook zelf een SSL-verbinding met de webserver kan opzetten kan je daarmee voorkomen dat externe applicaties eenvoudig de html-structuur kunnen namaken en daarmee ongein uit kunnen halen. De applet is uiteraard zelf weer hackbaar (of de communicatie) maar kan het eventueel wel moeilijker maken.

Soms is een applet nog makkelijker namaakbaar dan een browser (als je geen enkele code hebt.) Maar ja alles is namaakbaar...

128 bits encryptie is sterk zat om niet on-the-fly gedecrypt te worden, en bij bijv, man-in-the-middle attacks, gaat het juist om dat element.

Nee je hebt duidelijk niet alles doorgelezen . Als je al het verkeer rond een bepaald tijdstip snifft en oplslaat, kun je het achteraf nog kraken.

Ehh, wel eens gedacht aan het aanpassen van de mozilla-source en opnieuw compileren?

Als je de client-side niet standaard vertouwd, zoals ik, dan is dat helemaal geen probleem. Zoals ACM al zegt kan je alles wel namaken.

BierPul:

De conclusie lijkt me duidelijk. Jezelf juridisch afschermen en alles in het werk stellen om onveiligheid te voorkomen. Dan kan je dat ook in de media verkondigen.