211service.com
Mashup Sikkerhed
Mashups – onlineapplikationer, der kombinerer data og værktøjer fra forskellige websteder – bliver stadig mere nyttige. Selvom de startede som simple forbrugerprogrammer, som f.eks et værktøj der placerede boligannoncer fra Craigslist på Google kort , er mashups vokset i kompleksitet og bliver også populære blandt virksomheder. Efterhånden som et stigende antal værktøjer frigives for at hjælpe folk med nemt at bygge mashups, kigger eksperter også på, hvordan man kan afværge sikkerhedsrisici.
En usikker blanding: Nuværende metoder til fremstilling af mashups, som kombinerer data og værktøjer fra flere kilder på nettet, kan skabe sikkerhedsproblemer. Eksperter undersøger måder, hvorpå man kan bevare den brede kreative frihed, som mashups tilbyder, og samtidig gøre dem mere sikre at bruge. Dette er af særlig interesse for forretningsbrugere, der ønsker at bygge mashups.
Mange mashups deler kun tekst, siger David Boloker, medstifter af OpenAjax Alliance og IBM'er CTO for Emerging Internet Technologies. De risikerer i værste fald, herunder ukorrekte eller ophavsretligt beskyttede data. Men efterhånden som mashups bliver mere komplekse, er de begyndt at inkorporere computerkode fra flere kilder. På dette tidspunkt bygger vi nu bro til upålidelig kode, siger Boloker. For eksempel vil et ejendomsselskab måske have en mashup til at arbejde med fortegnelser fra en intern database. Mashup'et kan køre annoncerne gennem tredjepartsværktøjer til sammenligning med konkurrenternes priser i de samme postnumre og derefter bruge et ekstra tredjepartsværktøj til at kortlægge alle husene på markedet. Uden sikkerhedsforanstaltninger kan denne mashup gøre virksomhedens interne database sårbar over for ondsindet kode i et hvilket som helst af disse tredjepartsværktøjer.
Webbrowsere var ikke designet med mashups i tankerne, og vorterne har været der fra dag ét, siger Boloker. Browsere indeholder en sikkerhedsfunktion kaldet same-origin policy, der er beregnet til at forhindre ondsindet kode, der er hostet på et websted, fra at fange data, såsom gemte legitimationsoplysninger, fra et andet websted. Politikken om samme oprindelse forhindrer websteder fra ét domæne i at anmode om data, der tilhører et andet domæne.
Imidlertid, Helen Wang , seniorforsker i system- og netværksgruppen på Microsoft Research , forklarer, at samme oprindelsespolitik mislykkes ved at tvinge webapplikationer i dag til enten at ofre sikkerhed eller funktionalitet. Hun siger, at en masse fantastisk funktionalitet, såsom mashups, kommer fra at bruge værktøjer fra flere kilder. Problemet er, at når webstedsskaberen indlejrer kode skrevet af en tredjepart på hendes websted, tilbyder samme oprindelsespolitik ikke længere nogen beskyttelse, og den indlejrede kode har sandsynligvis adgang til oplysninger, der er gemt på skaberens websted. For eksempel, hvis skaberen af et forum indlejrer en kortlægningsapplikation på sit websted, kan koden i kortlægningsapplikationen potentielt få adgang til login-data for forummet. Mashup-producenter, siger Wang, opgiver enten sikkerheden ved at acceptere disse risici og stole på tredjepartsværktøjer, eller de opgiver funktionalitet ved at nægte sig selv at bruge værktøjer, der ikke er tillid til.
Chuck Willis, hovedsikkerhedskonsulent for Mandiant , et informationssikkerhedsfirma, siger, at mange udviklere gerne vil se nogle af kontrollerne, såsom politikken for samme oprindelse, lempet. Den gennemsnitlige bruger har brug for, at tingene forbliver, som de er, siger han, da de fleste brugere ikke forstår konsekvenserne af at give adgang til tredjepartsværktøjer. Men bestræbelser på at lempe eksisterende beskyttelser skal behandles med forsigtighed.
Microsofts Wang har arbejdet på at løse problemet ved at give browsere mulighed for at genkende kode, der kommer fra en tredjepart, og behandle denne kode anderledes end den fra værtswebstedet. Hun foreslår at vedlægge tredjepartskode i et sandkassemærke, som ville fungere som en slags envejsglas. Det ville gøre det muligt for det større websted at gøre brug af koden indeholdt i sandkassen, men behandle denne kode som uautoriseret indhold uden autoritet uden for sandkassen. Enhver information, som tredjepartskoden krævede, kunne inkluderes i sandkassen. Men for at denne løsning skal være effektiv, skal sandbox-tagget blive en accepteret webstandard. Wang har bygget en prototype af Internet Explorer, der genkender tagget, men hun bemærker, at det ville tage tid for tagget at blive adopteret i alle browsere.
Tidligere på måneden udgav IBM et sikkerhedsværktøj kaldet SMash (forkortelse for sikre mashups), der har til formål at løse problemet uden at ændre browseren. SMash tillader, at indhold fra flere kilder vises på en enkelt side, og det gør det muligt for værktøjer at kommunikere på en sikker måde, forklarer Larry Koved, Web 2.0-sikkerhedsforsker for IBM Research. En sikker kommunikationskanal overvåger information sendt mellem værktøjer, mens de stadig bevarer deres separate identiteter og separate sæt tilladelser. En mashup-skaber, der bruger SMash, forbinder hvert værktøj til en hub, der derefter tager ansvaret for at overvåge de beskeder, der sendes mellem værktøjer, på udkig efter mistænkelig aktivitet. Koved siger, at hvert værktøj, der er inkluderet i mashup'en, kan kontrollere, hvordan dets data transformeres og præsenteres.
SMash, siger Boloker, bytter muligheden for tæt sammenkobling af widgets i en mashup for at holde den sikker og nem at lave. IBM planlægger at inkorporere SMash i sit Lotus Mashups-produkt, der udkommer til sommer, og virksomheden har også doneret koden til OpenAjax Alliance, som giver enhver mashup-producent mulighed for at bruge den.
Chris Warner, marketingdirektør hos mashup maker JackBe , siger om eksisterende tilbud, Generelt er mashup-sikkerhed stadig lidt af et vilde vesten. Som medlem af OpenAjax Alliance, siger han, planlægger JackBe at støtte SMash og andre standarder, der er frigivet gennem alliancen. Han tilføjer, at det næste skridt for mashup-industrien er at sikre, at vi udvikler et universelt billede af sikkerhed.