Chrome schakelt het wijzigen van document.domain uit om het beleid inzake dezelfde oorsprong te versoepelen

Als uw website afhankelijk is van het instellen van document.domain , is uw actie vereist.

Eiji Kitamura

Updates

  • 30 mei 2023 : we hebben aangekondigd dat de veroudering van document.domain setter van kracht wordt in Chrome 115.
  • 7 april 2023 : We hebben een probleem vastgesteld voordat deze wijziging in Chrome 112 werd doorgevoerd. document.domain setter die standaard wordt verwijderd, is momenteel opgeschort en de nieuwe verzendmijlpaal is nog niet vastgesteld. Controleer deze blogpost regelmatig of abonneer u op blink-dev en deze thread .
  • 20 januari 2023 : Tijdlijn bijgewerkt: document.domain -setter wordt standaard verwijderd vanaf Chrome 112. Ook is er een vermelding toegevoegd over een bedrijfsbeleid om het document.domain -gedrag te beheren.
  • 25 juli 2022 : Bijgewerkte tijdlijn: document.domain setter wordt standaard verwijderd vanaf Chrome 109.
  • 4 februari 2022 : Bijgewerkt met de nieuwe tijdlijn. Vanaf Chrome 100 tonen we een waarschuwing in het Problemen-paneel en wordt document.domain setter standaard verwijderd vanaf Chrome 106.

document.domain is ontworpen om de hostnaam van de oorsprong op te halen of in te stellen.

Websites kunnen in Chrome geen document.domain instellen. U moet alternatieve methoden gebruiken, zoals postMessage() of de Channel Messaging API, om cross-origin te communiceren. We streven ernaar dat Chrome 112 deze wijziging zo snel mogelijk doorvoert, maar dit is afhankelijk van de reactie op de Intent to Ship -melding .

Als uw website afhankelijk is van versoepeling van het beleid voor dezelfde oorsprong via document.domain om correct te functioneren, moet de site een Origin-Agent-Cluster: ?0 header verzenden, net als alle andere documenten die dat gedrag vereisen (houd er rekening mee dat document.domain geen effect heeft als het slechts door één document wordt ingesteld).

Waarom moet document.domain onveranderlijk worden gemaakt?

Veel websites stellen document.domain in om communicatie tussen pagina's van dezelfde site maar met een andere oorsprong mogelijk te maken.

Zo wordt het gebruikt:

Stel dat een pagina op https://parent.example.com een ​​iframe-pagina van https://video.example.com insluit. Deze pagina's hebben dezelfde eTLD+1 ( example.com ) met verschillende subdomeinen. Wanneer document.domain van beide pagina's is ingesteld op 'example.com' , behandelt de browser de twee bronnen alsof ze dezelfde oorsprong hebben.

Stel het document.domain in voor https://parent.example.com :

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

Stel het document.domain in voor https://video.example.com :

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

U kunt nu een cross-origin DOM-manipulatie op https://parent.example.com maken tegen https://video.example.com .

Websites stellen document.domain in om de communicatie tussen documenten op dezelfde site te vergemakkelijken. Omdat deze wijziging het beleid voor dezelfde oorsprong versoepelt , kan de bovenliggende pagina toegang krijgen tot het document in het iframe en de DOM-structuur doorlopen, en vice versa.

Dit is een handige techniek, maar het brengt wel een veiligheidsrisico met zich mee.

Beveiligingsproblemen met document.domain

Beveiligingsproblemen rond document.domain hebben geleid tot een wijziging in de specificatie die gebruikers waarschuwt het gebruik ervan te vermijden . De huidige discussie met andere browserleveranciers beweegt zich in dezelfde richting.

Wanneer twee pagina's bijvoorbeeld document.domain instellen, kunnen ze doen alsof ze dezelfde oorsprong hebben. Dit is met name cruciaal wanneer deze pagina's gebruikmaken van een gedeelde hostingservice met verschillende subdomeinen. Door document.domain in te stellen, wordt toegang verleend tot alle andere sites die door dezelfde service worden gehost, waardoor aanvallers gemakkelijker toegang krijgen tot uw sites. Dit is mogelijk omdat document.domain het poortnummer van het domein negeert.

Voor meer informatie over de beveiligingsimplicaties van het instellen van document.domain raadpleegt u de pagina "Document.domain" op MDN .

Chrome is van plan om document.domain onveranderlijk te maken in Chrome 112.

Hoe weet ik of mijn site is getroffen?

Als uw website door deze wijziging wordt beïnvloed, waarschuwt Chrome u in het venster Problemen in DevTools. Let op de gele vlag rechtsboven.

Wanneer document.domein wordt gewijzigd, wordt er een waarschuwing weergegeven in het paneel Problemen.
Wanneer document.domain wordt gewijzigd, wordt er een waarschuwing weergegeven in het paneel Problemen.

Als u een rapportage-eindpunt hebt ingesteld, ontvangt u ook verouderingsrapporten. Lees meer over hoe u de Reporting API kunt gebruiken met bestaande rapportverzamelingsservices of door uw eigen interne oplossing te bouwen.

U kunt de verouderde API-audit van LightHouse voor uw site uitvoeren om alle API's te vinden die gepland staan ​​om uit Chrome te worden verwijderd.

Alternatieve cross-origin communicatie

Op dit moment hebt u drie opties om document.domain voor uw website te vervangen.

Gebruik postMessage() of Channel Messaging API

In de meeste gevallen kan cross-origin postMessage() of Channel Messaging API document.domain vervangen.

In het volgende voorbeeld:

  1. https://parent.example.com vraagt https://video.example.com aan binnen een iframe om de DOM te manipuleren door een bericht te versturen via postMessage() .
  2. https://video.example.com manipuleert DOM zodra het bericht ontvangen is en informeert de bovenliggende site over het succes.
  3. https://parent.example.com erkent het succes.

Op https://parent.example.com :

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

Op https://video.example.com :

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

Probeer het en zie hoe het werkt. Als je specifieke vereisten hebt die niet werken met postMessage() of de Channel Messaging API, laat het ons dan weten op Twitter via @ChromiumDev of vraag het op Stack Overflow met een document.domain tag .

Als laatste redmiddel stuurt u de Origin-Agent-Cluster: ?0 header

Als u goede redenen hebt om document.domain te blijven instellen, kunt u Origin-Agent-Cluster: ?0 responsheader meesturen met het doeldocument.

Origin-Agent-Cluster: ?0

De Origin-Agent-Cluster header geeft de browser aan of het document al dan niet door het Origin-keyed agentcluster moet worden verwerkt. Lees Prestatie-isolatie aanvragen met de Origin-Agent-Cluster -header voor meer informatie over Origin-Agent-Cluster .

Wanneer u deze header verzendt, kan uw document document.domain blijven instellen, zelfs nadat deze standaard onveranderlijk is geworden.

Configureer OriginAgentClusterDefaultEnabled voor bedrijfsbeleid

Optioneel kan uw beheerder het beleid OriginAgentClusterDefaultEnabled configureren op false , zodat document.domain standaard instelbaar is op Chrome-instanties in uw organisatie. Lees voor meer informatie Chrome Enterprise Policy List & Management | Documentatie .

Browsercompatibiliteit

Bronnen

Dankbetuigingen

Foto door Braydon Anderson op Unsplash