Webontwikkelaars moeten meer aandacht hebben voor technologie achter de zogenoemde Spectre-kwestbaarheden voor processors. Deze kwetsbaarheden maakt een einde aan oude bedreigingsmodellen, zodat ontwikkelaars nu vaker code moeten gaan schrijven voor de nieuwe situatie. Een engineer van Google heeft een vijftal concrete aanbevelingen gepresenteerd.
In 2018 werd de IT-industrie opgeschrikt door de ontdekking van de zogenoemde Spectre-kwetsbaarheden voor moderne processors. Deze kwetsbaarheden maakten side-channelaanvallen mogelijk, waardoor gevoelige data ongezien kon weglekken. Hackers gebruikten hiervoor de functionaliteit waarmee processors toekomstige instructies voorspellen.
De grote chipsetfabrikanten en leveranciers van besturingssystemen hebben hiervoor inmiddels voldoende maatregelen genomen. Onder meer door firmware patches, updates van kernels en het tegengaan van timers in webbrowsers.
Beurt aan de webontwikkelaars
Volgens webbeveiligingspecialisten is het nu echter de beurt aan de ontwikkelaars. Concreet moeten zij de manier waarop zij code voor webapplicaties en webbrowsers aanpassen volgens ‘oude’ bedreigingsmodellen vervangen door nieuwe code die zich aan de post-Spectre situatie heeft aangepast. Kortom, oude securitycode voor websites en browsers voldoet niet meer en moet door nieuwe code worden vervangen.
Nieuwe aanbevelingen voor webontwikkelaars
Zowel een security engineer van Google, Mike West, als een vertegenwoordiger van W3C’s Web Application Security Working Group bepleiten daarom een nieuw set van aanbevelingen voor deze nieuwe securitycode voor webapplicaties en -browsers. Deze aanbevelingen moeten zijn gebaseerd op best practices.
Volgens West toont de Spectre-affaire aan dat de basis van het websecurity-model een opfrissing nodig heeft. Zo moet bijvoorbeeld het open source browser project begrijpen dat actieve webcontent nu in staat is om alle data te lezen in de adresruimte van het gehoste proces. Dit betekent dat voor browsers projecten als Site Isolation en Project Fission moeten worden uitgevoerd. Deze functionaliteit zorgt ervoor dat website en de code die daarbij hoort in aparte processen wordt geplaatst, zodat de websites geen invloed op elkaar hebben.
Vijf aanbevelingen
De implementatie van deze functionaliteit betekent wel dat ontwikkelaars veel codeerwerk staat te wachten. Gelukkig is volgens Mike West van Google wel een redelijke hoeveelheid direct bruikbare oplossingen beschikbaar en preventief kunnen worden ingezet.
Voor het vergemakkelijken van de implementatie van deze oplossingen, introduceert West daarom een vijftal aanbevelingen.
Ten eerste moeten ontwikkelaars bepalen of hun code wel of niet antwoord geeft aan inkomende verzoeken. Dit door binnenkomende request headers te onderzoeken op basis van de verlangde isolatievereisten voor de diverse bronnen. Ten tweede moet een zogenoemde ‘cross-origin resource policy (CORP)’ worden opgezet. Hierdoor kunnen hackers geen data als een subbron offloaden.
De derde aanbeveling is dat ontwikkelaars ervoor zorgen dat websitedata niet kan worden ‘geframed’ door de framingbescherming te manipuleren. Als vierde aanbeveling moeten ontwikkelaars er zeker van zijn dat hackers geen referentie of ‘handle’ naar een window object van de betreffende website krijgen. Dit door een ‘cross-origing opener policy (COOP) in te voeren. De laatste aanbeveling is dat ontwikkelaars beveiligingen moeten instellen tegen MIME-type confusion-aanvallen die ‘cross-origin read blocking’ (CORB) en ‘opaque response blocking’ (ORB) gebruiken. Bijvoorbeeld door de juiste defensieve Content-Type headers te implementeren.
Tip: ‘Spectre terug als exploit voor Windows- en Linux-apparaten’
16 uur geleden
