Een Content Security Policy (CSP) helpt ervoor te zorgen dat de inhoud die op de pagina wordt geladen, wordt vertrouwd door de site-eigenaar. CSP's beperken cross-site scripting (XSS)-aanvallen omdat ze onveilige scripts kunnen blokkeren die door aanvallers worden geïnjecteerd. De CSP kan echter gemakkelijk worden omzeild als deze niet streng genoeg is. Bekijk Mitigate cross-site scripting (XSS) met een strikt Content Security Policy (CSP) voor meer informatie. Lighthouse verzamelt CSP's die zijn opgelegd op het hoofddocument en rapporteert problemen vanuit de CSP Evaluator als deze kunnen worden omzeild.
Vereiste praktijken voor een niet-omzeilbare CSP
Implementeer de volgende procedures om ervoor te zorgen dat uw CSP niet kan worden omzeild. Als de CSP kan worden omzeild, zal Lighthouse een waarschuwing met hoge ernst uitzenden.
CSP richt zich op XSS
Om XSS te targeten, moet een CSP de script-src , object-src en base-uri richtlijnen bevatten. De CSP moet ook vrij zijn van syntaxisfouten.
script-src en object-src beveiligen een pagina tegen respectievelijk onveilige scripts en onveilige plug-ins. Als alternatief kan default-src worden gebruikt om een breed beleid te configureren in plaats van veel richtlijnen, waaronder script-src en object-src .
base-uri voorkomt de injectie van ongeautoriseerde <base> -tags die kunnen worden gebruikt om alle relatieve URL's (zoals scripts) om te leiden naar een door de aanvaller beheerd domein.
CSP gebruikt nonces of hashes om omzeiling van de toelatingslijst te voorkomen
Een CSP die een toelatingslijst voor script-src configureert, gaat ervan uit dat alle reacties afkomstig van een vertrouwd domein veilig zijn en als scripts kunnen worden uitgevoerd. Deze veronderstelling geldt echter niet voor moderne toepassingen; Dankzij enkele veelvoorkomende, goedaardige patronen, zoals het blootleggen van JSONP-interfaces en het hosten van kopieën van de AngularJS-bibliotheek, kunnen aanvallers ontsnappen aan de grenzen van CSP.
In de praktijk kan het merendeel van script-src toelaatlijsten worden omzeild door een aanvaller met een XSS-bug, ook al is dit misschien niet voor de hand liggend voor auteurs van toepassingen, en bieden ze weinig bescherming tegen scriptinjectie. De nonce- en hash-gebaseerde benaderingen hebben daarentegen geen last van deze problemen en maken het gemakkelijker om een veiliger beleid aan te nemen en te handhaven.
Deze code gebruikt bijvoorbeeld een JSONP-eindpunt dat wordt gehost op een vertrouwd domein om een door de aanvaller bestuurd script te injecteren:
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
Om te voorkomen dat deze worden omzeild, moet een CSP scripts afzonderlijk toestaan met behulp van nonces of hashes en 'strikt-dynamisch' gebruiken in plaats van een toelatingslijst.
Aanvullende aanbevelingen voor een veilige CSP
Implementeer de volgende procedures voor extra beveiliging en compatibiliteit. Als de CSP een van de aanbevelingen niet opvolgt, zal Lighthouse een middelzware waarschuwing afgeven.
Configureer CSP-rapportage
Door een rapportagebestemming te configureren, kunt u eventuele storingen opsporen. U kunt de rapportagebestemming instellen met behulp van de report-uri of report-to -richtlijnen. report-to wordt momenteel niet door alle moderne browsers ondersteund, dus het wordt aanbevolen om beide of alleen report-uri te gebruiken.
Als inhoud de CSP schendt, stuurt de browser een rapport naar de geconfigureerde bestemming. Zorg ervoor dat u op deze bestemming een applicatie heeft geconfigureerd die deze rapporten verwerkt.
Definieer de CSP in een HTTP-header
Een CSP kan als volgt in een metatag worden gedefinieerd:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
Indien mogelijk moet u echter een CSP definiëren in een HTTP-antwoordheader. Een injectie vóór de metatag omzeilt de CSP. Bovendien worden frame-ancestors , sandbox en rapportage niet ondersteund in metatag-CSP's.
Zorg ervoor dat CSP achterwaarts compatibel is
Niet alle browsers ondersteunen CSP-nonces/hashes. Daarom wordt het aanbevolen om unsafe-inline toe te voegen als reserve voor niet-compatibele browsers. Als de browser nonces/hashes ondersteunt, wordt unsafe-inline genegeerd.
Op dezelfde manier wordt strict-dynamic niet door alle browsers ondersteund. Het wordt aanbevolen om een toelatingslijst in te stellen als noodoplossing voor niet-compatibele browsers. De toelatingslijst wordt genegeerd in browsers die strict-dynamic ondersteunen.
Hoe een strikte CSP te ontwikkelen
Hieronder ziet u een voorbeeld van het gebruik van een strikte CSP met een niet-gebaseerd beleid.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123 zou elke base64-tekenreeks zijn die op de server wordt gegenereerd elke keer dat de pagina wordt geladen. unsafe-inline en https: worden in moderne browsers genegeerd vanwege de nonce en strict-dynamic . Voor meer informatie over het hanteren van een strikte CSP kunt u de Strict CSP-handleiding raadplegen.
U kunt een CSP controleren op mogelijke bypasses met behulp van Lighthouse en CSP Evaluator . Als u een nieuwe CSP wilt testen zonder het risico te lopen bestaande pagina's kapot te maken, definieert u de CSP in de alleen-rapportmodus door Content-Security-Policy-Report-Only als headernaam te gebruiken. Hierdoor worden CSP-schendingen verzonden naar alle rapportagebestemmingen die u hebt geconfigureerd met report-to en report-uri , maar wordt de CSP niet daadwerkelijk afgedwongen.