It-studerende vinder ny cybersikkerhedspris for HTML-tjek imod malware

Tilføjelse til HTML standarden skal advare mod suspekte hjemmesider.

For første gang bliver der uddelt en dansk cybersikkerhedspris. Den uddeles af interesseorganisationen Dansk IT af en dommerkomite med medlemmer fra DTU og Center for Cybersikkerhed.

Førstepræmien og 25.000 kr. går til datalogistuderende Hauke Jan Lübbers for et projekt om at lade browsere advare mod malware-inficerede hjemmesider.

»Når man besøger en hjemmeside er det vigtigt, at man kan stole på, at den side, man besøger, er den, man tror den er, og ikke at nogen uautoriseret har været inde og pillet ved siden. Den prisvindende idé vil udvide HTML-standarden sådan, at det gøres muligt for browsere at kontrollere integriteten og ægtheden af koden. Hermed vil hjemmesiders integritet blive sikret,« siger Lars Ramkilde Knudsen, formand for DANSK IT’s udvælgelseskomite og professor på DTU i en pressemeddelelse.

Rammer et behov for et vurdere websites ægthed

Det er svært for internetbesøgende at vurdere ægtheden af en hjemmeside og helt umuligt at vurdere, om den er inficeret med malware. Det skal Lübbers ide ændre på ved at browseren tjekker alle sider.

En sådan advarsel skal sætte en stopper for stigningen af Water Hole angreb, hvor it-kriminelle angriber en virksomhed ved at placere skadelig kode på en fremmed hjemmeside, som man ved at offeret vil besøge.

Det næste skridt for Lübbers er at præsentere sin ide for World Wide Web Consortium, der er ansvarlige for at udvikle HTML-standarder. Hauke Jan Lübbers er ved at tage en kandidat som datalog på Københavns Universitet.

Cybersikkerhedsprisens premie er sponsoreret af virksomheden KPMG. Dansk IT håber på at tiltrække flere unge til cybersikkerhed branchen gennem de årlige kåringer.

Kommentarer (15)

Anders Søndergaard

Kort fortalt: indsæt en checksum af al javascript med et salt der bliver tilfældigt genereret når siden indlæses. Selvom man får held til at injicere javascript på siden, eksekveres det ikke, fordi webserveren ikke hasher det injicerede script.

Angriberen kan ikke injicere gyldigt indhold fordi saltet bliver fornyet ved hver page load.

Fundet på google (pdf):
https://www.dit.dk/~/media/Files/PDF/Pressemeddelelser%202015/proposal.a...

Jacob Pind

Virker lidt mystisk, så det er alene en beskyttelse mod xss hvilket normalt opstår ved kode fejl, så istedet for at rettet lad man dem bliver i ?

Bjarne Nielsen

Umiddelbart spiller det vidst ikke så godt sammen med cache servere..

Hvorfor ikke? Det er stadig muligt at verificeret at scripts loaded fra caches, inkl. browserens egen, er umodificerede. Det er klart, at en cached side ikke ændrer salt, men det betyder umiddelbart ikke noget for verifikationen?

Til gengæld er jeg ikke helt sikker på, at jeg fanger pointen med at salte. Er det mon fordi, at man er bange for at nogen skulle kunne finde og udnytte hashkollisioner?

Christian Nobel

Er der ikke noget med at Google arbejder hen mod at snart vil Chrome per default ikke acceptere HTTP, kun HTTPS?

Hvilket så, parret med at LetsEncrypt rigtig kommer i luften, gør mærkelige tiltag af denne slags inderligt overflødige.

Anders Søndergaard

Som jeg forstår det er pointen med saltet, at hvis ikke det ændrer sig, så kan angriberen bare lave en checksum af sin kode med det tidsuafhængige salt.
Så er man lige vidt.

Problemet med cachen er så, at saltet netop skal ændres hver gang siden loades,
for at metoden virker. Men ok, det er nok stadig besværligt/umuligt for en angiber at udnytte at cache serveren genbruger saltet på den statiske kopi af siden, den har gemt.

Bjarne Nielsen

... gør mærkelige tiltag af denne slags inderligt overflødige.

Ikke helt. For det vil stadig kunne give tillid til ressourcer, som i praksis ligger udenfor serverens rækkevidde, f.eks. hvis der bruges CDN. Du ved, at det script, som serveren forestiller sig (jfr. hashen) er identisk med det, som du får andetsteds.

Se f.eks. siden om Subresource Integrity hos MDN, hvor der beskrives en lignende løsning (dog uden salt - som jeg stadig ikke forstår nødvendigheden af :-) ).

Anders Søndergaard

@Bjarne
Subresource Integrity og det nye "HTML check" forsvarer ikke mod helt de samme typer angreb. HTML checket forsvarer mod at en angriber injicerer skadelig javascript kode ind i din hjemmeside via en eller anden XSS vektor. Det er meningen at browseren kun afvikler JS med en gyldig checksum, som ikke på forhånd kan udregnes. Subresource Integrity forhindrer ikke at der afvikles skadelig kode. Det forhindrer kun at allerede eksisterende filer ikke bliver modificeret af et CDN, og kun så længe HTML siden ikke selv bliver leveret fra det CDN. (CDN'en ville så også kunne ændre checksummer i HTMLen - der er ingen hemmelig nøgle involveret)

Det er i hvert fald sådan jeg læser beskrivelsen af de to metoder.

Ingen af metoderne garderer mod skadelige banner reklamer og andet tredjeparts indhold.

Rune Jensen
Rune Jensen

Problemet med cachen er så, at saltet netop skal ændres hver gang siden loades,

Jeg ville godt se et eksempel på, hvor det er implementeret. Problemet med randomness er netop, at det er random. Kunne man i stedet danne salt som et fingeraftryk af browseren, så ville man jo kunne cashe, fordi hver browser sender sit eget fingeraftryk hver gang. Det er bare ikke ligeså pålideligt selvfølgelig.

Bjarne Nielsen

HTML checket forsvarer mod at en angriber injicerer skadelig javascript kode ind i din hjemmeside via en eller anden XSS vektor.

Aha! Mekanismen baserer sig på, at alle scripts på siden skal have en checksum. Så tricket skal forhindre, at der smugles et ekstra script ind på siden via andet indhold. Den havde jeg ikke fanget. Det forklarer også saltet.

Det kunne nu også løses uden kryptografiske checksummer og andet cpu-krævende, hvis man unikt kunne identificere de enkelte scripts (med id f.eks.) og samtidig forlangte at de blev opremset i metatagget. Så skulle du ikke alene smugle tagget ind, men også modificere meta tagget (script id vil være en ændring til script tagget, men det er hashen også).

Med Content Security Policy kan man allerede lave en hash af javascripten som man serverer.

Identiteten kunne såmænd godt være en hash (og når den ikke er saltet, så kan den forudberegnes på serveren; det vigtige er, at den afkoblet fra script-tagget - og jeg er ikke så bekymret for lidt ekstra arbejde hos klienterne).

Er vi henne ved, at ideen ikke er særligt original?

Anders Søndergaard

Hvad er det forskel fra standarden?

Den standard du nævner tillader bl.a replay angreb, altså hvor allerede eksisterende scripts kan blive kørt igen. Det er heller ikke ufarligt. Der er også teoretisk set hash kollisioner og så kunne man måske forestille sig, at den header, der bliver brugt, også kunne injiceres. Måske..

Hvad er forskel så på standard X? Sikkert ikke stor. Ideen med checksums er ikke ligefrem ny.

Anders Søndergaard

Er vi henne ved, at ideen ikke er særligt original?

Det vil jeg være tilbøjelig til at mene. Der er i hvert fald ret meget ståen på kæmpers skuldre i det. Dermed ikke sagt at jeg synes forslaget er ubrugeligt.

Jeg vil også mene at det er mere vigtigt at clienten selv beskytter sig mod at afvikle farlig kode, gennem f.eks sandboxing, blokering og hvad man nu ellers har.
Standarden synes at lægge op til at, brugeren skal stole på, at samtlige websites opfører sig pænt. Det er selvfølgelig fint at webmasteren garderer sig mod XSS. Men det hjælper webmasteren mere end det hjælper brugeren.

Generelt synes jeg det er forstyrrende, at vi i dag har en kultur hvor det er helt naturligt at eksekverer arbitrær kode (endda fra skumle 3. parts sider) når man gør helt dagligdags ting som f.eks at tjekke sin netbank. Men det er vidst den generelle holdning her inde?

Martin Jünckow

Generelt synes jeg det er forstyrrende, at vi i dag har en kultur hvor det er helt naturligt at eksekverer arbitrær kode (endda fra skumle 3. parts sider) når man gør helt dagligdags ting som f.eks at tjekke sin netbank

Den kultur havde vi såmænd også tidligere, der var det bare i form af eksekverbar native kode man hentede eller overførte (eks. via disketter). Det er korrekt at vi midlertidigt havde et World Wide Web der bestod af meget tynde klienter, hvor HTML repræsenterede en formel specifikation og al logik blev afviklet på serveren, men den vision døde lidt efterhånden som websider begyndte at nærme sig applikationer og i mange tilfælde erstatte hvad vi tidligere afviklede som native applikationer.

Skal man vende det til noget positivt så må det være at den arbitrære 3. parts kode i det mindste er væsentlig bedre sandboxed idag end det tidligere har været tilfældet.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen