Chrome patcher 24 sikkerhedshuller, muliggør "Sanitizer" sikkerhedssystem

Googles nyeste Chrome-browser, udgave 105, er ude, selvom det fulde versionsnummer er irriterende forskelligt alt efter om du er på Windows, Mac eller Linux.

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

Ifølge Google indeholder denne nye version 24 sikkerhedsrettelser, selvom ingen af ​​dem er rapporteret som "in-the-wild", hvilket betyder, at der ikke var nogen nul-dage rettet denne gang.

Ikke desto mindre er der én sårbarhed kaldet Kritisk, og yderligere otte bedømte Høj.

Af de fejl, der blev rettet, skyldes lidt over halvdelen af ​​dem hukommelsesfejl, med ni opført som bruge efter frigivelse bugs, og fire som heap buffer overløb.

Hukommelsesfejltyper forklaret

A bruge efter frigivelse er præcis, hvad der står: du afleverer hukommelse for at frigøre den til en anden del af programmet, men fortsætter alligevel med at bruge den, og dermed potentielt forstyrre den korrekte drift af din app.

Forestil dig for eksempel, at den del af programmet, der mener, at den nu har eneadgang til den stødende hukommelsesblok, modtager noget upålideligt input og omhyggeligt verificerer, at de nye data er sikre at bruge...

…men så, i det øjeblik før den begynder at bruge det validerede input, forstyrrer din buggy "brug-efter-fri"-kode og injicerer forældede, usikre data i den samme del af hukommelsen.

Pludselig opfører sig fejlfri kode andre steder i programmet, som om den selv var buggy, takket være fejlen i din kode, der lige gjorde det, der var i hukommelsen, ugyldig.

Angribere, der kan finde ud af en måde at manipulere timingen for din kodes uventede indgreb, kan muligvis ikke kun nedbryde programmet efter forgodtbefindende, men også fravride kontrollen fra det og dermed forårsage, hvad der er kendt som fjern kodeudførelse.

Og a heap buffer overløb henviser til en fejl, hvor du skriver flere data til hukommelsen, end der passer til den plads, der oprindeligt blev tildelt dig. (bunke er jargonbegrebet for samlingen af ​​hukommelsesblokke, der i øjeblikket administreres af systemet.)

Hvis en anden del af programmet har en hukommelsesblok tilfældigvis er tæt på eller ved siden af ​​din i dyngen, så vil de overflødige data, som du lige har skrevet ud, ikke flyde uskadeligt over i ubrugt plads.

I stedet vil det ødelægge data, der er i aktiv brug et andet sted, hvilket svarer til det, vi lige har beskrevet for en brug efter-fri fejl.

"Sanitisizer"-systemet

Heldigvis har Google udover at rette fejlfunktioner, der slet ikke skulle være der, annonceret ankomsten af ​​en ny funktion, der tilføjer beskyttelse mod en klasse af browserfejl kendt som scripting på tværs af websteder (XSS).

XSS-fejl er forårsaget af, at browseren indsætter upålidelige data, f.eks. fra en webformular indsendt af en fjernbruger, direkte på den aktuelle webside uden først at tjekke efter (og fjerne) risikabelt indhold.

Forestil dig for eksempel, at du har en webside, der tilbyder at vise mig, hvordan en tekststreng efter mit valg ser ud i din funky nye skrifttype.

Hvis jeg skriver eksempelteksten Cwm fjord bank glyphs vext quiz (en konstrueret, men vagt meningsfuld mashup af engelsk og walisisk, der indeholder alle 26 bogstaver i alfabetet på kun 26 bogstaver, hvis du skulle undre dig), så er det sikkert for dig at sætte den præcise tekst ind på den webside, du opretter.

I JavaScript, for eksempel, kan du omskrive brødteksten på websiden sådan her, ved at indsætte den tekst, jeg har leveret, uden nogen ændring:

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

Men hvis jeg snød og bad dig om at "vise" tekststrengen Cwm fjord<script>alert(42)</script> i stedet ville det være hensynsløst for dig at gøre dette...

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

…fordi du ville tillade mig at injicere JavaScript-kode, der ikke er tillid til my vælger direkte ind din webside, hvor min kode kunne læse dine cookies og få adgang til data, der ellers ville være off-limits.

Så for at gøre det, der er kendt som rense dine input nemmere, Chrome har nu officielt aktiveret understøttelse af en ny browserfunktion kaldet setHTML().

Dette kan bruges til at skubbe nyt HTML-indhold gennem en funktion kaldet Sanitizer først, så hvis du bruger denne kode i stedet...

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

...så scanner Chrome den foreslåede nye HTML-streng for sikkerhedsproblemer først og fjerner automatisk al tekst, der kan udgøre en risiko.

Du kan se dette i aktion via Udvikler værktøjer ved at køre ovenstående setHTML() kode ved Konsol prompt, og derefter hente den faktiske HTML, der blev injiceret i document.body variabel, som vi gjorde her:

Selvom vi udtrykkeligt sætter en <script> tag i det input, som vi sendte til setHTML() funktion, blev scriptkoden automatisk slettet fra det output, der blev oprettet.

Hvis du virkelig har brug for at tilføje potentielt farlig tekst til et HTML-element, kan du tilføje et andet argument til setHTML() funktion, der specificerer forskellige typer risikabelt indhold, der skal blokeres eller tillades.

Som standard, hvis dette andet argument udelades som ovenfor, så fungerer Sanitizer på sit maksimale sikkerhedsniveau og renser automatisk alt farligt indhold, som den kender til.

Hvad skal jeg gøre?

• Hvis du er Chrome-bruger. Tjek, at du er opdateret ved at klikke Tre prikker > Hjælp > Om Google Chrome, eller ved at browse til den særlige URL chrome://settings/help.
• Hvis du er webprogrammør. Lær om det nye Sanitizer , setHTML() funktionalitet ved læsning råd fra Google og MDN Web Docs.

---

Forresten, hvis du er på Firefox, Sanitizer er tilgængelig, men er endnu ikke slået til som standard. Du kan slå den til for at lære mere om den ved at gå til about:config og skifte til dom.security.sanitizer.enabled mulighed for at true.

---