Onderzoekers ontwerpen label-restrictiesysteem voor javascript-apps

Onderzoekers van UCL, Stanford Engineering, Google, Chalmers University en Mozilla Research hebben een nieuw systeem ontwikkeld dat de privacy van internetgebruikers significant zou verbeteren terwijl web-apps toch informatie afkomstig van meerdere sites kunnen verzamelen.

Het systeem draagt de naam COWL, oftewel Confinement with Origin Web Labels, en functioneert momenteel op Firefox en Chromium, de opensourceversie van Chrome, zo beschrijft UCL. Het systeem legt door middel van zogenaamde 'contexts' restricties op aan javascript. Zo moeten gebruikers beschermd worden tegen het lekken van gevoelige informatie aan ongeautoriseerde partijen via bijvoorbeeld malafide scripts. Het moet voor webprogrammeurs tegelijkertijd wel mogelijk blijven om web-apps te bouwen die gegevens van verschillende websites verzamelen en verwerken, zoals mashups.

De COWL-technologie accepteert dat informatie wordt gedeeld, maar geeft ontwikkelaars wel de mogelijkheid om een aantal beperkingen op te leggen. Zo kan javascriptcode data, al dan niet legitiem, van een andere website inlezen en verwerken, maar de bron kan dankzij COWL aangeven dat deze informatie niet langer gedeeld mag worden met andere partijen. Implementatie van COWL in de browser zou vrijwel geen negatieve invloed hebben op de verwerkingssnelheid van web-apps.

Als een web-app bijvoorbeeld prijzen met elkaar wil vergelijken, dan moet er momenteel nog javascriptcode worden geschreven om informatie van meerdere websites te verzamelen. De huidige beveiligingssystemen zouden dergelijke handelingen kunnen blokkeren, omdat de informatie afkomstig is van verschillende domeinen.

Same Origin Policy is een voorbeeld van een dergelijk systeem. Om dit mechanisme te ontwijken, wordt er veelal om inlogcodes gevraagd, waardoor de gegevens alsnog kunnen worden uitgewisseld. De onderzoekers zeggen dan ook dat het huidige beveiligingssysteem webdesigners min of meer verplicht om keuzes te maken die de privacy van internetgebruikers kan schaden. COWL zou hier een goed alternatief voor bieden. De code voor COWL is vanaf 15 oktober kosteloos te downloaden, zo hebben de onderzoekers aangekondigd.

Reacties (4)

[MadEgg]

Ik vind het nieuwsartikel hier niet zo duidelijk, maar het komt er dus op neer dat je een extern script in kunt laden als een gelabelde context, met behulp van message passing hier een verzoek naartoe kunt sturen met data die gelabeld is als zijnde gevoelig. Zodra het externe script deze gevoelige data gebruikt wordt het de mogelijkheid ontnomen om verder te communiceren met andere hosts dan degene waar het verzoek vandaan komt, dus ook niet met de host waar het externe script zich bevindt.

Lijkt me op zich best handig dit, maar het nadeel is wel dat zowel de aanvrager als de leverancier van het externe script de code hierop aan zullen moeten passen. Dit helpt dus niet in veel situaties waarin websites gebruik maken van data van andere sites zonder dat die sites daar expliciet aan meewerken.

Sowieso zou in veel gevallen m.i. überhaupt geen extern script gebruikt moeten worden maar een script op de host waar je sowieso al verbinding mee hebt. Vertrouwen op derde partijen is een aardig beveiligingsrisico. Nu wordt dat hier wel wat door verbeterd, maar nog beter is de data gewoon lokaal te houden.

[R4gnax]

Je gaat dus de mogelijkheid krijgen om scripts in een afgebakende sandbox te draaien die alleen via een messaging interface (zoals de bestaande window.postMessage API) met de buitenwereld kan communiceren. Zodra er door deze sandbox een message ontvangen wordt vanaf een gegeven domein gaat alle externe communicatie op slot, behalve communicatie met dat ene domein.

Heel fijn in concept, maar dit gaat je dus geen zier helpen met mashups die zaken als Facebook of Twitter widgets integreren, waar communicatie met de servers van die 3e partij essentieel is voor het correct functioneren.

Dit zou pas zin hebben als je expliciet een marker aan bepaalde data toe kunt voegen op zo'n manier dat die en enkel die data niet doorgecommuniceerd kan of mag worden, terwijl andere data wel gewoon gecommuniceerd mag worden.

En dan ga je inderdaad af op een 'taint' oplossing, zoals bijv. op het moment al bestaat wanneer je cross-origin resources op een HTML canvas element gaat tekenen en daarmee een aantal privacy-gevoelige operaties op dat canvas uitgeschakeld worden alswel dat deze 'taint' ook het canvas zelf 'infecteert'.

Mag hopen dat COWL inderdaad een dergelijke implementatie omvat. Het zal alleen wel enorm moeilijk zijn om alle mogelijke gaatjes te dichten. Als een gesandboxed script bijv. nog met de DOM moet kunnen communiceren (wat dus voor een widget best wel esssentieel is), dan zullen ook alle mogelijke combinaties van DOM interactie met een 'taint' omweg kunnen. Maar die taint zal op zijn beurt ook weer niet te agressief toegepast moeten worden, omdat op dat moment alle mogelijkheid tot communicatie weer geblokkeerd gaat worden. etc. etc.


Het klinkt allemaal leuk in theorie, en in begrensde scenario's werkt het vast goed -- Canvas taints is een mooit voorbeeld daarvan, eigenlijk. --, maar er dit een dikke kans in dat dit in de praktijk weer één van twee kanten uit rollen:
of het wordt zo rigide dat niemand er gebruik van kan maken,
of het wordt zo lek dat niemand er gebruik van wil maken.

[Juup]

Een beetje zoals Perl's taint (perl -T).
Ziet er interessant uit.

[Verwijderd]

Hopelijk wordt dit niet net zo'n drama als CORS. Ik zal niet uitwijden over de vele problemen die deze techniek heeft, en hoe weinig het daadwerkelijk voor security doet.