Verbeter de beveiliging van extensies

Verbetering van de beveiliging in Manifest V3

Opmerking: Manifest V3 wordt over het algemeen ondersteund in Chrome 88 of later. Voor extensiefuncties die zijn toegevoegd in latere Chrome-versies, raadpleegt u de API-referentiedocumentatie voor ondersteuningsinformatie. Als uw extensie een specifieke API vereist, kunt u een minimale Chrome-versie opgeven in het manifestbestand.

Dit is het laatste van drie secties waarin de wijzigingen worden beschreven die nodig zijn voor code die geen deel uitmaakt van de extension service worker. Het beschrijft de wijzigingen die nodig zijn om de beveiliging van extensies te verbeteren. De andere twee secties behandelen het bijwerken van uw code die nodig is voor de upgrade naar Manifest V3 en het vervangen van blokkerende webverzoeken .

Voorkom de uitvoering van willekeurige tekenreeksen.

Je kunt geen externe logica meer uitvoeren met executeScript() , eval() en new Function() .

• Verplaats alle externe code (JS, Wasm, CSS) naar je extensiebundel.
• Werk de script- en stijlreferenties bij om bronnen uit de extensiebundel te laden.
• Gebruik chrome.runtime.getURL() om resource-URL's tijdens runtime te genereren.
• Gebruik een iframe in een sandbox: eval en new Function(...) worden nog steeds ondersteund in iframes in een sandbox. Lees de handleiding over iframes in een sandbox voor meer informatie.

De methode executeScript() bevindt zich nu in de naamruimte scripting in plaats van de naamruimte tabs . Zie Verplaatsen van executeScript() voor meer informatie over het bijwerken van aanroepen.

Er zijn een paar speciale gevallen waarin het uitvoeren van willekeurige tekenreeksen nog steeds mogelijk is:

• Voeg extern gehoste stylesheets in een webpagina in met behulp van insertCSS.
• Voor extensies die gebruikmaken van chrome.devtools : inspectWindow.eval maakt het mogelijk om JavaScript uit te voeren in de context van de geïnspecteerde pagina.
• Debugger-extensies kunnen chrome.debugger.sendCommand gebruiken om JavaScript in een debugdoel uit te voeren.

Verwijder extern gehoste code

In Manifest V3 moet alle logica van je extensie deel uitmaken van het extensiepakket. Je kunt volgens het beleid van de Chrome Web Store geen extern gehoste bestanden meer laden en uitvoeren. Voorbeelden hiervan zijn:

• JavaScript-bestanden opgehaald van de server van de ontwikkelaar.
• Elke bibliotheek die op een CDN wordt gehost.
• Gebundelde bibliotheken van derden die dynamisch code ophalen die op een externe locatie wordt gehost.

Afhankelijk van uw specifieke toepassing en de reden voor het hosten op afstand, zijn er alternatieve benaderingen beschikbaar. In dit gedeelte worden de te overwegen benaderingen beschreven. Als u problemen ondervindt met het werken met code die op afstand wordt gehost, hebben we richtlijnen beschikbaar .

Configuratiegestuurde functies en logica

Uw extensie laadt en cachet een externe configuratie (bijvoorbeeld een JSON-bestand) tijdens de uitvoering. De gecachede configuratie bepaalt welke functies zijn ingeschakeld.

Externe logica met een externe service

Je extensie roept een externe webservice aan. Hierdoor kun je je code privé houden en deze naar behoefte aanpassen, zonder de extra kosten van het opnieuw indienen bij de Chrome Web Store.

Sluit extern gehoste code in een afgeschermde iframe in.

Code die op afstand wordt gehost, wordt ondersteund in iframes die in een sandbox zijn opgeslagen . Houd er rekening mee dat deze aanpak niet werkt als de code toegang nodig heeft tot de DOM van de pagina waarin deze wordt ingesloten.

Bundel bibliotheken van derden

Als je een populair framework zoals React of Bootstrap gebruikt dat je voorheen vanaf een externe server laadde, kun je de geminificeerde bestanden downloaden, aan je project toevoegen en lokaal importeren. Bijvoorbeeld:

<script src="./react-dom.production.min.js"></script>
<link href="./bootstrap.min.css" rel="stylesheet">

Om een ​​bibliotheek in een service worker op te nemen, stelt u de sleutel "background.type" in op "module" in het manifest en gebruikt u een import instructie.

Let op: sommige bibliotheken (zoals Firebase) halen tijdens de uitvoering extra code op wanneer dat nodig is. Je hebt twee opties om dit te voorkomen. Je kunt een bibliotheek kiezen die geen code van externe servers gebruikt. Je kunt er ook voor kiezen om alle mogelijke dynamische imports tijdens het buildproces te downloaden. Hier is een voorbeeldscript dat Firebase bundelt met Rollup.js .

Gebruik externe bibliotheken in scripts die met tab-injectie worden geladen.

Je kunt externe bibliotheken ook tijdens de uitvoering laden door ze toe te voegen aan de array files wanneer je scripting.executeScript() aanroept. Je kunt nog steeds gegevens op afstand laden tijdens de uitvoering.

chrome.scripting.executeScript({
  target: {tabId: tab.id},
  files: ['jquery-min.js', 'content-script.js']
});

Een functie injecteren

Als je meer dynamiek nodig hebt, kun je met de nieuwe func eigenschap in scripting.executeScript() een functie injecteren als inhoudsscript en variabelen doorgeven via de args eigenschap.

Manifest V2

let name = 'World!';
chrome.tabs.executeScript({
  code: `alert('Hello, ${name}!')`
});

In een achtergrondscriptbestand.

Manifest V3

async function getCurrentTab() {/* ... */}
let tab = await getCurrentTab();

function showAlert(givenName) {
  alert(`Hello, ${givenName}`);
}

let name = 'World';
chrome.scripting.executeScript({
  target: {tabId: tab.id},
  func: showAlert,
  args: [name],
});

Op de achtergrond is een servicemedewerker actief.

De Chrome Extension Samples-repository bevat een voorbeeld van functie-injectie dat je stap voor stap kunt doorlopen. Een voorbeeld van getCurrentTab() is te vinden in de referentie voor die functie.

Zoek naar andere oplossingen.

Als de voorgaande benaderingen niet werken voor jouw specifieke situatie, moet je mogelijk een alternatieve oplossing zoeken (bijvoorbeeld overstappen naar een andere bibliotheek) of andere manieren vinden om de functionaliteit van de bibliotheek te benutten. In het geval van Google Analytics kun je bijvoorbeeld overschakelen naar het Google-meetprotocol in plaats van de officiële, op afstand gehoste JavaScript-versie te gebruiken, zoals beschreven in onze handleiding voor Google Analytics 4 .

Werk het inhoudsbeveiligingsbeleid bij.

De "content_security_policy" is niet verwijderd uit het manifest.json bestand, maar is nu een woordenboek dat twee eigenschappen ondersteunt: "extension_pages" en "sandbox" .

Manifest V2

{
  ...
  "content_security_policy": "default-src 'self'"
  ...
}

Manifest V3

{
  ...
  "content_security_policy": {
    "extension_pages": "default-src 'self'",
    "sandbox": "..."
  }
  ...
}

extension_pages : Verwijst naar contexten in uw extensie, waaronder HTML-bestanden en service workers.

Let op: deze paginatypen worden aangeboden via het chrome-extension:// protocol. Een pagina in uw extensie is bijvoorbeeld chrome-extension://EXTENSION_ID/foo.html .

sandbox : Verwijst naar alle afgeschermde extensiepagina's die uw extensie gebruikt.

Verwijder niet-ondersteunde inhoudsbeveiligingsbeleidsregels

Manifest V3 staat bepaalde waarden voor het contentbeveiligingsbeleid in het veld "extension_pages" niet meer toe, die in Manifest V2 wel waren toegestaan. Met name waarden die het uitvoeren van code op afstand toestaan, zijn in Manifest V3 niet meer toegestaan. De directives script-src, object-src en worker-src mogen alleen de volgende waarden hebben:

• self
• none
• wasm-unsafe-eval
• Alleen uitgepakte extensies: elke localhost-bron ( http://localhost , http://127.0.0.1 of elke poort op die domeinen).

De waarden van het contentbeveiligingsbeleid voor sandbox kennen geen dergelijke nieuwe beperkingen.