13. september 2025Norsk

En dybdeanalyse av brudd på frontend Content Security Policy (CSP), med fokus på hendelsesanalyse, overvåking og tiltak for globale webapplikasjoner.

Analyse av Brudd på Content Security Policy i Frontend: Analyse av Sikkerhetshendelser

I dagens trusselbilde er sikkerheten til webapplikasjoner helt avgjørende. Et av de mest effektive forsvarene mot ulike angrep, inkludert Cross-Site Scripting (XSS), er Content Security Policy (CSP). En CSP er et ekstra sikkerhetslag som hjelper til med å oppdage og redusere visse typer angrep, inkludert XSS og datainjeksjonsangrep. Disse angrepene brukes til alt fra datatyveri og vandalisering av nettsteder til distribusjon av skadevare.

Men det er ikke nok å bare implementere en CSP. Du må aktivt overvåke og analysere CSP-brudd for å forstå applikasjonens sikkerhetsstatus, identifisere potensielle sårbarheter og finjustere policyen din. Denne artikkelen gir en omfattende guide til analyse av CSP-brudd i frontend, med fokus på analyse av sikkerhetshendelser og handlingsrettede strategier for forbedring. Vi vil utforske de globale implikasjonene og beste praksis for å håndtere CSP i ulike utviklingsmiljøer.

Hva er Content Security Policy (CSP)?

Content Security Policy (CSP) er en sikkerhetsstandard definert som en HTTP-response-header som lar webutviklere kontrollere hvilke ressurser brukeragenten har lov til å laste for en gitt side. Ved å definere en hviteliste over klarerte kilder kan du betydelig redusere risikoen for å injisere ondsinnet innhold i webapplikasjonen din. CSP fungerer ved å instruere nettleseren til kun å kjøre skript, laste inn bilder, stilark og andre ressurser fra spesifiserte kilder.

Nøkkeldirektiver i CSP:

`default-src`: Fungerer som en reserve for andre fetch-direktiver. Hvis en spesifikk ressurstype ikke er definert, brukes dette direktivet.
`script-src`: Spesifiserer gyldige kilder for JavaScript.
`style-src`: Spesifiserer gyldige kilder for CSS-stilark.
`img-src`: Spesifiserer gyldige kilder for bilder.
`connect-src`: Spesifiserer gyldige kilder for fetch, XMLHttpRequest, WebSockets og EventSource-tilkoblinger.
`font-src`: Spesifiserer gyldige kilder for skrifttyper.
`media-src`: Spesifiserer gyldige kilder for lasting av medier som lyd og video.
`object-src`: Spesifiserer gyldige kilder for plugins som Flash. (Generelt er det best å forby plugins helt ved å sette dette til 'none'.)
`base-uri`: Spesifiserer gyldige URL-er som kan brukes i et dokuments ``-element.
`form-action`: Spesifiserer gyldige endepunkter for skjemainnsendinger.
`frame-ancestors`: Spesifiserer gyldige foreldre som kan bygge inn en side ved hjelp av ``, ``, `<object>`, `<embed>` eller `<applet>`.</li> <li>`report-uri` (Utdatert): Spesifiserer en URL som nettleseren skal sende rapporter om CSP-brudd til. Vurder å bruke `report-to` i stedet.</li> <li>`report-to`: Spesifiserer et navngitt endepunkt konfigurert via `Report-To`-headeren som nettleseren skal bruke til å sende rapporter om CSP-brudd. Dette er den moderne erstatningen for `report-uri`.</li> <li>`upgrade-insecure-requests`: Instruerer brukeragenter til å behandle alle et nettsteds usikre URL-er (de som serveres over HTTP) som om de har blitt erstattet med sikre URL-er (de som serveres over HTTPS). Dette direktivet er ment for nettsteder som er i overgang til HTTPS.</li> </ul> Eksempel på CSP-header: `Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-to csp-endpoint;` Denne policyen tillater at ressurser lastes fra samme opprinnelse (`'self'`), JavaScript fra `https://example.com`, inline-stiler, bilder fra samme opprinnelse og data-URI-er, og spesifiserer et rapporteringsendepunkt kalt `csp-endpoint` (konfigurert med `Report-To`-headeren). <h2>Hvorfor er Analyse av CSP-brudd Viktig?</h2> Selv om en korrekt konfigurert CSP kan forbedre sikkerheten betraktelig, avhenger dens effektivitet av aktiv overvåking og analyse av bruddrapporter. Å overse disse rapportene kan føre til en falsk følelse av sikkerhet og tapte muligheter til å håndtere reelle sårbarheter. Her er hvorfor analyse av CSP-brudd er avgjørende: <ul> <li>Identifisere XSS-forsøk: CSP-brudd indikerer ofte forsøk på XSS-angrep. Analyse av disse rapportene hjelper deg med å oppdage og respondere på ondsinnet aktivitet før den kan forårsake skade.</li> <li>Avdekke svakheter i policyen: Bruddrapporter avslører hull i CSP-konfigurasjonen din. Ved å identifisere hvilke ressurser som blokkeres, kan du finjustere policyen din til å bli mer effektiv uten å ødelegge legitim funksjonalitet.</li> <li>Feilsøke legitime kodeproblemer: Noen ganger forårsakes brudd av legitim kode som utilsiktet bryter CSP-en. Analyse av rapporter hjelper deg med å identifisere og fikse disse problemene. For eksempel kan en utvikler ved et uhell inkludere et inline-skript eller en CSS-regel, som kan bli blokkert av en streng CSP.</li> <li>Overvåke tredjepartsintegrasjoner: Tredjepartsbiblioteker og -tjenester kan introdusere sikkerhetsrisikoer. Rapporter om CSP-brudd gir innsikt i oppførselen til disse integrasjonene og hjelper deg med å sikre at de overholder sikkerhetspolicyene dine. Mange organisasjoner krever nå at tredjepartsleverandører gir informasjon om CSP-samsvar som en del av deres sikkerhetsvurdering.</li> <li>Samsvar og revisjon: Mange forskrifter og bransjestandarder krever robuste sikkerhetstiltak. CSP og overvåkingen av den kan være en sentral komponent for å demonstrere samsvar. Å opprettholde logger over CSP-brudd og din respons på dem er verdifullt under sikkerhetsrevisjoner.</li> </ul> <h2>Sette opp CSP-rapportering</h2> Før du kan analysere CSP-brudd, må du konfigurere serveren din til å sende rapporter til et angitt endepunkt. Moderne CSP-rapportering benytter seg av `Report-To`-headeren, som gir større fleksibilitet og pålitelighet sammenlignet med det utdaterte `report-uri`-direktivet. Steg 1: Konfigurer `Report-To`-headeren: `Report-To`-headeren definerer ett eller flere rapporteringsendepunkter. Hvert endepunkt har et navn, en URL og en valgfri utløpstid. Eksempel: `Report-To: {"group":"csp-endpoint","max_age":31536000,"endpoints":[{"url":"https://your-reporting-service.com/csp-report"}],"include_subdomains":true}` <ul> <li>`group`: Et navn for rapporteringsendepunktet (f.eks. "csp-endpoint"). Dette navnet refereres til i `report-to`-direktivet i CSP-headeren.</li> <li>`max_age`: Levetiden til endepunktkonfigurasjonen i sekunder. Nettleseren mellomlagrer endepunktkonfigurasjonen i denne perioden. En vanlig verdi er 31536000 sekunder (1 år).</li> <li>`endpoints`: En matrise av endepunktobjekter. Hvert objekt spesifiserer URL-en dit rapportene skal sendes. Du kan konfigurere flere endepunkter for redundans.</li> <li>`include_subdomains` (Valgfritt): Hvis satt til `true`, gjelder rapporteringskonfigurasjonen for alle underdomener av domenet.</li> </ul> Steg 2: Konfigurer `Content-Security-Policy`-headeren: `Content-Security-Policy`-headeren definerer din CSP-policy og inkluderer `report-to`-direktivet, som refererer til rapporteringsendepunktet definert i `Report-To`-headeren. Eksempel: `Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;` Steg 3: Sett opp et rapporteringsendepunkt: Du må opprette et server-side-endepunkt som mottar og behandler rapportene om CSP-brudd. Dette endepunktet bør kunne håndtere JSON-data og lagre rapportene for analyse. Den nøyaktige implementeringen avhenger av din server-side-teknologi (f.eks. Node.js, Python, Java). Eksempel (Node.js med Express): <pre> <code> const express = require('express'); const bodyParser = require('body-parser'); const app = express(); app.use(bodyParser.json()); app.post('/csp-report', (req, res) => { const report = req.body['csp-report']; console.log('CSP Violation Report:', report); // Store the report in a database or log file res.status(204).end(); // Respond with a 204 No Content status }); const port = 3000; app.listen(port, () => { console.log(`Server listening on port ${port}`); }); </code> </pre> Steg 4: Vurder `Content-Security-Policy-Report-Only` for testing: Før du håndhever en CSP, er det god praksis å teste den i kun-rapporteringsmodus. Dette lar deg overvåke brudd uten å blokkere noen ressurser. Bruk `Content-Security-Policy-Report-Only`-headeren i stedet for `Content-Security-Policy`. Brudd vil bli rapportert til ditt rapporteringsendepunkt, men nettleseren vil ikke håndheve policyen. Eksempel: `Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;` <h2>Analysere Rapporter om CSP-brudd</h2> Når du har satt opp CSP-rapportering, vil du begynne å motta bruddrapporter. Disse rapportene er JSON-objekter som inneholder informasjon om bruddet. Strukturen på rapporten er definert av CSP-spesifikasjonen. Eksempel på rapport om CSP-brudd: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "referrer": "https://attacker.com", "violated-directive": "script-src 'self' https://example.com", "effective-directive": "script-src", "original-policy": "default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;", "disposition": "report", "blocked-uri": "https://attacker.com/evil.js", "status-code": 200, "script-sample": "", "source-file": "https://attacker.com/evil.js", "line-number": 1, "column-number": 1 } } </code> </pre> Nøkkelfelt i en rapport om CSP-brudd: <ul> <li>`document-uri`: URI-en til dokumentet der bruddet skjedde.</li> <li>`referrer`: URI-en til den henvisende siden (hvis noen).</li> <li>`violated-directive`: CSP-direktivet som ble brutt.</li> <li>`effective-directive`: Direktivet som faktisk ble anvendt, med tanke på reservemekanismer.</li> <li>`original-policy`: Den komplette CSP-policyen som var i kraft.</li> <li>`disposition`: Indikerer om bruddet ble håndhevet (`"enforce"`) eller kun rapportert (`"report"`).</li> <li>`blocked-uri`: URI-en til ressursen som ble blokkert.</li> <li>`status-code`: HTTP-statuskoden til den blokkerte ressursen.</li> <li>`script-sample`: Et utdrag av det blokkerte skriptet (hvis aktuelt). Nettlesere kan redigere deler av skript-utdraget av sikkerhetsgrunner.</li> <li>`source-file`: Kildefilen der bruddet skjedde (hvis tilgjengelig).</li> <li>`line-number`: Linjenummeret i kildefilen der bruddet skjedde.</li> <li>`column-number`: Kolonnenummeret i kildefilen der bruddet skjedde.</li> </ul> <h2>Steg for Effektiv Analyse av Sikkerhetshendelser</h2> Å analysere rapporter om CSP-brudd er en kontinuerlig prosess som krever en strukturert tilnærming. Her er en trinnvis guide for å effektivt analysere sikkerhetshendelser basert på data fra CSP-brudd: <ol> <li>Prioriter rapporter basert på alvorlighetsgrad: Fokuser på brudd som indikerer potensielle XSS-angrep eller andre alvorlige sikkerhetsrisikoer. For eksempel bør brudd med en blokkert URI fra en ukjent eller ikke-klarert kilde undersøkes umiddelbart.</li> <li>Identifiser rotårsaken: Finn ut hvorfor bruddet skjedde. Er det en legitim ressurs som blokkeres på grunn av en feilkonfigurasjon, eller er det et ondsinnet skript som prøver å kjøre? Se på feltene `blocked-uri`, `violated-directive` og `referrer` for å forstå konteksten til bruddet.</li> <li>Kategoriser brudd: Grupper brudd i kategorier basert på deres rotårsak. Dette hjelper deg med å identifisere mønstre og prioritere utbedringstiltak. Vanlige kategorier inkluderer:</li> <ul> <li>Feilkonfigurasjoner: Brudd forårsaket av feil CSP-direktiver eller manglende unntak.</li> <li>Legitime kodeproblemer: Brudd forårsaket av inline-skript eller -stiler, eller av kode som bryter CSP-en.</li> <li>Tredjepartsproblemer: Brudd forårsaket av tredjepartsbiblioteker eller -tjenester.</li> <li>XSS-forsøk: Brudd som indikerer potensielle XSS-angrep.</li> </ul> <li>Undersøk mistenkelig aktivitet: Hvis et brudd ser ut til å være et XSS-forsøk, undersøk det grundig. Se på feltene `referrer`, `blocked-uri` og `script-sample` for å forstå angriperens hensikt. Sjekk serverloggene dine og andre sikkerhetsovervåkingsverktøy for relatert aktivitet.</li> <li>Utbedre brudd: Basert på rotårsaken, iverksett tiltak for å utbedre bruddet. Dette kan innebære: <ul> <li>Oppdatere CSP: Endre CSP-en for å tillate legitime ressurser som blir blokkert. Vær forsiktig så du ikke svekker policyen unødvendig.</li> <li>Fikse kode: Fjern inline-skript eller -stiler, eller endre koden for å overholde CSP-en.</li> <li>Oppdatere tredjepartsbiblioteker: Oppdater tredjepartsbiblioteker til de nyeste versjonene, som kan inneholde sikkerhetsfikser.</li> <li>Blokkere ondsinnet aktivitet: Blokker ondsinnede forespørsler или brukere basert på informasjonen i bruddrapportene.</li> </ul> </li> <li>Test endringene dine: Etter å ha gjort endringer i CSP-en eller koden, test applikasjonen grundig for å sikre at endringene ikke har introdusert nye problemer. Bruk `Content-Security-Policy-Report-Only`-headeren for å teste endringer i en ikke-håndhevende modus.</li> <li>Dokumenter funnene dine: Dokumenter bruddene, deres rotårsaker og utbedringstiltakene du tok. Denne informasjonen vil være verdifull for fremtidig analyse og for samsvarsformål.</li> <li>Automatiser analyseprosessen: Vurder å bruke automatiserte verktøy for å analysere rapporter om CSP-brudd. Disse verktøyene kan hjelpe deg med å identifisere mønstre, prioritere brudd og generere rapporter.</li> </ol> <h2>Praktiske Eksempler og Scenarier</h2> For å illustrere prosessen med å analysere rapporter om CSP-brudd, la oss se på noen praktiske eksempler: Scenario 1: Blokkering av inline-skript Bruddrapport: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "violated-directive": "script-src 'self' https://example.com", "blocked-uri": "inline", "script-sample": "<script>alert('Hello');</script>" } } </code> </pre> Analyse: Dette bruddet indikerer at CSP-en blokkerer et inline-skript. Dette er et vanlig scenario, da inline-skript ofte anses som en sikkerhetsrisiko. `script-sample`-feltet viser innholdet i det blokkerte skriptet. Utbedring: Den beste løsningen er å flytte skriptet til en egen fil og laste det fra en klarert kilde. Alternativt kan du bruke en nonce eller hash for å tillate spesifikke inline-skript. Disse metodene er imidlertid generelt mindre sikre enn å flytte skriptet til en egen fil. Scenario 2: Blokkering av et tredjepartsbibliotek Bruddrapport: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "violated-directive": "script-src 'self' https://example.com", "blocked-uri": "https://cdn.example.com/library.js" } } </code> </pre> Analyse: Dette bruddet indikerer at CSP-en blokkerer et tredjepartsbibliotek som hostes på `https://cdn.example.com`. Dette kan skyldes en feilkonfigurasjon eller en endring i bibliotekets plassering. Utbedring: Sjekk CSP-en for å sikre at `https://cdn.example.com` er inkludert i `script-src`-direktivet. Hvis det er det, verifiser at biblioteket fortsatt hostes på den angitte URL-en. Hvis biblioteket har flyttet, oppdater CSP-en tilsvarende. Scenario 3: Potensielt XSS-angrep Bruddrapport: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "referrer": "https://attacker.com", "violated-directive": "script-src 'self' https://example.com", "blocked-uri": "https://attacker.com/evil.js" } } </code> </pre> Analyse: Dette bruddet er mer bekymringsfullt, da det indikerer et potensielt XSS-angrep. `referrer`-feltet viser at forespørselen kom fra `https://attacker.com`, og `blocked-uri`-feltet viser at CSP-en blokkerte et skript fra samme domene. Dette tyder sterkt på at en angriper prøver å injisere ondsinnet kode i applikasjonen din. Utbedring: Undersøk bruddet umiddelbart. Sjekk serverloggene dine for relatert aktivitet. Blokker angriperens IP-adresse og iverksett tiltak for å forhindre fremtidige angrep. Gjennomgå koden din for potensielle sårbarheter som kan tillate XSS-angrep. Vurder å implementere ytterligere sikkerhetstiltak, som input-validering og output-koding. <h2>Verktøy for Analyse av CSP-brudd</h2> Flere verktøy kan hjelpe deg med å automatisere og forenkle prosessen med å analysere rapporter om CSP-brudd. Disse verktøyene kan tilby funksjoner som: <ul> <li>Aggregering og visualisering: Samle bruddrapporter fra flere kilder og visualiser dataene for å identifisere trender og mønstre.</li> <li>Filtrering og søk: Filtrer og søk i rapporter basert på ulike kriterier, som `document-uri`, `violated-directive` og `blocked-uri`.</li> <li>Varsling: Send varsler når mistenkelige brudd oppdages.</li> <li>Rapportering: Generer rapporter om CSP-brudd for samsvars- og revisjonsformål.</li> <li>Integrasjon med SIEM-systemer (Security Information and Event Management): Videresend rapporter om CSP-brudd til SIEM-systemer for sentralisert sikkerhetsovervåking.</li> </ul> Noen populære verktøy for analyse av CSP-brudd inkluderer: <ul> <li>Report URI: En dedikert CSP-rapporteringstjeneste som gir detaljert analyse og visualisering av bruddrapporter.</li> <li>Sentry: En populær plattform for feilsporing og ytelsesovervåking som også kan brukes til å overvåke CSP-brudd.</li> <li>Google Security Analytics: En skybasert sikkerhetsanalyseplattform som kan analysere rapporter om CSP-brudd sammen med andre sikkerhetsdata.</li> <li>Egendefinerte løsninger: Du kan også bygge dine egne verktøy for analyse av CSP-brudd ved hjelp av åpen kildekode-biblioteker og -rammeverk.</li> </ul> <h2>Globale Hensyn ved Implementering av CSP</h2> Når du implementerer CSP i en global kontekst, er det viktig å vurdere følgende: <ul> <li>Innholdsleveringsnettverk (CDN-er): Hvis applikasjonen din bruker CDN-er for å levere statiske ressurser, sørg for at CDN-domenene er inkludert i CSP-en. CDN-er har ofte regionale variasjoner (f.eks. `cdn.example.com` for Nord-Amerika, `cdn.example.eu` for Europa). CSP-en din bør imøtekomme disse variasjonene.</li> <li>Tredjepartstjenester: Mange nettsteder er avhengige av tredjepartstjenester, som analyseverktøy, annonsenettverk og sosiale medier-widgets. Sørg for at domenene som brukes av disse tjenestene er inkludert i CSP-en. Gjennomgå regelmessig tredjepartsintegrasjonene dine for å identifisere nye eller endrede domener.</li> <li>Lokalisering: Hvis applikasjonen din støtter flere språk eller regioner, kan det hende CSP-en må justeres for å imøtekomme forskjellige ressurser eller domener. For eksempel kan det hende du må tillate skrifttyper eller bilder fra forskjellige regionale CDN-er.</li> <li>Regionale forskrifter: Noen land har spesifikke forskrifter om personvern og sikkerhet. Sørg for at CSP-en din overholder disse forskriftene. For eksempel krever personvernforordningen (GDPR) i EU at du beskytter personopplysningene til EU-borgere.</li> <li>Testing i forskjellige regioner: Test CSP-en din i forskjellige regioner for å sikre at den fungerer korrekt og ikke blokkerer legitime ressurser. Bruk nettleserens utviklerverktøy eller online CSP-validatorer for å verifisere policyen.</li> </ul> <h2>Beste Praksis for Håndtering av CSP</h2> For å sikre den kontinuerlige effektiviteten til CSP-en din, følg disse beste praksisene: <ul> <li>Start med en streng policy: Begynn med en streng policy som kun tillater ressurser fra klarerte kilder. Løsne gradvis på policyen etter behov, basert på bruddrapporter.</li> <li>Bruk nonces eller hasher for inline-skript og -stiler: Hvis du må bruke inline-skript eller -stiler, bruk nonces eller hasher for å tillate spesifikke forekomster. Dette er sikrere enn å tillate alle inline-skript eller -stiler.</li> <li>Unngå `unsafe-inline` og `unsafe-eval`: Disse direktivene svekker CSP-en betydelig og bør unngås hvis mulig.</li> <li>Gjennomgå og oppdater CSP-en regelmessig: Gjennomgå CSP-en regelmessig for å sikre at den fortsatt er effektiv og at den gjenspeiler eventuelle endringer i applikasjonen din eller tredjepartsintegrasjoner.</li> <li>Automatiser distribusjonsprosessen for CSP: Automatiser prosessen med å distribuere CSP-endringer for å sikre konsistens og redusere risikoen for feil.</li> <li>Overvåk rapporter om CSP-brudd: Overvåk rapporter om CSP-brudd regelmessig for å identifisere potensielle sikkerhetsrisikoer og for å finjustere policyen.</li> <li>Lær opp utviklingsteamet ditt: Lær opp utviklingsteamet ditt om CSP og dens betydning. Sørg for at de forstår hvordan de skal skrive kode som overholder CSP-en.</li> </ul> <h2>Fremtiden for CSP</h2> Content Security Policy-standarden utvikler seg stadig for å møte nye sikkerhetsutfordringer. Noen nye trender innen CSP inkluderer: <ul> <li>Trusted Types: Et nytt API som hjelper med å forhindre DOM-baserte XSS-angrep ved å sikre at data som settes inn i DOM-en er korrekt sanert.</li> <li>Feature Policy: En mekanisme for å kontrollere hvilke nettleserfunksjoner som er tilgjengelige for en nettside. Dette kan bidra til å redusere angrepsflaten til applikasjonen din.</li> <li>Subresource Integrity (SRI): En mekanisme for å verifisere at filer som hentes fra CDN-er ikke har blitt tuklet med.</li> <li>Mer detaljerte direktiver: Den pågående utviklingen av mer spesifikke og detaljerte CSP-direktiver for å gi finere kontroll over ressurslasting.</li> </ul> <h2>Konklusjon</h2> Analyse av brudd på Content Security Policy i frontend er en essensiell komponent i moderne webapplikasjonssikkerhet. Ved å aktivt overvåke og analysere CSP-brudd kan du identifisere potensielle sikkerhetsrisikoer, finjustere policyen din og beskytte applikasjonen din mot angrep. Implementering av CSP og nøye analyse av bruddrapporter er et kritisk skritt i å bygge sikre og pålitelige webapplikasjoner for et globalt publikum. Å omfavne en proaktiv tilnærming til CSP-håndtering, inkludert automatisering og teamopplæring, sikrer et robust forsvar mot trusler i stadig utvikling. Husk at sikkerhet er en kontinuerlig prosess, og CSP er et kraftig verktøy i arsenalet ditt.</div><footer class="mt-12 pt-8 border-t border-gray-200"><h3 class="text-sm font-semibold text-gray-900 mb-3 dark:text-white/90">Tags:</h3><div class="flex flex-wrap gap-2">Content Security PolicyCSPfrontend-sikkerhetbruddrapporteringsikkerhetsanalysewebsikkerhetXSSsikkerhetsovervåkingsikkerhetshendelserpersonverninformasjonssikkerhetwebutvikling</div></footer></article></div><script>$RS=function(a,b){a=document.getElementById(a);b=document.getElementById(b);for(a.parentNode.removeChild(a);a.firstChild;)b.parentNode.insertBefore(a.firstChild,b);b.parentNode.removeChild(b)};$RS("S:2","P:2")</script><script>$RB=[];$RV=function(b){$RT=performance.now();for(var a=0;a<b.length;a+=2){var c=b[a],e=b[a+1];null!==e.parentNode&&e.parentNode.removeChild(e);var f=c.parentNode;if(f){var g=c.previousSibling,h=0;do{if(c&&8===c.nodeType){var d=c.data;if("/$"===d||"/&"===d)if(0===h)break;else h--;else"$"!==d&&"$?"!==d&&"$~"!==d&&"$!"!==d&&"&"!==d||h++}d=c.nextSibling;f.removeChild(c);c=d}while(c);for(;e.firstChild;)f.insertBefore(e.firstChild,c);g.data="$";g._reactRetry&&g._reactRetry()}}b.length=0}; $RC=function(b,a){if(a=document.getElementById(a))(b=document.getElementById(b))?(b.previousSibling.data="$~",$RB.push(b,a),2===$RB.length&&(b="number"!==typeof $RT?0:$RT,a=performance.now(),setTimeout($RV.bind(null,$RB),2300>a&&2E3<a?2300-a:b+300-a))):a.parentNode.removeChild(a)};$RC("B:1","S:1")</script><div style="display:none" id="S:3"></div><script>$RC("B:3","S:3")</script><div style="display:none" id="S:0"></div><script>$RC("B:0","S:0")</script></body></html>