Websikkerhedsværktøj kopierer apps bevægelser

I dag er det nemt for udviklere at bygge fuldt udbyggede applikationer, der kører inde i browseren. At holde disse applikationer sikre mod hackere er en anden sag.

Spil det sikkert : Microsoft-forskere har brugt Ripley til at sikre adskillige webapplikationer, inklusive spil.

Med dette i tankerne har forskere hos Microsoft Research afsløret en ny måde at sikre komplekse webapplikationer på ved effektivt at klone brugerens browser og køre den eksternt.

Mange af de nyeste webapplikationer deler deres eksekverbare kode mellem serveren og klienten. Problemet er at opdage, om koden, der kører på brugerens hjemme-pc, er blevet kompromitteret på en eller anden måde. Den nye Microsoft-løsning, kendt som Ripley, blev annonceret tirsdag hos Association for Computing Machinery Computer- og kommunikationssikkerhedskonference i Chicago.

Ripley går længere end tidligere bestræbelser på at sikre integriteten af ​​webapplikationer. Det tager integritetsbeskyttelse til sin logiske yderlighed, siger Adam Barth , en forsker ved University of California, Berkeley, som har specialiseret sig i sikkerheden af ​​webapplikationer. Han var ikke involveret i projektet. I stedet for blot at verificere, at en anmodning kom fra det rigtige websted, verificerer Ripley, at brugerens handlinger faktisk er tilladt af applikationens brugergrænseflade.

Ripley forhindrer en ondsindet bruger eller fjernhacker i at ændre adfærden for kode, der kører i en webbrowser, ved at oprette en nøjagtig kopi af beregningsmiljøet og køre denne kopi på serveren. Ripley sender derefter alle brugerens handlinger, inklusive museklik, tastetryk og andre input, i en komprimeret hændelsesstrøm fra klienten til serveren. Denne stream køres gennem den klonede klientapplikation på serveren, og den virtuelle dobbeltgængers adfærd sammenlignes med den applikation, der kører på brugerens browser derhjemme. Hvis der er uoverensstemmelser, afbryder Ripley klienten.

Man kan ikke stole på noget, der sker i klienten, siger Ben Livshits , den ledende forsker hos Microsoft Research på Ripley-projektet. Det er dybest set djævelen i browseren fra udviklerens synspunkt.

Ripley er usynlig for slutbrugeren og påvirker ikke en webapplikations normale funktion. Det er kun de ondsindede fyre, der skal bekymre sig om, hvad der sker, når de har indsendt et resultat, siger Livshits.

En af de udfordringer, som Livshits og hans samarbejdspartner hos Microsoft, Emre Kiciman , der stod over for, da Ripley byggede, var, hvordan man opretter en kopi af hele klientmiljøet – webapplikationen og softwaremotoren, der kører det – som var lille nok til at være praktisk til en webserver med stor volumen, der håndterede anmodninger fra hundreder eller tusinder af brugere på enkelt gang.

På serveren, sagde Livshits, hvis du skal køre replikaen i en browser, vil du pådrage dig et hukommelsesfodaftryk på 50 til 60 megabyte pr. browserforekomst. Løsningen, som han og Kiciman udtænkte, var i stedet at køre en hovedløs browser - en emulator, der kun simulerer funktionerne i en webbrowser, der er afgørende for Ripley. Dette reducerede hukommelsesfodaftrykket for den klonede browser og applikation til mellem en og halvanden megabyte pr. applikation.

Ved at formindske klonen på serversiden af ​​brugerens browserbaserede applikation reducerede Livshits og Kiciman – sammen med kolleger fra Cornell University, NY og Indian Institute of Technology, Delhi – ydeevnen overhead af Ripley yderligere. Ud af fem eksperimentelle applikationer, som omfattede en indkøbskurv, adskillige spil og en blogging-motor, var den gennemsnitlige stigning i latens på grund af den øgede indsats fra serverens CPU omkring et millisekund.

I nogle tilfælde forbedrede Ripley endda ydeevnen af ​​webapplikationer, fordi server-side klonen af ​​klientapplikationen er omskrevet i .NET, et programmeringssprog, der er 10 til 100 gange hurtigere end JavaScript, der kører på klientsiden. Nogle gange tillader dette Ripley at forudsige, hvad den næste klient-side applikationsanmodning vil være, før den overhovedet er blevet foretaget af klienten, og forebyggende skubbe data til klienten.

Det er en magisk situation, hvis man tænker over det, siger Livshits. Det fører til fjernprocedurekald med nul latency.

På nuværende tidspunkt er udviklere, der er interesseret i at bruge Ripley til at sikre deres webapplikationer, nødt til at genimplementere ideerne i papiret præsenteret om Ripley på deres egen foretrukne webapplikationsramme. Til sidst tror Livshits og Kiciman dog, at Ripley kunne hjælpe med at demokratisere en væsentlig del af webapplikationssikkerheden, og sætte den inden for rækkevidde af ikke-ekspertudviklere.

Indtil nu tror jeg, at folk har angrebet disse problemer manuelt, siger Kiciman. Du får eksperter, der dykker ind, og de skræddersyer deres applikationer til at imødekomme disse udfordringer, men det er ikke særlig skalerbart og ikke særlig smidigt, når du skal lave ændringer. Det, vi forsøger at gøre, er at få webudviklingsplatformen til et punkt, hvor alle kan drage fordel af de typer teknologi, som disse eksperter bruger.

UC Berkeleys Barth bemærker, at Ripley er en del af en større trend inden for løsninger, der beskytter integriteten af ​​kode på klientsiden ved at sikre, at der ikke kan forekomme uautoriseret adfærd. Jeg ser Ripley som mere et tankeeksperiment: Hvad ville der ske, hvis serveren validerede alt? han siger. Arbejdet tyder på, at sikkerhed ville gavne, hvis vi validerede mere, end vi validerer i dag.

skjule