XSS i React: dangerouslySetInnerHTML och tredjepartsskript

React escape:ar automatiskt alla värden som renderas via JSX innan de infogas i DOM:en. När Ni skriver {userInput} i JSX utför React motsvarande tilldelning till textContent — värdet behandlas som text, aldrig som HTML. Detta förhindrar som standard de flesta XSS-attacker i React-applikationer.

dangerouslySetInnerHTML={{ __html: htmlString }} är Reacts undantag från säkerhetsmekanismen, som kringgår den automatiska escape-funktionen. Namnet är avsiktligt alarmerande: det visar att Ni själv ansvarar för HTML-strängens säkerhet. React anger innerHTML direkt och kör all HTML, inklusive skript och händelsehanterare.

Ni behöver faktiskt dangerouslySetInnerHTML när Ni renderar HTML från en rich text-editor (som TipTap eller Quill), ett CMS som lagrar HTML eller en Markdown-till-HTML-konverterare. Dessa källor producerar riktig HTML-markup som måste renderas som HTML, inte som escape:ad text.

Om HTML-strängen innehåller <script>stealCookies()</script> eller <img src=x onerror="stealData()"> körs angriparens kod när strängen anges som innerHTML. Användarinnehåll som skickas direkt till dangerouslySetInnerHTML utan sanering är en kritisk XSS-sårbarhet.

DOMPurify är branschstandard för HTML-sanering i webbläsare. Det tolkar HTML-strängen i en sandlådad kontext, tar bort farliga element och attribut (scripttaggar, on-event-hanterare och javascript:-URL:er) och returnerar en säker HTML-sträng. Användning: DOMPurify.sanitize(dirtyHtml) innan värdet skickas till dangerouslySetInnerHTML.

Tredjepartsskript (analysverktyg, chattwidgetar och annonsnätverk) körs med samma behörigheter som applikationens JavaScript. Ett komprometterat eller skadligt tredjepartsskript kan läsa document.cookie, komma åt localStorage, läsa formulärfält och skicka begäranden till externa servrar — allt utan att användaren märker något.

Content Security Policy är en HTTP-header som anger vilka skript som får köras. Även om en XSS-payload injiceras i DOM:en kan en korrekt konfigurerad CSP blockera körningen genom att begränsa inline-skript och endast tillåta vitlistade skriptkällor. CSP är det andra försvarslagret efter sanering av indata.

npm-paket utgör en verklig XSS-angreppsväg. Ett beroende kan innehålla skadlig kod som skickar miljövariabler eller användardata vidare. Incidenten med node-ipc 2022 och komprometteringen av ua-parser-js 2021 visade att vanligt använda paket kan tas över och förgiftas. Granska beroenden med npm audit och använd lockfiler.

En lyckad XSS-attack gör det möjligt för en angripare att stjäla användarens JWT-token från sessionStorage (genom att skicka den till en server som angriparen kontrollerar), utföra åtgärder som den autentiserade användaren (API-anrop med användarens session), ändra DOM:en för att visa nätfiskeinnehåll eller logga varje tangenttryckning som användaren gör i applikationen.

Webbläsarens Trusted Types-API kräver att alla DOM-sänkor (innerHTML, eval, script.src) tar emot särskilda typade objekt i stället för råa strängar. Detta förhindrar att strängbaserade XSS-payloads når DOM:en på plattformsnivå. React arbetar med stöd för Trusted Types, och CSP kan framtvinga det.

Det säkra mönstret för att rendera CMS-HTML är att hämta HTML-koden, skicka den genom DOMPurify.sanitize() med en allowlist över säkra taggar och attribut och sedan rendera den med dangerouslySetInnerHTML={{ __html: cleanHtml }}. Hoppa aldrig över saneringssteget, även om Ni litar på CMS:et, eftersom själva CMS-databasen kan ha komprometterats.

React escape:ar automatiskt JSX-värden, vilket förhindrar de flesta XSS-attacker. dangerouslySetInnerHTML kringgår detta för legitim HTML-rendering — sanera alltid indata med DOMPurify först. Tredjepartsskript och komprometterade npm-paket är XSS-angreppsvägar i leveranskedjan. Content Security Policy tillhandahåller ett andra försvarslager. En lyckad XSS-attack möjliggör stöld av token, identitetskapning och nätfiske.