ENISA finder sikkerhedsbrister i HTML5-standarder

For eksempel giver HTML5 mulighed for at placere en submit-knap til en webform hvor som helst på en hjemmeside, hvilket gør det nemmere at foretage et angreb, der indsætter en ny knap og indsender dataene i formen til angriberen i stedet for den tilsigtede hjemmeside. ENISA mener, at fordelene for udviklere er store, og foreslår derfor ikke, at muligheden fjernes, men blot at man gør brugerne opmærksomme på den eventuelle sikkerhedsbrist.

Hvilket man sjovt nok også kan i HTML4 og XHTML 1.0... dvs i ALLE NUVÆRENDE HTML versioner !...

er de dumme eller hvad ?

myBtn.onclick = document.MyForm.submit();

Nyheden skrev:

men blot at man gør brugerne opmærksomme på den eventuelle sikkerhedsbrist.

O_o

Jeg forventer en enorm stigning i mængden af fremtidige fejl-40....

Sikkerhedshuller er ok, så længe brugeren godt ved de er der?!?

HenrikH (2) skrev:

Sikkerhedshuller er ok, så længe brugeren godt ved de er der?!?

Brugerne af HTML5 må i den sammenhæng betyde dem der genererer HTML5 dokumenter.

Det svarer vel lidt til, at en lås godt må være defekt, så længe at låsesmeden er klar over det?

Forventes det så bare, at alle der designer hjemmesider ikke benytter de funktioner der er sikkerhedsbrister i? Say, alle stopper med at bruge forms?

Åhh nej! Hvem har dog fundet på at man kan lave en submit-knap hvor som helst!?!?! Den skal jo sidde i det nedre højre hjørne -.-'

Hvem helvede er ENISA? Og hvorfor skal de dog gøre os (Europa) til grin?

Nicolai (5) skrev:

Hvem helvede er ENISA? Og hvorfor skal de dog gøre os (Europa) til grin?

Umm gider du læse linie 1 i newz.dk's resume ;)

Men igen, så er HTML5 jo kun i udkast, så fint at de er vågne og kan sende forslag til forbedringer inden den endelige version.

Damn, nåede lige netop ikke at rette mit første indlæg, men:

For eksempel giver HTML5 mulighed for at placere en submit-knap til en webform hvor som helst på en hjemmeside, hvilket gør det nemmere at foretage et angreb, der indsætter en ny knap og indsender dataene i formen til angriberen i stedet for den tilsigtede hjemmeside.

NEJ. Kilden indeholder samme misforståelse. At man introducere HTML5 i brugerens browser, gør det ikke nemmere at 'injicere' (inject) fjendtligt HTML kode på serveren! (Hvorfor skulle det dét?). Jeg har ikke læst ENISA's dokument, men jeg går stærkt ud fra at det som de (ENISA) kritisere, er at HVIS man kan få fjendtligt HTML kode ind på serveren, så kan man "stjæle" en form ved at lave sin egen submit-knap. Meeen, det hvis man kan få fjendtligt HTML kode ind på serveren, så kan man da også bare lave en script til at stjæle formen...?

Nicolai (7) skrev:

Damn, nåede lige netop ikke at rette mit første indlæg, men:
NEJ. Kilden indeholder samme misforståelse. At man introducere HTML5 i brugerens browser, gør det ikke nemmere at 'injicere' (inject) fjendtligt HTML kode på serveren! (Hvorfor skulle det dét?). Jeg har ikke læst ENISA's dokument, men jeg går stærkt ud fra at det som de (ENISA) kritisere, er at HVIS man kan få fjendtligt HTML kode ind på serveren, så kan man "stjæle" en form ved at lave sin egen submit-knap. Meeen, det hvis man kan få fjendtligt HTML kode ind på serveren, så kan man da også bare lave en script til at stjæle formen...?

Man kan nøjes med at manipulere indholdet client-side med XSS.

Det de brokker sig over, er at sikkerheden omkring det ikke er blevet bedre i HTML5

Jamen lad dog ENISA få det som de vil have det - advar brugeren på side 17 i den 30 siders lange EULA man alligevel klikker "I agree" til under installation af browsere.

End of story and everyone are happy :)

CarstenLorentzen (8) skrev:

Det de brokker sig over, er at sikkerheden omkring det ikke er blevet bedre i HTML5

Mulighed for injektion af html kode er en fejl i softwaren på serversiden. En ændring af html formatet kan hverken introducere den mulighed eller fjerne den.

Når man behandler data på serversiden er man nødt til at bruge den rigtige escaping. Hvis man vil gøre det nemmere er det de sprog man bruger på serversiden, der skal ændres på. Det er uafhængigt af det specifikke format af html koden.

Hvis først der er et hul kan der dog stadig være forskel på hvor nemt det er at udnytte. Kan den injektede kode tilgå forms andre steder på siden gør det angreb lidt nemmere, men det kræver stadig at man finder et hul.

Man kan sammenligne det med udnyttelse af buffer overflows og andre oldschool sikkerhedshuller. Man kan randomisere memory layout, fjerne execute rettigheder på stack og andre data mappings, fjerne mulighed for at mappe på NULL adressen og gøre meget andet for at gøre det sværere at udnytte.

Det ændrer ikke ved at et hul er et hul, og hullet skal lukkes. Er der ingen huller er de andre foranstaltninger overflødige. Er der et hul er de andre foranstaltninger utilstrækkelige og hullet skal lukkes alligevel. Foranstaltningerne er altså af begrænset værdi, og man må opveje den værdi imod ulemperne.

Randomiseret memory layout gør debugging sværere. Manglende execute rettigheder på stakken er et problem for kode, der bruger trampoliner. Ingen mulighed for at mappe på NULL adressen gør det umuligt at opnå så høj kompatibilitet med ældre kode. Manglende mulighed for at referere andre dele af et html dokument gør det sværere at udvikle webapplikationer.

https