Webbsäkerhetsverktyget kopierar apparnas rörelser

Nuförtiden är det lätt för utvecklare att bygga fullfjädrade applikationer som körs i webbläsaren. Att hålla dessa applikationer säkra från hackare är en annan sak.

Spela säkert : Microsoft-forskare har använt Ripley för att säkra flera webbapplikationer, inklusive spel.

Med detta i åtanke har forskare vid Microsoft Research avslöjat ett nytt sätt att säkra komplexa webbapplikationer genom att effektivt klona användarens webbläsare och köra den på distans.

Många av de senaste webbapplikationerna delar upp sin körbara kod mellan servern och klienten. Problemet är att upptäcka om koden som körs på användarens hemdator har äventyrats på något sätt. Den nya Microsoft-lösningen, känd som Ripley, tillkännagavs på tisdagen på Association for Computing Machinery's Dator- och kommunikationssäkerhetskonferens i Chicago.

Ripley går längre än tidigare ansträngningar för att säkra webbapplikationernas integritet. Det tar integritetsskyddet till sin logiska ytterlighet, säger Adam Barth , en forskare vid University of California, Berkeley, som är specialiserad på säkerhet för webbapplikationer. Han var inte involverad i projektet. Istället för att bara verifiera att en förfrågan kom från rätt webbplats, verifierar Ripley att användarens handlingar faktiskt tillåts av applikationens användargränssnitt.

Ripley förhindrar en illvillig användare eller fjärrhacker från att ändra beteendet hos kod som körs i en webbläsare genom att skapa en exakt kopia av beräkningsmiljön och köra den kopian på servern. Ripley skickar sedan alla användarens handlingar, inklusive musklick, tangenttryckningar och andra indata, i en komprimerad händelseström från klienten till servern. Denna ström körs genom den klonade klientapplikationen på servern, och beteendet hos den virtuella dubbelgångaren jämförs med det hos applikationen som körs på användarens webbläsare hemma. Om det finns några avvikelser kopplar Ripley bort klienten.

Man kan inte lita på något som händer hos klienten, säger Ben Livshits , den ledande forskaren på Microsoft Research om Ripley-projektet. Det är i princip djävulen i webbläsaren från utvecklarens synvinkel.

Ripley är osynlig för slutanvändaren och påverkar inte den normala funktionen hos en webbapplikation. Det är bara de illvilliga killarna som behöver oroa sig för vad som händer när de väl skickar in ett resultat, säger Livshits.

En av utmaningarna som Livshits och hans medarbetare på Microsoft, Emre Kiciman , när man byggde Ripley var hur man skapar en kopia av hela klientmiljön – webbapplikationen och programvarumotorn som kör den – som var tillräckligt liten för att vara praktisk för en webbserver med stora volymer som hanterar förfrågningar från hundratals eller tusentals användare på en gång.

På servern, sa Livshits, om du måste köra repliken i en webbläsare skulle du få ett minnesfotavtryck på 50 till 60 megabyte per webbläsarinstans. Lösningen som han och Kiciman kom på var att istället köra en huvudlös webbläsare – en emulator som bara simulerar funktionerna i en webbläsare som är nödvändig för Ripley. Detta drev ner minnesavtrycket för den klonade webbläsaren och applikationen till mellan en och en och en halv megabyte per applikation.

Genom att krympa klonen på serversidan av användarens webbläsarbaserade applikation reducerade Livshits och Kiciman – tillsammans med kollegor från Cornell University, NY och Indian Institute of Technology, Delhi – Ripleys prestandakostnader ytterligare. Av fem experimentella applikationer, som inkluderade en kundvagn, flera spel och en bloggmotor, var den genomsnittliga ökningen i latens på grund av de ökade ansträngningarna från serverns CPU cirka en millisekund.

I vissa fall förbättrade Ripley till och med prestandan för webbapplikationer, eftersom klonen på serversidan av klientapplikationen skrivs om i .NET, ett programmeringsspråk som är 10 till 100 gånger snabbare än JavaScript som körs på klientsidan. Ibland tillåter detta Ripley att förutsäga vad nästa applikationsbegäran på klientsidan kommer att bli innan den ens har gjorts av klienten, och i förebyggande syfte skicka data till klienten.

Det här är en magisk situation, om man tänker efter, säger Livshits. Det leder till noll latens fjärranrop för procedur.

För närvarande måste utvecklare som är intresserade av att använda Ripley för att säkra sina webbapplikationer omimplementera idéerna i artikeln som presenterades om Ripley på sin egen favoritram för webbapplikationer. Så småningom tror Livshits och Kiciman dock att Ripley skulle kunna hjälpa till att demokratisera en viktig del av webbapplikationssäkerheten och göra den inom räckhåll för icke-experta utvecklare.

Hittills tror jag att folk har attackerat dessa problem manuellt, säger Kiciman. Du får experter som dyker in och de skräddarsyr sina applikationer för att möta dessa utmaningar, men det är inte särskilt skalbart och inte särskilt smidigt när du behöver göra ändringar. Vad vi försöker göra är att få webbutvecklingsplattformen till en punkt där vem som helst kan dra fördel av den typ av teknik som dessa experter använder.

UC Berkeleys Barth noterar att Ripley är en del av en större trend inom lösningar som skyddar integriteten hos kod på klientsidan genom att säkerställa att inget obehörigt beteende kan inträffa. Jag ser Ripley som mer av ett tankeexperiment: Vad skulle hända om servern validerade allt? han säger. Arbetet tyder på att säkerhet skulle gynnas om vi validerade mer än vi validerar idag.

Dölj