Headers Content Security Policy (CSP) 2

Binnenland: Tech HTTP Headers Content-Security-Policy: Content Security Policy (CSP) Content Security Policy (CSP) is een extra beveiligingslaag die helpt bij het detecteren en beperken van bepaalde soorten aanvallen, waaronder Cross Site Scripting (XSS) en aanvallen met gegevensinjectie. Deze aanvallen worden gebruikt voor alles van gegevensdiefstal tot defacatie van websites tot verspreiding van malware.

CSP versie 2

CSP is ontworpen om volledig achterwaarts compatibel te zijn (behalve CSP versie 2 waar er een aantal expliciet genoemde inconsistenties in achterwaartse compatibiliteit zijn,). Browsers die het niet ondersteunen, werken nog steeds met servers die het implementeren en omgekeerd: browsers die CSP niet ondersteunen, negeren het gewoon en functioneren zoals gebruikelijk, in gebreke blijven aan het standaardbeleid van dezelfde oorsprong voor webinhoud. Als de site de CSP Header niet biedt, gebruiken browsers ook het standaardbeleid voor same-origin policy.

Om CSP in te schakelen, moet u uw webserver configureren om de HTTP Header Content-Security-Policy te retourneren (soms ziet u vermeldingen van de X-Content-Security-Policy Header, maar dat is een oudere versie en u hoeft dit niet te doen specificeer het meer).

Content-Security-Policy moet je weten welke opties je kunt toevoegen aan je eigen Content-Security-Policy Header, en de meeste weten absoluut niet hoe ze dit moeten gebruiken.

Dit stukje zullen wij kort houden, je zal moeten nazien wat jouw website aan te bieden heeft???

Zet jij bijvoorbeeld een <iframe> of een Video vanaf Youtube op jouw website, dat zal de toepassing

media-src: definieer waar de beveiligde bron video en audio kan laden, dat kan dus zijn 'self' vanaf je eigen website, indien anders zal je er een website URL erbij moeten worden opgegeven worden
frame-src: definieer vanaf waar de beschermde bron frames kan insluiten, dat kan dus zijn 'self'' vanaf je eigen website, indien anders zal je er een website URL erbij moeten worden opgegeven worden

De HTTP Headers Content-Security-Policy, zal je dus zelf moeten opbouwen, de enige die wij standaard aanraden is in groen aangegeven. Ga vanaf daar verder alles rustig opbouwen wat van toepassing is voor jouw website

Content Security Policy <meta>

Als alternatief kan het element <meta> worden gebruikt om een ​​beleid te configureren, bijvoorbeeld

NIET GEBRUIKEN, WERKT NIET

<meta HTTP equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

Matigen van cross-site scripting

Een primaire doelstelling van CSP is om XSS aanvallen te matigen en te melden. XSS aanvallen maken gebruik van het vertrouwen van de browser van de inhoud die van de server wordt ontvangen. Schadelijke scripts worden uitgevoerd door de browser van het slachtoffer, omdat de browser de bron van de inhoud vertrouwt, zelfs als deze niet afkomstig is van waar het vandaan lijkt te komen.

CSP maakt het voor serverbeheerders mogelijk om de vectoren waarmee XSS kan plaatsvinden te verminderen of te elimineren door de domeinen op te geven die de browser moet beschouwen als geldige bronnen van uitvoerbare scripts. Een CSP compatibele browser voert dan alleen scripts uit die zijn geladen in bronbestanden die zijn ontvangen van die witte lijsten en alle andere scripts negeren (inclusief inline-scripts en HTML kenmerken voor gebeurtenisafhandeling).

Als ultieme vorm van beveiliging kunnen sites die scripts nooit willen uitvoeren, toestaan om de uitvoering van scripts globaal af te wijzen.

Matigen pakketten sniffing aanvallen

Naast het beperken van de domeinen waarvan inhoud kan worden geladen, kan de server specificeren welke protocollen mogen worden gebruikt; bijvoorbeeld (en idealiter vanuit een beveiligingsstandpunt), kan een server specificeren dat alle inhoud moet worden geladen met behulp van HTTPS. Een complete beveiligingsstrategie voor gegevensoverdracht omvat niet alleen het afdwingen van HTTPS voor gegevensoverdracht, maar ook het markeren van alle cookies met de veilige markering en het automatisch omleiden van HTTP pagina's naar hun HTTPS tegenhangers. Sites kunnen ook de HTTP Header Strict-Transport-Security gebruiken om ervoor te zorgen dat browsers alleen verbinding maken via een gecodeerd kanaal.

Content Security Policy CSP gebruiken

Het beleid voor inhoudbeveiliging configureren bestaat erin de HTTP Header Content-Security-Policy aan een webpagina toe te voegen en deze waarden te geven voor het beheren van bronnen die de user-agent voor die pagina mag laden. Een pagina die afbeeldingen uploadt en weergeeft, kan afbeeldingen van overal toestaan, maar een formulieractie beperken tot een specifiek eindpunt. Een goed ontworpen beleid voor inhoudsbeveiliging helpt een pagina te beschermen tegen een cross-site scriptingaanval. In dit artikel wordt uitgelegd hoe dergelijke Headers op de juiste manier worden geconstrueerd en worden voorbeelden gegeven.

Uw Content Security Policy specificeren

U kunt de HTTP Header Content-Security-Policy gebruiken om uw beleid op te geven, zoals dit:

Header Alway set Content-Security-Policy: "policy"

Een Content Security Policy schrijven

Een beleid wordt beschreven met behulp van een reeks beleidsrichtlijnen, die elk het beleid voor een bepaald resourcetype of beleidsgebied beschrijven. Uw beleid moet een default-src -beleidsrichtlijn bevatten, die een terugval is voor andere resourcetypes wanneer deze geen eigen beleid hebben (voor een volledige lijst, zie de beschrijving van de default-src -richtlijn). Een beleid moet een default-src - of script-src-instructie bevatten om te voorkomen dat inline-scripts worden uitgevoerd, en het gebruik van eval () te blokkeren. Een beleid moet een default-src - of style-src-instructie bevatten om te beperken dat inline stijlen worden toegepast vanuit een <style> -element of een stijlkenmerk.

Content Security Policy voorbeeld 1

Een websitebeheerder wil dat alle inhoud afkomstig is van de eigen herkomst van de site (dit sluit subdomeinen uit.)

Header always set Content-Security-Policy: "default-src 'self'"

Content Security Policy Voorbeeld 2

Een websitebeheerder wil inhoud van een vertrouwd domein en al zijn met subdomeinen toestaan (dit hoeft niet hetzelfde domein te zijn als waarop de CSP is ingesteld).

Header always set Content-Security-Policy: "default-src 'self' *.jouwwebsite.com"

Content Security Policy Voorbeeld 3

Een websitebeheerder wil gebruikers van een webtoepassing toestaan om afbeeldingen van elke herkomst in hun eigen inhoud op te nemen, maar om audio- of videomedia te beperken tot vertrouwde providers en alle scripts alleen naar een specifieke server die vertrouwde code host.

Header always set Content-Security-Policy: "default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com"

Hier is standaard alleen content toegestaan van de oorsprong van het document, met de volgende uitzonderingen:

Afbeeldingen kunnen overal laden (let op het jokerteken "**" ).
Media is alleen toegestaan van media1.com en media2.com (en niet van subdomeinen van die sites).

Uitvoerbaar script is alleen toegestaan vanaf userscripts.example.com.

Content Security Policy Voorbeeld 4

Een websitebeheerder voor een website voor online bankieren wil ervoor zorgen dat al zijn inhoud wordt geladen met SSL, om te voorkomen dat aanvallers op verzoeken kunnen afluisteren.

Header always set Content-Security-Policy: "default-src https://onlinebanking.bobank.com"

De server staat alleen toegang toe tot documenten die specifiek via HTTPS worden geladen via de single origin onlinebanking.jumbobank.com.

Content Security Policy Voorbeeld 5

Een websitebeheerder van een webmailsite wil HTML in e-mail toestaan, evenals afbeeldingen die overal worden geladen, maar niet JavaScript of andere potentieel gevaarlijke inhoud.

Header always set Content-Security-Policy: "default-src 'self' *.mailsite.com; img-src *"

Merk op dat dit voorbeeld geen script-src opgeeft; Met het voorbeeld CSP gebruikt deze site de instelling die is opgegeven door de default-src -richtlijn. Dit betekent dat scripts alleen kunnen worden geladen vanaf de oorspronkelijke server.

Rapportage mogelijk maken

Standaard worden er geen actieverslagen verzonden. Om melding van een overtreding mogelijk te maken, moet u de beleidsrichtlijn rapport-uri specificeren, waarbij u ten minste één URI levert voor het afleveren van de rapporten:

Header always set Content-Security-Policy: "default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi"

Dan moet u uw server instellen om de rapporten te ontvangen; het kan ze opslaan of verwerken op elke manier die volgens u geschikt is.

Syntaxis voor het auteursrapport

Het JSON-rapportrapport bevat de volgende gegevens:

blocked-uri

De URI van de bron die is geblokkeerd voor laden door het inhoudsbeveiligingsbeleid. Als de geblokkeerde URI van een andere oorsprong is dan de document-uri, wordt de geblokkeerde URI afgekapt om alleen het schema, de host en de poort te bevatten.

disposition

Ofwel "afdwingen" of "rapporteren" afhankelijk van of de Content-Security-Policy-Report-Only Header of de Content-Security-Policy Header wordt gebruikt.

document-uri

De URI van het document waarin de schending heeft plaatsgevonden.

effective-directive

De richtlijn waarvan de handhaving de overtreding heeft veroorzaakt.

original-policy

Het oorspronkelijke beleid zoals gespecificeerd door de HTTP Header van het HTTP beleid voor beveiliging.

referrer

De verwijzer van het document waarin de schending heeft plaatsgevonden.

script-sample

De eerste 40 tekens van het inline script, de gebeurtenis handler of de stijl die de overtreding veroorzaakten.

status-code

De HTTP statuscode van de resource waarop het globale object is geïnstalleerd

violated-directive

De naam van de beleidssectie die is geschonden.