Java versus ActiveX
Wie interactiviteit op zijn Website wil, kan natuurlijk gebruik maken van formulieren en plaatjes. Maar voor meer uitgebreide toepassingen is het gebruik van een Java applet of een ActiveX control bijna vereist. Beide bieden uitgebreide mogelijkheden voor animaties, interactieve toepassingen, maar brengen ook de nodige veiligheidsrisico's met zich mee.
Inhoudsopgave
De Java-politie
Programma's die in Sun's taal Java zijn geschreven, kunnen in principe op elk platform gedraaid worden. De gebruiker heeft hiervoor wel een zogeheten Java runtime interpreter nodig, die het programma uitvoert en zorgt voor weergave op het scherm en het afhandelen van de invoer van de gebruiker. Deze runtime interpreter is inmiddels voor vrijwel alle platforms beschikbaar. Het is nu dus in principe mogelijk om een programma te schrijven in Java dat iedereen op zijn computer kan uitvoeren, zonder dat de auteur aparte versies voor elk besturingssysteem hoeft te schrijven.
Een belangrijke toepassing van Java is het gebruik van ``applets'', kleine programma's die in een Webpagina opgenomen kunnen worden. Als de gebruiker dan de pagina opvraagt, wordt de applet uitgevoerd en verschijnt in- en uitvoer in de pagina. Op deze manier is het mogelijk om interactieve pagina's te maken.
Hierbij ontstaat natuurlijk wel een groot veiligheidsrisico. De gebruiker haalt tenslotte een programma binnen van een onbekende Website, dat vervolgens automatisch uitgevoerd wordt. Een uitgelezen mogelijkheid voor kwaadwillende personen om te spioneren of schade aan te richten, zo lijkt het. Gelukkig heeft Sun hier rekening mee gehouden. Wanneer de Java runtime interpreter een applet uit gaat voeren, worden er aan het programma bepaalde restricties opgelegd. Zo mag een applet niet naar de harde schijf schrijven, bestanden openen of verbindingen leggen met willekeurige Internet-sites.
Om deze restricties af te dwingen, controleert de Java runtime interpreter alle code voordat hij deze uitvoert. Instructies die er verdacht uitzien, worden gewoonweg niet uitgevoerd, waardoor een kwaadaardige applet geen schade aan kan richten.
Zandbak
De restricties in de oorspronkelijke versie van Java bleken toch wel erg beperkend. Er is daarom een uitbreiding gemaakt op wat een applet mag doen. Dit is de zogeheten ``zandbak'', een apart stukje op de harde schijf waarin de applet mag doen en laten wat hij wil. Zo kan een applet dus toch bestanden lezen en schrijven, mits de gebruiker deze van te voren in de zandbak heeft gezet. De rest van het systeem blijft dus beschermd.
Deze uitbreiding biedt applets meer mogelijkheden, maar het risico is nu ook groter. Als de browser de controle over wat wel en niet in de zandbak zit niet goed uitvoert, kan de applet alsnog de hele harde schijf benaderen. Sommige versies van Netscape bevatten inderdaad een dergelijke fout. Ook kan natuurlijk de gebruiker per ongeluk een te groot gebied als zandbak aanmerken, waardoor de applet de verkeerde bestanden kan benaderen.
En er bestaat altijd het gevaar dat de Java runtime interpreter een fout bevat, waardoor kwaadaardige code niet als zodanig wordt aangemerkt. Inventieve programmeurs bedenken steeds nieuwe manieren om om de beperkingen van de runtime interpreter heen te komen en toch dingen te doen die niet de bedoeling zijn. Het is bijvoorbeeld mogelijk om een rekenkundige bewerking uit te voeren die veel processortijd kost. Volkomen legitiem, maar als een applet deze bewerking duizend keer tegelijk uitvoert, wordt het systeem onbruikbaar voor andere toepassingen. Toch is er hier geen sprake van kwaadaardige instructies volgens de Java runtime interpreter.
Binnen het Java model zijn er dus een aantal risico's, die voornamelijk afhangen van de kwaliteit van de runtime interpreter. Bij een goede implementatie, waarbij ook beperkingen kunnen worden opgelegd aan de hoeveelheid processortijd en dergelijke, is de kans op kwaadaardig gedrag van een Java applet vrijwel nul.
De ActiveX-douane
Microsoft's programmeertaal ActiveX volgt een andere aanpak. Een ActiveX control is niets meer of minder dan een volledig Windows programma, dat speciaal geschreven is om in een browser uitgevoerd te worden. Een ActiveX control kan dus alles wat een normaal programma ook kan, van het lezen van willekeurige bestanden tot het formatteren van de harde schijf. Er is geen runtime interpreter zoals bij Java, die in de gaten houdt wat de control wil doen en zo nodig ingrijpt. De beveiliging komt hier van een digitale handtekening.
Wie namelijk een ActiveX control wil schrijven, moet deze voorzien van zijn digitale handtekening. Deze krijgt een auteur alleen als hij aan bepaalde eisen voldoet. Hij moet bijvoorbeeld beloven dat hij geen kwaadaardige code zal schrijven, en natuurlijk moet zijn identiteit bekend zijn bij Verisign, de instantie die de certificaten verstrekt waarmee hij handtekeningen kan plaatsen. Als een control dus schade aanricht, is bekend wie de auteur is en kan men deze aansprakelijk stellen voor de schade of zelfs strafrechtelijk vervolgen.
Wanneer een gebruiker nu een ActiveX control binnenhaalt, krijgt hij de mededeling te zien dat de control gesigneerd is door een bepaalde auteur. Hij kan nu kiezen of hij deze auteur vertrouwt en of de applet dus uitgevoerd moet worden. Zo kan een gebruiker zich beperken tot vertrouwde en bekende software-auteurs, zodat hij geen risico loopt kwaardaardige controls te downloaden.
Helaas blijkt dit in de praktijk niet zo te werken. De controle van de handtekeningen klopt lang niet altijd, waardoor veel gebruikers geneigd zijn deze stap over te slaan en altijd direct voor uitvoeren te kiezen. Ook zijn er zo veel pagina's met controls dat het niet langer praktisch is om te onthouden wie nu wel of niet betrouwbaar is. Vertrouwen op de handtekening is dus geen realistische optie. Zo kreeg de auteur Fred McClain bijvoorbeeld zonder problemen een certificaat voor zijn Exploder control, die de computer van de gebruiker automatisch kon herstarten.
Een heel ander probleem met ActiveX is dat het niet zo platform-onafhankelijk is als Java. Een control die onder Windows gebruikt kan worden, werkt niet onder MacOS (en andersom). Voor andere platforms is geen ondersteuning voor ActiveX, dit in tegenstelling tot de vele platforms waarop Java beschikbaar is.
Conclusie
Het uitvoeren van programma's die van een onbekende Website komen is natuurlijk altijd een risico, of dit programma nu eerst genstalleerd moet worden of direct beschikbaar is. De ``politie'' methode van Java, die elk programma in de gaten houdt en ingrijpt als het fout dreigt te gaan, lijkt tot nu toe goed te werken, mits de browser of het besturingssysteem beschikt over een goede Java runtime interpreter. De gebruiker moet er maar op vertrouwen dat dit in orde is.
Microsoft's ``douane'' methode bij ActiveX gaat alleen na of de control van een bekende bron afkomstig is. Het gebruik van digitale handtekeningen zou hier een goede beveiliging moeten bieden, maar helaas blijkt dit lang niet altijd zo te zijn. De gebruiker moet meer informatie krijgen voordat hij een control uitvoert, zodat hij na kan gaan of dit werkelijk een goedaardige control is. Maar zelfs dan is er nog een probleem: als een control de harde schijf herformatteert, is daarmee natuurlijk ook al het bewijsmateriaal van de digitale handtekening weg.
