Chrome gaat Safe Browsing voortaan niet meer vóór het laden van sites inzetten

Google wil de Safe Browsing-functionaliteit in Chrome in de toekomst later laten inladen. Nu doet Chrome dat al voordat een website is geladen, maar Google wil dat gelijktijdig doen met het laden van een site zelf.

Google schrijft in een blogpost dat het die wijziging wil doorvoeren in Chrome 122, die inmiddels als bèta uit is. Google gaat daarin een 'asynchrone check' met de Safe Browsing API v4 inzetten. Dat is een feature die ingeladen websites controleert op bijvoorbeeld phishing, malware of andere exploits. Nu wordt Safe Browsing ingezet voordat de website wordt ingeladen, maar Google gaat dit synchroon doen met het laden van de website zelf. Volgens Google maakt dat het laden van websites sneller. "We verwachten dat dit paginalaadtijden reduceert en de gebruikerservaring verbetert omdat realtime serversidechecks de laadtijden niet meer vertragen."

Volgens Google worden pagina's nog steeds wel achteraf geblokkeerd of van een waarschuwing voorzien. Het kan daardoor wel voorkomen dat gebruikers een foute website zien voordat die geblokkeerd kan worden. Google blijft een lokale check inladen met een lijst met websites waarvan bekend is dat ze exploits bevatten.

Verder gaat Google geen controle meer doen op de URL's van subresources, zoals elementen die via een cdn worden ingeladen. Volgens het bedrijf is dat niet langer relevant, omdat grootschalige cybercrimecampagnes bijna nooit meer gebruikmaken van zulke subresources. Tot slot gaat Chrome geen Safe Browsing meer gebruiken om pdf's te controleren voor die worden gedownload. Ook dat is volgens Google minder relevant geworden. "Onder andere door het verbeteren van de veiligheid van pdf-lezers zien we weinig wijdverspreide exploitatie via pdf's meer", zegt het bedrijf. Het verwijst naar het feit dat de ingebouwde pdf-lezer in Chrome in een sandbox wordt ingeladen.

Reacties (25)

[Mars4i]

Van de blog:

In addition to the performance boost, this change will let us improve the quality of protection over time. By taking the remote lookup outside of the blocking path of the page load, we're now able to experiment with and deploy novel AI and ML based algorithms to detect and block more phishing and social engineering attacks. It was previously challenging to perform such experimentation because of the potential to delay page loads.

Zo klinkt het bijna alsof ze pagina's verder willen laten laden zodat ze hun nieuwe AI en ML algoritmes beter kunnen trainen op phishing en social engeneering aanvallen. Maar wel vreemd dat ze dit dan op alle browsers bij gebruikers gaan doen. Kunnen ze beter op hun eigen afgesloten testsystemen doen lijkt me.

[CAPSLOCK2000]

Zo klinkt het bijna alsof ze pagina's verder willen laten laden zodat ze hun nieuwe AI en ML algoritmes beter kunnen trainen op phishing en social engeneering aanvallen. Maar wel vreemd dat ze dit dan op alle browsers bij gebruikers gaan doen. Kunnen ze beter op hun eigen afgesloten testsystemen doen lijkt me.

Ik lees dat citaat als "AI is nog te langzaam". Daarom wachten ze niet op het antwoord van de AI maar gaan ze alvast verder terwijl de AI nog staat te pruttelen.

Het roept bij mij wel de vraag op hoeveel data Google ontvangt op deze manier. Ik dacht dat SafeBrowsing dusver lokaal in je eigen browser draaide en geen informatie deelde met Google.
Nu kun je AI ook lokaal draaien maar Google het heeft over een "remote lookup", daarom denk ik dat dit gewoon bij Google in de cloud draait. Dan moet er dus data van je browser naar Google stromen bij iedere pagina die je bezoekt.

[djwice]

Ik lees het meer als: als je als hacker weet hoe lang de detectie algoritmes kijken, wacht je met het inladen van malafide dingen. Idem met IP-adressen van Google etc.

Sommige aanvallen zijn doel gericht, en worden dus niet geladen als niet aan bepaalde voorwaarden is voldaan.
Dat is lastig om in het lab dan te triggeren.

In de cliënt heb je meer kans dat een klant wel aan de voorwaarden voldoet. Waar je dan van kan leren.
Met 3,3 miljard publieke web pagina's op internet moet je best veel puppeteer browsers draaien om alle voorwaarden voor een aanval te simuleren.
Als die worden gecombineerd met server side trucjes is het helemaal lastig de juiste condities te triggeren (denk aan redirect based profiling cookies, human swipe of scroll detectie etc.)

[Reactie gewijzigd door djwice op 23 juli 2024 01:36]

[wildhagen]

Volgens Google worden pagina's nog steeds wel achteraf geblokkeerd of van een waarschuwing voorzien. Het kan daardoor wel voorkomen dat gebruikers een foute website zien voordat die geblokkeerd kan worden.

Leuk dat hij achteraf geblokkeerd wordt, maar dan kan het kwaad dus al geschied zijn, en er dus een exploit geactiveerd zijn als die nog niet op de lijst met 'known exploits' staan en die exploit actief wordt vóór de SafeBrowsing-check uitgevoerd wordt..

Fijn dat het laden van de website dan iets sneller gaat, maar dat gaat dan wel ten koste van de veiligheid.

Ik weet niet of dat nou een heel erg goede deal en keuze is om het op deze manier te doen?

[Remc0_]

Als de website een zero day gebruikt, hoe zou SafeBrowsing dan weten dat het deze moet blokkeren?

[wildhagen]

Dat kan bijvoorbeeld op basis van heuristic analyse, zo werken malware-scanners ook (onder andere) bijvoorbedld. Dan kijken ze dus naar het gedrag van een website, script, programma etc om te bepalen of het potentieel verdacht is of niet.

Mogelijk heeft Safe Browsing nog andere technieken die ze hiervoor gebruiken, daarvoor ken ik het niet goed genoeg verder.

[kuurtjes]

On Google Chrome, Enhanced Safe Browsing users will benefit from the following additional protections:

Real-time checks against lists of known phishing and malware sites
The option to request Google to perform deeper scans of files they’ve downloaded to check for malware and viruses
Protection against previously unknown attacks when navigating to sites
Tailored protections based on your risk level

Across other Google products, Enhanced Safe Browsing users will benefit from additional protections:

Strengthened protections in GMail including additional checks on attachments and web links
Tailored protection if an attack is detected on the account

Ik denk om eerlijk te zijn dat alleen de "lists of known phishing and malware sites" de moeite waard is.

[Rob Coops]

Dat hangt er van af waneer de check gedaan wordt als Chrome de code in van de site niet uitvoert voor de safebrowsing feature het groene licht heeft gegeven dan is er niets aan de hand.

Waar het Google om gaat is dat je de pagina op het scherm ziet in minder tijd dan nu het geval is. Als de code een paar ms later start dat is niet een ramp er zijn immers vrijwel geen mensen die zo snel dingen met een pagina zullen doen dat ze daar "last" van zullen hebben.

Het geen wat ik wel een beetje eng vind is het idee dat sub-url's niet meer gecontroleerd zullen worden want niemand maakt er meer gebruik van voor hun exploits. Dat men het niet meer gebruikt is omdat Chrome de overgrote meerderheid van de exploits toch wel stopt en er dus geen voordeel is in het laden van een exploit via een cdn. Als ik weet dat Google niet meer naar cdn's kijkt dan lijkt het me logisch dat ik juist daar mijn exploit laad omdat ik dan lekker makkelijk om de safebrowsing check van chrome heen kan werken.

Maar goed ik heb zo'n vermoeden dat men bij Google wel een beetje weet wat men doet en dat men hier redelijk wat tijd aan besteed heeft om er zeker van te zijn dat dit echt een goed idee is. Maar zeker het cdn idee denk ik dat ze nog wel eens op terug zullen komen want dat klinkt heel erg naar vragen om een probleem.

[Joshuffle]

Maar goed ik heb zo'n vermoeden dat men bij Google wel een beetje weet wat men doet en dat men hier redelijk wat tijd aan besteed heeft om er zeker van te zijn dat dit echt een goed idee is.

Naja, ze weten een beetje wat men doet ja, maar misschien iets minder dan we hopen:
https://killedbygoogle.com/

[curkey]

Ik weet niet of het puur code is waar 'iets' mee kan zijn. Er waren ook exploits via geprepareerde plaatjes, bv door bugs in een jpeg bibliotheek.

[Bender]

Volgens mij kan een exploit pas gebruikt worden bij het renderen van de binnengekomen data en niet bij de request zelf.

Dus op zich is er niks aan de hand zolang de code niet uitgevoerd wordt?

(maar verbeter me vooral als het anders is)

[djwice]

Je hebt hier een valide punt. Windows 2000 had in de eerste release de validatie van SMB verzoeken en authorisatie parallel in uitvoer, de aanname was dat de authorisatie check sneller was en dus het uitvoeren van het commando tijdig kon worden tegen gehouden.

Dat was waar totdat je eerst het autorisatie systeem overspoelde met verzoeken en daarna een kort commando gaf om jezelf admin te maken....

[Verwijderd]

"Verder gaat Google geen controle meer doen op de url's sub-resources, zoals elementen die via een cdn worden ingeladen. Volgens het bedrijf is dat niet langer relevant, omdat grootschalige cybercrimecampagnes bijna nooit meer gebruikmaken van zulke sub-resources."

tot nu dus.

[graey]

Ik vind ook het woordje 'bijna' in die afweging wat spannend, soms dus wel, en nu staat het straks voor bijna iedereen standaard uit.

[Vexxon]

Inderdaad, wat een naïeve instelling van Google.

[Bor]

Hoe erg vertraagt deze functionaliteit momenteel nu echt? Ik lijk er niets van te merken in de meeste gevallen. Natuurlijk zal er achter deze keuze een goede risico afweging zitten maar toch voelt het wat vreemd om te kiezen voor mogelijk misbruik met als voordeel een mogelijk marginale snelheidswinst. Hopelijk komen er policy instellingen om controle vooraf toch af te dwingen waar je bijvoorbeeld in een bedrijfsomgeving gebruik van kan maken.

Verder gaat Google geen controle meer doen op de url's sub-resources, zoals elementen die via een cdn worden ingeladen. Volgens het bedrijf is dat niet langer relevant, omdat grootschalige cybercrimecampagnes bijna nooit meer gebruikmaken van zulke sub-resources.

Is het met een stelling als dit geen kwestie van tijd totdat dit wel weer gebruikt gaat worden wanneer duidelijk is dat je op die manier onder bepaalde controles uit kan komen?

[Martinspire]

Dit klinkt echt als een hele domme actie. Het zal mij nou niet meer verbazen als deze feature binnen korte tijd helemaal de nek om wordt gedraaid. Terwijl een veilig web in het voordeel is van Google zelf.

[david-v]

Chrome gaat Safe Browsing voortaan niet meer vóór het laden van sites inzetten

En in de eerste paragraaf staat

Google wil de Safe Browsing-functionaliteit in Chrome in de toekomst later laten inladen. Nu doet Chrome dat pas nadat een website is geladen

Wat is het nou, vóór of ná het laden van pagina's?

[dreester]

"Niet meer vóór het laden van sites" en "pas nadat een website is geladen" is toch hetzelfde?

[watercoolertje]

Precies zijn punt, alleen de ene opmerking gaat over nu en de andere over de toekomst. Als er hetzelfde gezegd wordt over nu als over de toekomst dan veranderd er dus niks, en dat klopt dus niet want dan was er geen artikel/nieuws

Maar deze zin uit het artikel gaat dus niet op, nu gebeurd het vooraf en niet achteraf!

Nu doet Chrome dat pas nadat een website is geladen

[Reactie gewijzigd door watercoolertje op 23 juli 2024 01:36]

[david-v]

het verwarrende is dat ze het in beide gevallen hebben over hoe het nu is. In de eerste paragraaf moet dan toch ook staan:

Google wil de Safe Browsing-functionaliteit in Chrome in de toekomst later laten inladen. Nu doet Chrome dat voordat een website is geladen

Ik had echt moeite om zowel de titel als de eerste paragraaf te lezen omdat ze elkaar tegenspreken.

[TijsZonderH]

Ik heb het aangepast, dank!

[Alxndr]

In de eerste alinea, tweede zin, zou 'pas' niet 'al' moeten zijn?

Ze gaan het later doen, niet eerder.

[voxl_]

Is dit niet gewoon een stap die ze zetten om deze functionaliteit sowieso uit de browser te halen? Waarna het is "nu werken adblockers niet meer want de API is weg"? Oepsie...

[Macron]

Klinkt net als "we stoppen met vaccineren want mensen krijgen de ziekte niet meer". Zo werkt dat dus niet.