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

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.

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?

Hvad er det forskel fra standarden?

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

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?

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.

Kort fortalt: indsæt en checksum af al javascript med et salt der bliver tilfældigt genereret når siden indlæses.

Hvad er det forskel fra standarden?

https://www.owasp.org/index.php/List_of_useful_HTTP_headers

Med Content Security Policy kan man allerede lave en hash af javascripten som man serverer. Det er Candidate Recommendation.

https://www.w3.org/TR/CSP/#script-src-hash-usage

@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.

... 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 :-) ).

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.

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.

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?

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 ?

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

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.ashx?la=da

Artiklen er noget vag omkring hvad det reelt handler om - kunne vi her på v2, hvor antagelsen vel er at modtageren er IT professionel, ikke få lidt flere tekniske detaljer?