Chrome lappar 24 säkerhetshål, möjliggör "Sanitizer" säkerhetssystem

Googles senaste Chrome-webbläsare, version 105, är ute, även om det fullständiga versionsnumret är irriterande olika beroende på om du använder Windows, Mac eller Linux.

På Unix-liknande system (Mac och Linux), vill du 105.0.5195.52, men på Windows letar du efter 105.0.5195.54.

Enligt Google innehåller den här nya versionen 24 säkerhetskorrigeringar, även om ingen av dem rapporteras som "in-the-wild", vilket innebär att det inte fanns några nolldagar som korrigerades den här gången.

Ändå finns det en sårbarhet dubbad Kritisk, och ytterligare åtta betygsatta Hög.

Av de brister som åtgärdades beror drygt hälften av dem på minnesfel, med nio listade som använd-efter-fri buggar, och fyra som högbuffert svämmar över.

Minnesbuggtyper förklaras

A använd-efter-fri är exakt vad det står: du lämnar tillbaka minnet för att frigöra det för en annan del av programmet, men fortsätter att använda det ändå, vilket potentiellt stör den korrekta driften av din app.

Föreställ dig till exempel att den del av programmet som tror att den nu har ensam tillgång till det stötande minnesblocket får lite otillförlitlig input och noggrant verifierar att den nya datan är säker att använda...

…men sedan, i ögonblicket innan den börjar använda den validerade ingången, stör din buggy "use-after-free"-kod och injicerar inaktuella, osäkra data i samma del av minnet.

Plötsligt beter sig buggfri kod på andra ställen i programmet som om den var buggig, tack vare felet i din kod som just ogiltigförklarade det som fanns i minnet.

Angripare som kan komma på ett sätt att manipulera tidpunkten för din kods oväntade ingripande kan kanske inte bara krascha programmet efter behag, utan också ta kontrollen från det, vilket kan orsaka vad som kallas extern kod exekvering.

Och a hög buffertspill hänvisar till en bugg där du skriver mer data till minnet än vad som får plats i det utrymme som ursprungligen tilldelades dig. (heap är jargongtermen för samlingen av minnesblock som för närvarande hanteras av systemet.)

Om någon annan del av programmet har ett minnesblock bara råkar vara nära eller bredvid ditt i högen, kommer den överflödiga data som du just skrev ut inte att svämma över ofarligt till oanvänt utrymme.

Istället kommer det att korrumpera data som är i aktiv användning någon annanstans, vilket liknar konsekvenserna som vi just beskrev för en användning efter-fri bugg.

"Desinficeringssystemet".

Lyckligtvis har Google, förutom att åtgärda felfunktioner som inte alls skulle finnas där, meddelat ankomsten av en ny funktion som lägger till skydd mot en klass av webbläsarbrister som kallas cross-site scripting (XSS).

XSS-buggar orsakas av att webbläsaren infogar opålitlig data, till exempel från ett webbformulär som skickats in av en fjärranvändare, direkt i den aktuella webbsidan, utan att först leta efter (och ta bort) riskfyllt innehåll.

Föreställ dig till exempel att du har en webbsida som erbjuder mig att visa mig hur en textsträng som jag väljer ser ut i ditt läckra nya typsnitt.

Om jag skriver in exempeltexten Cwm fjord bank glyphs vext quiz (en konstruerad men vagt meningsfull mashup av engelska och walesiska som innehåller alla 26 bokstäverna i alfabetet på bara 26 bokstäver, om du undrade), då är det säkert för dig att lägga in den exakta texten på webbsidan du skapar.

I JavaScript, till exempel, kan du skriva om webbsidans brödtext så här och infoga texten som jag angav utan några ändringar:

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

Men om jag fuskade och bad dig att "visa" textsträngen Cwm fjord<script>alert(42)</script> istället skulle det vara hänsynslöst av dig att göra det här...

document.body.innerHTML = " Cwm fjord alert(42) "

...för att du skulle tillåta mig att injicera opålitlig JavaScript-kod av my väljer direkt in ditt webbsida, där min kod kan läsa dina cookies och komma åt data som annars skulle vara förbjudna.

Så, för att göra vad som är känt som sanera dina ingångar enklare, Chrome har nu officiellt aktiverat stöd för en ny webbläsarfunktion som heter setHTML().

Detta kan användas för att skicka nytt HTML-innehåll genom en funktion som kallas Sanitizer först, så att om du använder den här koden istället...

document.body.setHTML(" Cwm fjord alert(42) ")

… då ska Chrome först skanna den föreslagna nya HTML-strängen efter säkerhetsproblem och automatiskt ta bort all text som kan utgöra en risk.

Du kan se detta i aktion via Utvecklarverktyg genom att köra ovanstående setHTML() kod vid Konsol uppmaning och sedan hämta den faktiska HTML som injicerades i document.body variabel, som vi gjorde här:

Även om vi uttryckligen sätter en <script> taggen i ingången som vi skickade till setHTML() funktion, rensades skriptkoden automatiskt från utdata som skapades.

Om du verkligen behöver lägga till potentiellt farlig text i ett HTML-element kan du lägga till ett andra argument till setHTML() funktion som specificerar olika typer av riskfyllt innehåll att blockera eller tillåta.

Som standard, om detta andra argument utelämnas enligt ovan, fungerar Sanitizer på sin maximala säkerhetsnivå och rensar automatiskt allt farligt innehåll som den känner till.

Vad göra?

• Om du är en Chrome-användare. Kontrollera att du är uppdaterad genom att klicka Tre prickar > Hjälp > Om Google Chrome, eller genom att bläddra till den speciella URL:en chrome://settings/help.
• Om du är en webbprogrammerare. Lär dig mer om det nya Sanitizer och setHTML() funktionalitet genom att läsa råd från Google och MDN -webbdokument.

---

Förresten, om du använder Firefox, Sanitizer är tillgänglig, men är ännu inte aktiverad som standard. Du kan aktivera den för att lära dig mer om den genom att gå till about:config och växla mellan dom.security.sanitizer.enabled alternativ till true.

---