Chrome lapper 24 sikkerhetshull, muliggjør "Sanitizer" sikkerhetssystem

Googles nyeste Chrome-nettleser, versjon 105, er ute, selv om det fullstendige versjonsnummeret er irriterende forskjellig avhengig av om du bruker Windows, Mac eller Linux.

På Unix-lignende systemer (Mac og Linux), vil du 105.0.5195.52, men på Windows leter du etter 105.0.5195.54.

I følge Google inkluderer denne nye versjonen 24 sikkerhetsreparasjoner, selv om ingen av dem er rapportert som «i-the-wild», noe som betyr at det ikke var noen null-dager oppdatering denne gangen.

Likevel er det én sårbarhet kalt Kritisk, og ytterligere åtte vurdert Høy.

Av feilene som ble rettet, er litt over halvparten av dem på grunn av hukommelsesvansker, med ni oppført som bruk-etter-fri feil, og fire som haugbuffer renner over.

Minnefeiltyper forklart

A bruk-etter-fri er nøyaktig hva det står: du leverer tilbake minnet for å frigjøre det for en annen del av programmet, men fortsetter å bruke det likevel, og dermed potensielt forstyrre den korrekte driften av appen din.

Tenk deg for eksempel at den delen av programmet som tror den nå har eneste tilgang til den fornærmende minneblokken mottar upålitelige inndata, og verifiserer nøye at de nye dataene er trygge å bruke...

...men så, i øyeblikket før den begynner å bruke den validerte inngangen, forstyrrer buggy-koden din "bruk etter-fri" og injiserer foreldede, usikre data inn i den samme delen av minnet.

Plutselig oppfører feilfri kode andre steder i programmet seg som om den var buggy selv, takket være feilen i koden din som nettopp gjorde det som var i minnet ugyldig.

Angripere som kan finne ut en måte å manipulere tidspunktet for kodens uventede intervensjon kan være i stand til ikke bare å krasje programmet etter eget ønske, men også fravriste kontrollen fra det, og dermed forårsake det som er kjent som ekstern kjøring av kode.

Og a haugbufferoverløp refererer til en feil der du skriver mer data til minnet enn det som får plass i plassen som opprinnelig ble tildelt deg. (heap er sjargongbegrepet for samlingen av minneblokker som for øyeblikket administreres av systemet.)

Hvis en annen del av programmet har en minneblokk tilfeldigvis er i nærheten av eller ved siden av din i haugen, vil ikke de overflødige dataene du nettopp skrev ut, renne ufarlig over i ubrukt plass.

I stedet vil det ødelegge data som er i aktiv bruk et annet sted, noe som ligner på det vi nettopp beskrev for en bruk-etter-fri feil.

"Desinfisering"-systemet

Heldigvis, i tillegg til å fikse feilfunksjoner som ikke skulle være der i det hele tatt, har Google annonsert ankomsten av en ny funksjon som gir beskyttelse mot en klasse av nettleserfeil kjent som skripting på tvers av nettsteder (XSS).

XSS-feil er forårsaket av at nettleseren setter inn upålitelige data, for eksempel fra et nettskjema sendt inn av en ekstern bruker, direkte inn på gjeldende nettside, uten å se etter (og fjerne) risikabelt innhold først.

Tenk deg for eksempel at du har en nettside som tilbyr å vise meg hvordan en tekststreng etter eget valg ser ut i den funky nye fonten din.

Hvis jeg skriver inn eksempelteksten Cwm fjord bank glyphs vext quiz (en konstruert, men vagt meningsfull blanding av engelsk og walisisk som inneholder alle de 26 bokstavene i alfabetet på bare 26 bokstaver, i tilfelle du lurte), så er det trygt for deg å legge akkurat den teksten inn på nettsiden du oppretter.

I JavaScript, for eksempel, kan du omskrive hoveddelen av nettsiden slik, ved å sette inn teksten jeg har levert uten noen endring:

document.body.innerHTML = "Cwm fjord bank glyphs vext quiz"

Men hvis jeg jukset og ba deg om å "vise" tekststrengen Cwm fjord<script>alert(42)</script> i stedet ville det være hensynsløst av deg å gjøre dette...

document.body.innerHTML = "Cwm fjordalert(42)"

…fordi du vil tillate meg å injisere upålitelig JavaScript-kode av my velger direkte inn din nettside, hvor koden min kunne lese informasjonskapslene dine og få tilgang til data som ellers ville vært forbudt.

Så, for å gjøre det som er kjent som rense dine innganger enklere, Chrome har nå offisielt aktivert støtte for en ny nettleserfunksjon kalt setHTML().

Dette kan brukes til å presse nytt HTML-innhold gjennom en funksjon kalt Sanitizer først, slik at hvis du bruker denne koden i stedet...

document.body.setHTML("Cwm fjordalert(42)")

...så vil Chrome skanne den foreslåtte nye HTML-strengen for sikkerhetsproblemer først, og automatisk fjerne all tekst som kan utgjøre en risiko.

Du kan se dette i aksjon via Utviklerverktøy ved å kjøre ovenstående setHTML() kode på Konsoll ledetekst, og deretter hente den faktiske HTML-en som ble injisert i document.body variabel, som vi gjorde her:

Selv om vi eksplisitt setter en <script> taggen i innspillet som vi sendte til setHTML() funksjon, ble skriptkoden automatisk fjernet fra utdataene som ble opprettet.

Hvis du virkelig trenger å legge til potensielt farlig tekst i et HTML-element, kan du legge til et andre argument til setHTML() funksjon som spesifiserer ulike typer risikabelt innhold som skal blokkeres eller tillates.

Som standard, hvis dette andre argumentet utelates som ovenfor, opererer Sanitizer på sitt maksimale sikkerhetsnivå og fjerner automatisk alt farlig innhold den kjenner til.

Hva gjør jeg?

• Hvis du er en Chrome-bruker. Sjekk at du er oppdatert ved å klikke Tre prikker > Hjelp > Om Google Chrome, eller ved å bla til den spesielle URL-en chrome://settings/help.
• Hvis du er en nettprogrammerer. Lær om det nye Sanitizer og setHTML() funksjonalitet ved å lese råd fra Google og MDN Web Docs.

---

Forresten, hvis du bruker Firefox, Sanitizer er tilgjengelig, men er ennå ikke slått på som standard. Du kan slå den på for å lære mer om den ved å gå til about:config og veksle mellom dom.security.sanitizer.enabled alternativ til true.

---