HTTP-Koppen

Magazine-artikel

Dit artikel is gebaseerd op een artikel uit het Joomla! Community Magazine van Brendan Hedges in de editie van mei 2022. Hoewel geschreven voor Joomla 4, is de inhoud net zo goed van toepassing op Joomla 5.

Voor wie dit onderwerp lastig te begrijpen vindt, is er een verhelderend artikel van Scott Helme over Content Security Policy - An Introduction.

De nieuwe HTTP-headers-plugin van Joomla voor J4

Na het artikel van vorige maand over beveiliging, wachtwoorden en Joomla's WebAuthn-plugin, bekijken we deze maand een andere Joomla-beveiligingsfunctie die geïntroduceerd werd met J4. Dat is de HTTP Headers plugin, die nu deel uitmaakt van Joomla's kernfuncties.

Het internet blijft zich ontwikkelen, en Joomla blijft er nooit ver achter. Daarom koos ik het als mijn favoriete platform voor webontwikkeling. Of je website nu een klein familiebedrijfje is, of een volwaardig e-commerceplatform met miljoenen aan omzet, het Joomla framework heeft voor iedereen iets te bieden, en kijkt altijd naar het implementeren van nieuwe technologieën. Sommige zijn zelfs baanbrekend.

De introductie van de HTTP Headers plugin in de kern van Joomla 4 is een enorme stap voorwaarts in het helpen beveiligen van je website tegen aanvallen en kwaadaardige activiteiten.

Deze systeembeveiligingsplugin helpt website-eigenaars om eenvoudig de HTTP Security Headers te configureren vanuit Joomla's vertrouwde beheergedeelte, in plaats van te moeten rommelen in het htaccess-bestand of andere configuratiebestanden. Of, erger nog, het Cpanel van je webhosting.

Kijk eens hoe ingewikkeld het is om dit in Cpanel in te stellen en vertel me dan dat je geen fout zult maken! En dat is er dan nog van uitgaande dat, zodra het framework in Apache is geïnstalleerd en de mappen zijn aangemaakt, je het juiste formaat kent om de HTTP headers toe te voegen die je wilt integreren.

Hoe vaak heb je al geprobeerd een htaccess-commando te implementeren, om vervolgens je website opnieuw te laden en een http500-fout te krijgen?

Het grootste probleem is dat als je het formaat van je HTTP Header niet perfect krijgt, je je website kapot maakt.

Zelfs dan, wat voor de ene website werkt, werkt misschien niet voor de andere. Een goed voorbeeld hiervan is mijn htaccess-bestand en de manier waarop ik de browser instel om een niet-www https-versie van mijn website te laden:

##www to non www and http to https mixin
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://mywebsite.co.uk%{REQUEST_URI} [R=301,L,NE]
##End www to non www and http to https mixin

Dit werkte prima bij mijn vorige hostingbedrijf. Maar toen ik overstapte naar een andere host, werkte het niet meer. Ga er maar aan staan!

De htaccess-code die ik nu moet gebruiken om hetzelfde resultaat te bereiken ziet er zo uit:

##www to non www and http to https mixin
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
##End www to non www and http to https mixin

Verwarrend, toch? En als je één foutje maakt in de opmaak, BAM! Dan is je website kapot! Nou ja, in ieder geval totdat je de code hebt gerepareerd.

Daarom betekent het eenvoudig houden van dingen, als onderdeel van Joomla's kern, minder frustratie, minder tijd verspild aan het googelen van je fouten, en meer tijd voor feest terwijl je achterover leunt in je stoel en je nieuwe website bewondert.

Laten we dus eens kijken wat HTTP headers eigenlijk zijn, hoe je de plugin kunt vinden en wat je ermee kunt doen. Het is hier wel de moeite waard om te vermelden dat deze Joomla functie een geavanceerde functie van Joomla is, die meer geschikt is voor gegevensgevoelige websites, in plaats van de nieuwe website die je liefdevol hebt gemaakt over je schattige kittens. Maar dat gezegd hebbende, zelfs eenvoudige websites moeten zo veilig mogelijk zijn om te voorkomen dat kwaadaardige code wordt uitgevoerd nadat je website is gehackt.

Wat zijn HTTP Headers?

HTTP headers mogen niet verward worden met de <head> sectie van je HTML-document. Het zijn volledig verschillende dingen. HTTP headers zijn het voorwoord tussen je webserver en de browser. Een reeks instructies die de browser vertellen wat, of nog belangrijker, wat niet te tonen aan de bezoeker.

Je kunt de HTTP Headers zien en hoe ze betrekking hebben op individuele HTML-objecten in de DEV Tools van je browser. Open in Google Chrome de DEV Tools, en dan het tabblad Network. Ververs nu de webpagina en klik op een HTML-item in het linkerdeelvenster. Het toont de HTTP Header voor dat item in het rechterdeelvenster.

Je kunt in de afbeelding hieronder zien dat de gemarkeerde afbeelding een HTTP-status van 200 retourneert, dus de browser heeft het gevonden. Er is ook een reeks andere informatie gekoppeld aan dat item, zoals bestandsgrootte en bewerkingsdatums.

Als een van je HTML-items niet is weergegeven, kun je ook een aanwijzing krijgen over de reden in de HTTP headers. In dit voorbeeld is de tweede afbeelding niet weergegeven en je kunt aan de informatie in het rechterdeelvenster zien dat er geen HTTP Header-informatie is.

Behalve het cryptische bericht:

Referrer Policy: 'strict-origin-when-cross-origin'

'Strict-origin-when-cross-origin' betekent eenvoudigweg dat wanneer een HTML-item (in dit geval een afbeelding) wordt aangeleverd vanuit een andere bron (niet je server), het op dat moment ingestelde HTTP header-beleid gevolgd moet worden. In dit voorbeeld zullen de HTTP Headers, zoals ingesteld in de Joomla plugin, alle afbeeldingen weigeren die niet afkomstig zijn van ofwel deze website, of een andere website die specifiek is 'opgenomen' in de HTTP Header-parameters die zijn ingesteld in de Joomla HTTP Headers plugin.

Dus, wanneer de afbeelding wordt opgeroepen vanuit het HTML-document, weigert de browser deze en wordt deze niet geladen.

Dit verschilt van niet gevonden worden en het retourneren van een 404 niet gevonden HTTP-foutmelding. In deze situatie wordt er nog steeds gezocht naar de afbeelding op de server die deze host, maar heeft de browser deze niet gevonden.

Wat de Joomla HTTP Headers plugin doet

Naast het vertellen aan de browser wat er weergegeven moet worden en het teruggeven van algemene informatie over het HTML-document, helpen HTTP Headers om aanvallen en beveiligingskwetsbaarheden op uw Joomla website te beperken. Dat is waar de Joomla HTTP Headers plugin tot zijn recht komt. Dit wordt bereikt door HTML-inhoud expliciet weer te geven op basis van uw instellingen in de Joomla HTTP Headers plugin zelf.

Door extra, op beveiliging gebaseerde, HTTP headers toe te voegen aan uw Joomla website met de HTTP Header plugin, biedt u nog een extra beveiligingslaag voor uw Joomla website.

Dit is belangrijk, omdat een HTML-webpagina standaard al haar inhoud aan uw bezoeker zal tonen, goed of slecht. Tenzij er in de HTTP headers van de webpagina expliciet is aangegeven dit niet te doen. De plugin doet dit door u de geavanceerde beveiligingsopties te laten configureren die beschikbaar zijn in het Content-Security-Policy voor uw website. De plugin kan voor elke website anders geconfigureerd worden, afhankelijk van uw vereisten, dus het is een werkelijk flexibel wapen in uw arsenaal tegen hackers.

Waarom heb ik deze plugin nodig?

In een ideale wereld zou dat niet zo zijn. In de wereld waarin we leven, zijn er echter veel te veel gewetenloze mensen die manieren proberen te vinden om geld te verdienen ten koste van onschuldige en argeloze mensen. In onze wereld noemen we deze mensen hackers. Hackers doen er alles aan om kwetsbaarheden in software te misbruiken voor financieel gewin, vaak ten nadele van de website-eigenaar.

Door gebruik te maken van Joomla's HTTP Header plugin om te bepalen welke inhoud aan uw bezoekers wordt aangeboden, verkleint u de kans dat hackers kwaadaardige website-inhoud aan uw bezoekers kunnen leveren via verouderde, kwetsbare plugins. Dit helpt om kwaadaardige scriptinjecties op uw website tegen te gaan.

Laten we dus even nadenken over deze hypothetische situatie.

U heeft een mooie Joomla 3 website. Deze is 5 jaar geleden gemaakt en ziet er nog steeds goed uit en werkt perfect. Al uw componenten, plugins en modules zijn up-to-date. Perfect, toch?

Nou, niet helemaal, want toen u uw website 5 jaar geleden maakte, installeerde u de trendy Foo Bar Plugin om "FOO BAR" op uw startpagina af te drukken. Het zag er eerst cool uit, maar na een tijdje veranderde u van gedachten en verwijderde u de shortcode {foo}FOO - BAR{/bar} van de plugin uit uw startpagina-artikel.

Maar hier is het probleem: u heeft de plugin zelf niet gedepubliceerd of verwijderd en het gebruik ervan is in de vergetelheid geraakt. Dit is iets waar we ONS ALLEMAAL wel eens schuldig aan hebben gemaakt, dat weet ik zeker.

Snel vooruit naar vandaag, 5 jaar later, die plugin staat er nog steeds, gepubliceerd en actief op uw website, maar hij is al 5 jaar niet bijgewerkt omdat u de plugin allang vergeten bent, of omdat de auteur gestopt is met de ondersteuning ervan. Nu heeft een of andere kwaadwillende ontdekt dat deze plugin een beveiligingslek heeft dat uitgebuit kan worden om een Cross Site Scripting (XSS) aanval op uw website te starten, en uw nietsvermoedende bezoekers tot slachtoffer te maken.

Cross-site scripting, ook bekend als XSS, is een kwetsbaarheid in uw website waarmee een aanvaller de interacties die uw gebruikers hebben met uw nu kwetsbare website kan compromitteren.

De aanvaller/hacker gebruikt XSS om uw kwetsbare website te misbruiken en een kwaadaardig script naar uw nietsvermoedende gebruiker te sturen. Omdat het script van uw website afkomstig is, weet of vermoedt de browser van uw gebruiker niet dat het script niet vertrouwd zou moeten worden, en voert het script uit wanneer de webpagina laadt en opent.

Kwaadaardige scripts die op deze manier worden uitgevoerd kunnen veel problemen voor uw gebruiker veroorzaken, van het stelen van inloggegevens en gebruikersnamen die in cookies zijn opgeslagen, tot het sturen van uw gebruiker naar nepphishingwebsites. Scripts kunnen zelfs het uiterlijk van de webpagina die uw website toont veranderen en u andere advertenties laten zien.

Het gebruik van de HTTP Headers plugin van Joomla helpt cross-site scripting te stoppen door ervoor te zorgen dat alleen de scripts en inhoud die u aan uw bezoeker wilt tonen daadwerkelijk getoond worden. Al het andere wordt geblokkeerd.

Dus, in het bovenstaande voorbeeld had u de HTTP Headers plugin kunnen configureren om alleen de JavaScript(script)bestanden van uw website vanuit een opgegeven map, of misschien een CDN als u er een gebruikt, te tonen om de aanval te stoppen.

U zou de website ook kunnen beletten om inline JavaScript dat in de HTML is ingesloten uit te voeren. Maar houd er rekening mee dat dit, afhankelijk van hoe u de HTML van uw website hebt ontworpen, verderop problemen kan veroorzaken.

Dit zou dan helpen om te voorkomen dat kwaadaardige JavaScript-code op uw website wordt uitgevoerd. Zelfs als uw kwetsbare Foo Bar Plugin de schuldige was dat een hacker in eerste instantie kwaadaardige code in uw website kon injecteren.

Notitie:

Veelvoorkomende zwakke punten op websites die gevoelig zijn voor XSS-aanvallen zijn gebruikersinvoerformulieren (inlogpagina's, inschrijfformulieren voor nieuwsbrieven, contactformulieren, enz.) zonder validatie en versleuteling.

Waar bevindt zich de HTTP Headers Plugin?

U vindt de HTTP Headers plugin van Joomla samen met alle andere Joomla plugins, en u krijgt er toegang toe op precies dezelfde manier als u gewend bent.

De HTTP Headers Plugin gebruiken

Het gebruik van de HTTP Plugin van Joomla is relatief eenvoudig, hoewel het een goed idee kan zijn om, voordat u wijzigingen aanbrengt in de standaardinstellingen, u te verdiepen in een aantal speciale termen die met het gebruik ervan te maken hebben. Hoewel, dat gezegd hebbende, sommige daarvan u al bekend zouden moeten zijn.

Bijvoorbeeld:

Bij het werken met afbeeldingen ziet u de term 'img-src', waarbij 'img' verwijst naar afbeeldingen en 'src' naar de geldige bron van de afbeelding. Dit zijn termen die we al kennen van basis-HTML.

Aan het einde van dit artikel vindt u een lijst met nuttige websites met aanvullende informatie om u te helpen deze Joomla plugin te gebruiken.

HTTP Headers Plugin Instellingen - Tab 1

Wanneer u de plugin opent, is het eerste geopende tabblad de basisinstellingen van de plugin. Hier kunt u aanpassingen maken aan X-Frame Options, het Referrer-Policy, Cross-Origin-Opener-Policy en ook Force HTTP Headers. Er zijn ook enkele links naar meer informatie om u te helpen begrijpen wat deze items in meer detail doen.

Laten we elk van deze stuk voor stuk bekijken.

X-Frame Options

De eerste instelling is voor de X-Frame Options. Deze is standaard ingeschakeld.

Met deze optie kan bepaald worden of de inhoud van de website kan worden weergegeven op een andere website in een <frame>, <iframe>, <embed> of <object>. Als deze optie wordt uitgeschakeld, kan elke andere website de website in een iframe weergeven.

Eenmaal ingeschakeld, wordt een ‘x-frame-options: SAMEORIGIN’ tag toegevoegd aan de koppen van de website. Deze tag staat nog steeds toe dat de eigen inhoud wordt weergegeven in een <frame>, <iframe>, <embed> of <object>, op de eigen website. Maar niemand anders kan de inhoud in een <iframe> op hun eigen website weergeven.

De X-Frame Option Header helpt de website en gebruikers te beschermen tegen ‘Click Jacking’ aanvallen. Hierbij plaatst een aanvaller een <iframe> op zijn eigen website en stelt de bron van de <iframe> in als de website van het slachtoffer. Vervolgens gebruikt de aanvaller meerdere transparante lagen van zijn eigen website erboven.

Dit misleidt een gebruiker om op een knop of link op de transparante bovenste laag te klikken, omdat de gebruiker denkt dat hij op een link in de onderliggende iframe klikt.

Zo "kaapt" de aanvaller klikken die bedoeld waren voor de oorspronkelijke geframede pagina en stuurt ze naar een andere webpagina.

Ernstiger nog, soortgelijke praktijken kunnen worden gebruikt om toetsaanslagen te verzamelen voor wachtwoord- en gebruikersnaamgegevens bij het inloggen op e-mailaccounts, social media accounts en natuurlijk de bankrekening.

De meeste moderne browsers ondersteunen X-Frame Options, wat geweldig is. Mijn aanbeveling is daarom om deze instelling in de HTTP Headers plugin in te schakelen om gebruikers te helpen beschermen tegen het slachtoffer worden van 'Click Jacking'.

De meeste moderne browsers ondersteunen de X-Frame Options.

Referrer-Policy

Het volgende item op de lijst in het eerste tabblad is de Referrer-Policy. Indien ingeschakeld, kan hiermee gekozen worden hoeveel van de potentiële websitegegevens worden doorgegeven aan een andere website wanneer op een link of ander HTML-object op de website wordt geklikt.

Vaak zien we dit ingesteld als een HTML-attribuut op <a> tags, waarbij een link geformatteerd kan worden als <a href=”https://someplace.com” rel=”noreferrer”>Klik hier</a>. De noreferrer tag houdt de details van de verzendende webpagina geheim voor de ontvangende webpagina. Dit gebeurt door de verwijzingsinformatie uit de HTTP header van de webpagina te verwijderen.

Bewust zijn van de gegevens die de website mogelijk 'lekt' naar een andere website waarnaar gelinkt wordt, is een belangrijk onderdeel van het beveiligen van de website en de gebruikers ervan.

Dit geldt vooral als gebruikers zich kunnen registreren, als er gevoelige gegevens worden verwerkt, of als de website geldtransacties afhandelt. De HTTP Headers plugin van Joomla helpt dit op globaal niveau te beheersen, in plaats van op individueel linkniveau.

Standaard is het Referrer Policy van de website ingesteld op ‘strict-origin-when-cross-origin’. Dit blokkeert geen van de verwijzingsgegevens van de oorspronkelijke webpagina, tenzij deze worden verzonden naar een minder veilige http-pagina. Maar aangezien de meeste webpagina's tegenwoordig https gebruiken, is dit nu een groter probleem dan het ooit was.

Er zijn natuurlijk veel onschuldige toepassingen van deze ‘gelekte’ gegevens als er geen Referrer-Policy is ingesteld voor uw website. Dit kan onder meer gaan om gegevens die door de gelinkte website worden verzameld voor analyse, loggen, of geoptimaliseerd cachen.

Helaas gebruikt niet elke website waarnaar verwezen wordt uw ‘gelekte’ gegevens voor dergelijke onschuldige doeleinden. Neem de volgende situatie als voorbeeld.

De meeste websites die gebruikersregistratie toestaan, hebben een link voor het resetten van het wachtwoord naast hun inlogformulier op een inlog-/registratiepagina. Het is ook waarschijnlijk dat de webpagina ook andere links naar externe websites bevat, links naar sociale media, of misschien staan er ‘Nuttige Links’ in de voettekst.

Deze leiden allemaal weg van uw beveiligde omgeving. Als er nu geen Referrer-Policy is ingesteld, is het mogelijk dat de Referrer Header die wordt verzonden naar een van die externe websites wanneer er op een link wordt geklikt vanaf die inlogpagina, de link voor het resetten van het wachtwoord bevat. Evenals andere informatie die u met die externe website hebt gedeeld.

Dit kan een beveiligingsrisico vormen voor de gebruiker doordat zijn gegevens in gevaar komen.

Vanwege het mogelijke beveiligingsrisico op dit soort gegevensgevoelige pagina's, is het ook goede praktijk om alle inhoud van derden van de pagina te verwijderen. Dit zou alle links en inhoud omvatten die wordt geleverd in <iframes>, zoals sociale media-widgets en YouTube-video's. Omdat gegevens die op deze pagina worden ingevoerd via de Referrer Header naar die sites kunnen worden verzonden als u op die schattige kittenvideo klikt die net is opgedoken.

Joomla’s HTTP Headers plugin pakt dit probleem aan door u de keuze te geven uit één van de 8 Referrer-Policies om een Referrer-Policy voor uw website in te stellen. Elk met hun eigen beperkingen voor wanneer en hoeveel gegevens er gedeeld worden.

Laten we hier eens naar kijken. Er staat een uitstekende beschrijving hiervan op de Mozilla Headers-pagina, waarin ze als volgt worden omschreven:

• no-referrer
  De Referrer Header wordt weggelaten: verzonden verzoeken bevatten geen enkele verwijzingsinformatie.
• no-referrer-when-downgrade
  Verstuur de oorsprong, het pad en de queryreeks in de Referrer Header wanneer het beveiligingsniveau van het protocol gelijk blijft of verbetert (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Verstuur de Referrer Header niet voor verzoeken naar minder veilige bestemmingen (HTTPS→HTTP, HTTPS→bestand).
• origin
  Verstuur alleen de oorsprong in de Referrer Header. Bijvoorbeeld, een document op https://example.com/page.html zal de verwijzing https://example.com/ versturen.
• origin-when-cross-origin
  Bij het uitvoeren van een verzoek binnen dezelfde oorsprong naar hetzelfde protocolniveau (HTTP→HTTP, HTTPS→HTTPS), verstuur de oorsprong, het pad en de queryreeks. Verstuur alleen de oorsprong voor verzoeken buiten de oorsprong en verzoeken naar minder veilige bestemmingen (HTTPS→HTTP).
• same-origin
  Verstuur de oorsprong, het pad en de queryreeks voor verzoeken binnen dezelfde oorsprong. Verstuur de Referrer Header niet voor verzoeken buiten de oorsprong.
• strict-origin
  Verstuur alleen de oorsprong wanneer het beveiligingsniveau van het protocol gelijk blijft (HTTPS→HTTPS). Verstuur de Referrer Header niet naar minder veilige bestemmingen (HTTPS→HTTP).
• strict-origin-when-cross-origin (standaard)
  Stuur de oorsprong, het pad en de queryreeks bij een verzoek binnen dezelfde oorsprong. Stuur bij verzoeken buiten de oorsprong alleen de oorsprong wanneer het beveiligingsniveau van het protocol gelijk blijft (HTTPS→HTTPS). Stuur de Referrer header niet naar minder veilige bestemmingen (HTTPS→HTTP). Notitie: Dit is het standaardbeleid als er geen beleid wordt opgegeven, of als de opgegeven waarde ongeldig is. Voorheen was de standaard no-referrer-when-downgrade.
• unsafe-url
  Stuur de oorsprong, het pad en de queryreeks bij elk verzoek, ongeacht de beveiliging. Waarschuwing: Dit beleid kan mogelijk privé-informatie uit HTTPS-resource-URL's laten lekken naar onveilige oorsprongen. Overweeg zorgvuldig de impact van deze instelling.

Cross-Origin-Opener-Policy

De derde optie die in het eerste tabblad kan worden ingesteld is de Cross Origin Opener Policy, een browsergebaseerde beveiligingsfunctie waarmee verschillende ‘Browser Context Groups' van elkaar kunnen worden losgekoppeld.

Een goed voorbeeld hiervan is het gebruik van pop-ups. Waarbij de oorspronkelijke browser context group (alle tekst, afbeeldingen, links enz.) wordt losgekoppeld van een nieuwe browser context group die wordt aangemaakt en vervolgens in de pop-up wordt weergegeven.

Deze HTTP Header optie is behoorlijk uitgebreid en ingewikkeld, hoewel er maar 3 opties zijn. Daarom wordt u aangemoedigd om de onderstaande links te bekijken om een beter begrip te krijgen van waarom deze optie op uw website moet worden ingesteld. Alsook om meer te leren over een aantal van de geavanceerde functies die beschikbaar komen wanneer deze optie actief is.

De Cross Origin Opener Policy helpt een historisch lek te dichten in de manier waarop browsers data delen tussen verschillende context groups, met name wanneer er pop-ups op de website worden gebruikt.

Het instellen van uw COOP helpt u databeveiligingsdreigingen te beperken, waarvan de bekendste ‘Spectre’ wordt genoemd. Spectre maakt data die in dezelfde browsing context group als uw code wordt geladen mogelijk leesbaar voor een hacker. Spectre maakt het mogelijk om te meten hoe lang bepaalde bewerkingen duren. Hierdoor kunnen die hackers raden wat er in de CPU-cache staat. Als dat lukt, weten ze wat er in het procesgeheugen staat. Daarna hebben ze toegang tot uw data. Die gevoelig kan zijn.

COOP werkt door de originele HTML-documentgegevens te isoleren van de HTML-gegevens die worden weergegeven in een pop-up vanuit het originele document. Dit helpt te voorkomen wat bekend staat als cross-origin aanvallen, of XS-Leaks.

Dit proces lijkt op het bekende rel=”noopener” dat wordt gebruikt bij gewone links. Maar, in tegenstelling tot rel=”noopener”, dat alleen actief is op uitgaande links, beperken documenten waarvoor de cross-origin-opener-policy is ingesteld in de HTTP headers door de Joomla plugin, gegevens in beide richtingen. Hierdoor zal het HTML-document met een actief COOP-beleid geen referentie hebben in de HTTP Header, en zal de window.opener HTTP Header eigenschap van het nieuwe venster worden ingesteld op null.

Bij het instellen van deze optie in de Joomla HTTP Header plugin, zijn er 3 opties beschikbaar.

• unsafe-none
  Dit is de standaardwaarde. Het staat toe dat uw document wordt toegevoegd aan de browser context group van de opener, tenzij de opener zelf een cross-origin-opener-policy heeft van same-origin of same-origin-allow-pop-ups.
• same-origin-allow-popups
  Deze optie behoudt referenties naar nieuw geopende vensters of tabbladen die ofwel geen cross-origin-opener-policy instellen, of die zich afmelden voor isolatie door zelf een cross-origin-opener-policy van unsafe-none in te stellen.
• same-origin
  Isoleert de browser context group alleen tot documenten binnen dezelfde oorsprong. Documenten buiten de oorsprong worden niet geladen in dezelfde browser context group.

Force HTTP Headers

De laatste optie om op te focussen in het eerste tabblad is Force HTTP Headers, niet te verwarren met ‘Force HTTPS’ in de algemene instellingen van Joomla.

Dit onderdeel van de Joomla HTTP Header plugin biedt de mogelijkheid om, indien gewenst, een selectie van ‘overige’ headers toe te voegen die niet specifiek in de plugin tabbladen zijn uitgewerkt, en ook om het opnemen van sommige al opgenomen headers te forceren.

In de keuzelijst zijn momenteel 10 opties beschikbaar. Het is echter de moeite waard om op te merken dat sommige hiervan na verloop van tijd kunnen vervallen omdat de headerbeleidsregels waarnaar ze verwijzen aan verandering onderhevig zijn, of opnieuw worden vormgegeven.

De huidige HTTP headers die hier rechtstreeks ingesteld kunnen worden, zijn headers die gericht zijn op het volgende:

Meer informatie over elke functie is te vinden op de Mozilla Developers website.

Content-Security-Policy (lijst)

De Content-Security-Policy response header biedt websites de mogelijkheid om controle uit te oefenen over de bronnen die de gebruiker mag laden voor elke webpagina. Beleidsregels specificeren meestal serveroorsprongen en scripteindpunten. Dit helpt bescherming te bieden tegen cross-site scripting aanvallen. Mozilla: Content-Security-Policy

Content-Security-Policy-Report-Only

De HTTP Content-Security-Policy-Report-Only response header biedt webontwikkelaars de mogelijkheid om te experimenteren met beleidsregels door de effecten ervan te monitoren (zonder ze af te dwingen). Mozilla: Content-Security-Policy-Report-Only

Cross-Origin-Opener-Policy (COOP)

De HTTP Cross-Origin-Opener-Policy (COOP) response header biedt de mogelijkheid om ervoor te zorgen dat een document op het hoogste niveau geen Browser Context Group deelt met documenten buiten de oorsprong. Mozilla: Cross-Origin-Opener-Policy

COOP isoleert het proces van het document en potentiële aanvallers kunnen geen toegang krijgen tot het globale object als ze dit in een pop-up zouden openen, waardoor een reeks cross-origin aanvallen die bekendstaan als XS-Leaks wordt voorkomen.

Expect-CT (wordt uitgefaseerd)

De Expect-CT header biedt websites de mogelijkheid om zich aan te melden voor rapportage en/of handhaving van Certificate Transparency vereisten, om te voorkomen dat het gebruik van onjuist uitgegeven certificaten voor die website onopgemerkt blijft. Mozilla: Expect-CT (To Be Discontinued)

Feature-Policy (inmiddels verouderd)

De HTTP Feature-Policy header biedt een mechanisme om het gebruik van browserfuncties toe te staan of te weigeren binnen het eigen frame, en binnen inhoud in eventuele <iframe> elementen in het document. Mozilla: Feature-Policy

Permissions-Policy

Dit is de vervanging voor de hierboven genoemde Feature-Policy. Mozilla: Permissions-Policy (Replaces Feature Policy Above)

Referrer-Policy (in lijst)

De Referrer-Policy HTTP header bepaalt hoeveel verwijzingsinformatie (verzonden met de Referrer Header) bij verzoeken moet worden meegestuurd. Mozilla: Referrer-Policy

Report-To

Onderdeel van de Content-Security-Policy. Het Content-Security-Policy Report-To HTTP response headerveld instrueert de user agent om rapportage-eindpunten voor een oorsprong op te slaan. Mozilla: Report-To

De report-to richtlijn is bedoeld om de verouderde report-uri richtlijn te vervangen, report-to wordt in de meeste browsers nog niet ondersteund.

Strict-Transport-Security

De HTTP Strict-Transport-Security response header (vaak afgekort als HSTS) informeert browsers dat de website alleen benaderd mag worden via HTTPS, en dat toekomstige pogingen om deze via HTTP te benaderen automatisch omgezet moeten worden naar HTTPS. Mozilla: Strict-Transport-Security

Dit is veiliger dan het simpelweg instellen van een HTTP naar HTTPS (301) verwijzing op de server, waarbij de eerste HTTP-verbinding nog steeds kwetsbaar is voor een man-in-the-middle aanval.

X-Frame-Options (in lijst)

De X-Frame-Options HTTP response header geeft aan of een browser toestemming heeft om een pagina weer te geven in een <frame>, <iframe>, <embed> of <object>, of niet. Websites kunnen dit gebruiken om click-jacking aanvallen te vermijden, door ervoor te zorgen dat hun inhoud niet wordt ingesloten in andere websites.Mozilla: X-Frame-Options

De toegevoegde beveiliging wordt alleen geboden als de gebruiker die het document bezoekt een browser gebruikt die X-Frame-Options ondersteunt.

De X-Frame-Options header heeft onderliggende items genaamd frame-ancestors die de Frame-Options header vervangen. Als een bron beide beleidsregels heeft, wordt het frame-ancestors beleid afgedwongen en wordt het X-Frame-Options beleid genegeerd.

Met behulp van het HTTP Header Value veld kunt u de waarden instellen die u wilt laten toepassen en deze toewijzen aan uw website, de beheerderswebsite, of beide.

HTTP Headers Plugin Instellingen - TAB 2

Strict-Transport-Security (HSTS)

Het tabblad Strict Transport Security Policy is standaard uitgeschakeld.

Ik hou van onderzoek doen. Want soms kom je een echt OMG! Moment tegen. Dit is zo'n moment.

Wikipedia stelt:

Netscape Communications creëerde HTTPS in 1994 voor zijn Netscape Navigator webbrowser. Oorspronkelijk werd HTTPS gebruikt met het SSL-protocol. Toen SSL evolueerde naar Transport Layer Security (TLS), werd HTTPS formeel gespecificeerd door RFC 2818 in mei 2000. Google kondigde in februari 2018 aan dat zijn Chrome-browser HTTP-sites als "Niet veilig" zou markeren, na juli 2018. Deze stap was bedoeld om website-eigenaren aan te moedigen HTTPS te implementeren, als onderdeel van een inspanning om het World Wide Web veiliger te maken.” ……

Wie had gedacht dat Netscape de HTTPS-protocollen al zo lang geleden heeft uitgevonden? Wat nog verrassender is, is hoe lang het duurde voordat het werd geïmplementeerd in het internet zoals we dat vandaag de dag kennen en liefhebben.

Al jaren proberen ze ons te overreden, onder druk te zetten en uiteindelijk te bedreigen om HTTPS op al onze websites te implementeren. De meesten van ons hebben toegegeven en het world wide web is nu eindelijk veilig. Of is dat zo?

Er zijn echter nog enkele doorzetters, diehards of vergeten websites die nog steeds alleen http gebruiken om hun inhoud te leveren, zij het met een waarschuwing “Deze website is onveilig” van Google/Firefox enzovoort.

Een snelle zoekopdracht in Google leverde verschillende verouderde lijsten op van die ‘alleen-HTTP schuldige’ websites. Hoewel sinds het publiceren van die lijsten veel websites zijn bijgewerkt naar HTTPS. Er waren echter enkele opvallende uitzonderingen van organisaties waarvan je zou denken dat ze het beter zouden moeten weten.

Bijvoorbeeld:

• NGINX (http://nginx.org/)
• GNU (http://www.gnu.org/)
• The University of Washington (http://www.washington.edu/)

Volgens w3techs.com draait ongeveer 20% van alle websites nog steeds alleen op HTTP.

Dus, waarom is dit een probleem?

Dit is een probleem omdat alle gegevens die vanuit en naar de browser van een gebruiker worden verzonden, risico lopen onderschept te worden. Dit staat bekend als een man-in-the-middle aanval. Dit lijkt misschien geen belangrijke overweging als uw website alleen over foto's van schattige kittens gaat.

Maar zelfs eenvoudige websites kunnen slachtoffer worden van hackers en aanvallers die click-jacking en andere cross-origin aanvallen uitvoeren die uw gebruikers schade berokkenen.

Een website die geen gebruikersgegevens of inloggegevens uitwisselt, moet toch HTTPS gebruiken.

Oké, laten we teruggaan naar het onderwerp.

Zoals u al weet, is het hele punt van HTTPS om een beveiligde verbinding tot stand te brengen tussen de browser van de gebruiker en uw server. Een verbinding waarbij elke gegevensuitwisseling plaatsvindt in een beveiligde omgeving die niet onderschept en gekopieerd kan worden door een derde partij. Een man in het midden.

Maar wist u dat uw 'beveiligde' verbinding niet zo veilig is als u zou verwachten, tenzij uw HTTPS SSL-certificaat gebruikmaakt van TLS? Niet-TLS HTTPS-verbindingen zijn nog steeds kwetsbaar voor man-in-the-middle aanvallen.

Hoewel het een oude blogpost is, legt dit artikel mooi uit hoe een man-in-the-middle aanval werkt.

Browsers hebben TLS op grote schaal overgenomen.

En TLS 1.3 is niet direct compatibel met eerdere versies, tenzij het wordt uitgevoerd in compatibiliteitsmodus. Dat kan voor sommigen een probleem vormen.

Het gebruik van Joomla's HTTP Header Plugin om Strict-Transport-Security (HSTS) af te handelen helpt man-in-the-middle aanvallen te beperken door het gebruik van TLS in de webbrowser van uw bezoekers af te dwingen. TLS zorgt ervoor dat alle webcommunicatie aan de kant van de Adverteerder plaatsvindt via een beveiligde transportlaag.

Gebruikt u een 301-verwijzing om de niet-beveiligde HTTP-versie van uw website naar de beveiligde HTTPS-versie te sturen?

De meeste mensen doen dat. 301-verwijzingen zijn instructies die de meeste website-eigenaren instellen in hun htaccess-bestand. Ze laten Google weten dat de versie van de website die gebruikt moet worden de HTTPS (beveiligde) versie is. Het probleem hiermee is dat de 301 slechts een URL-verwijzing is, waardoor uw website nog steeds een deel van de initiële verbinding via HTTP tot stand brengt.

In tegenstelling tot verbindingen tussen een gebruiker en een websiteserver die HSTS gebruiken, waarbij de server automatisch alleen via HTTPS communiceert.

HSTS heeft echter een zwak punt, aangezien de eerste initiële verbinding tussen de browser van de gebruiker en de websiteserver nog steeds via HTTP plaatsvindt. Maar alle volgende verbindingen worden automatisch via HTTPS gemaakt totdat de vervaldatum van de HTTP Header is bereikt en deze header opnieuw wordt ingesteld.

Dit is anders dan bij een standaard 301-verwijzing, waarbij elke paginaweergave een initieel http-verzoek bevat om de https-verbinding te starten.

Er is een oplossing voor dit zwakke punt in de HTTP Headers HSTS-instellingen: activeer 'Preload'.

Hiermee wordt de 'Preload'-tag toegevoegd aan de response header.

In de instellingen is er ook een link preload-lijst**. Dit is een lijst die hard gecodeerd is in veel moderne browsers. De lijst informeert de browser dat de verbinding met example.com alleen via HTTPS tot stand gebracht mag worden. Hierdoor hoeft de initiële verbinding zelfs niet meer via HTTP gemaakt te worden.

Zodra HSTS is ingesteld in de Joomla HTTP Headers plugin, worden alle benodigde tags toegevoegd aan de HTTP Response header. Dit laat de browser van elke gebruiker die probeert verbinding te maken met uw server weten dat alle verbindingen moeten plaatsvinden via HTTPS, ongeacht of dit in uw HTML is opgegeven of niet.

Kortom, het gebruik van de HTTP Headers plugin van Joomla om HSTS te integreren in plaats van te vertrouwen op 301-verwijzingen om uw inhoud via HTTPS aan te bieden, is een belangrijke beveiligingsverbetering. Een verbetering die helpt om man-in-the-middle aanvallen te stoppen, en uw gebruiker een veilige omgeving biedt.

HSTS dekt het hele domein, in tegenstelling tot een 301-verwijzing die alleen een specifiek URI-pad dekt.

HSTS gebruikt een aparte browsercache die meestal afgescheiden is, zodat deze niet gemakkelijk of per ongeluk gewist kan worden.

HSTS kan vooraf geladen worden in een browser. Dit zorgt ervoor dat een gebruiker alleen via HTTPS verbinding maakt met uw server, ongeacht of deze de website al eerder bezocht heeft.

HTTP Headers Plugin Instellingen - TAB 3

Content Security Policy (tabblad 3)

Het tabblad Content Security Policy is standaard uitgeschakeld.

Wanneer u Joomla's Content Security Policy inschakelt via de HTTP Headers plugin, vertelt u de browser van uw bezoeker precies welke middelen vanaf de server van uw website geladen worden. Dit is een uitstekende manier om ervoor te zorgen dat u alleen de inhoud aanbiedt die u daadwerkelijk wilt aanbieden.

Een effectief Content Security Policy beleid is een doeltreffende manier om Cross-Site Scripting (XSS)- en Click Jacking-aanvallen afkomstig van uw website te stoppen.

Cross-Site Scripting, ook bekend als een XSS-aanval, is een aanval op uw website waarbij een kwaadaardig script wordt 'geïnjecteerd' in een nietsvermoedende en verder vertrouwde website. Aanvallers zoeken een zwak punt om te misbruiken, meestal waar een gebruiker gegevens kan invoeren.

Verouderde componenten die gebruikersinvoer toestaan, bijvoorbeeld ongevalideerde commentaarformulieren, kunnen kwetsbaarheden bevatten die misbruikt kunnen worden bij een Cross Site Scripting-aanval. Daarom is het een goed idee om uw Joomla componenten altijd bij te werken en die mogelijkheden te minimaliseren.

Dus, met het geïnfecteerde commentaarformulier als voorbeeld:

Uw website gebruikt een reactieformulier aan het eind van een artikel om gebruikersdiscussie te verzamelen, zoals veel websites doen. Dat is geweldig.

Uw reactie-extensie van dodgy-joomla-extensions.com werkt prima en uw gebruikers zijn er dol op. Maar u heeft hem al 5 jaar niet bijgewerkt en de ontwikkelaars hebben hem allang in de steek gelaten.

Nu, 5 jaar later, ontdekt Mr Hacker dat hij door een kwetsbaarheid in de code van de reactie-component een stuk kwaadaardige code kan verbergen in een reactie die verder onschuldig lijkt.

Wat die code uiteindelijk doet verschilt, maar u kunt erop rekenen dat telkens wanneer uw onschuldige artikelpagina wordt geladen, met de reacties, die kwaadaardige code ook wordt geladen en uitgevoerd. Het maakt immers deel uit van de HTML, en de browser weet niet dat het daar niet hoort te staan, of niet vertrouwd zou moeten worden.

Dus de kwaadaardige code wordt uitgevoerd. Misschien controleert het uw cookiegegevens. Misschien steelt het gevoelige gegevens die door de browser worden bewaard. Of misschien laadt het advertenties van online casino's of volwassen websites. Misschien herlaadt het de HTML van uw onschuldige webpagina over die schattige kittens volledig vanaf een extern JavaScript-bestand om de creditcardgegevens van uw gebruikers te stelen.

Op dit punt kan een script worden uitgevoerd om bijna alles te bereiken.

Een goed Content Security Policy helpt dit soort aanvallen te stoppen, zelfs als uw gecompromitteerde reactie-extensie het doelwit wordt van Mr Hacker.

Dit lukt doordat de Joomla HTTP Header plugin de CSP levert als een HTTP Response Header, die expliciet aan de browser vertelt wat geladen mag worden. In de instellingen van het CSP tabblad in de HTTP headers plugin kunt u rechtstreeks 28 Policy Directives instellen. De richtlijnen helpen uw website te beveiligen door alleen goedgekeurde bronnen voor uw bestanden en inhoud te gebruiken.

Het bovenstaande aanvalsvoorbeeld eindigde met het laden van een JavaScript-bestand vanaf een andere bron om de HTML-uitvoer die op het scherm werd weergegeven te wijzigen. Dit had voorkomen kunnen worden door de richtlijn script-src 'self' toe te voegen aan Joomla's CSP in de plugin.

In dit voorbeeld zal de browser alleen JavaScript-bestanden in het HTML-document laden als ze afkomstig zijn van uw domein. Alle andere JavaScript-bestanden worden geweigerd, inclusief die van Mr Hacker.

Hoewel dit helpt om uw website te beveiligen, kan het ook andere legitieme JavaScript-bestanden tegenhouden die u wilt laden terwijl de webpagina op het scherm wordt weergegeven. Deze externe bestanden kunnen worden toegevoegd als bronnen op de witte lijst binnen dezelfde richtlijn. Als u bijvoorbeeld bootstrap gebruikt vanaf een CDN, zou u toevoegen:

script-src 'self' https://cdn.jsdelivr.net

Als u in dit voorbeeld problemen ondervindt bij het laden van bootstrap vanaf het CDN, https://cdn.jsdelivr.net, kunt u proberen de volledige URL van het benodigde bootstrap-bestand toe te voegen. U zou uw richtlijn dan als volgt opmaken: script-src 'self' https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.min.js.

Het toevoegen van deze externe bronnen is eenvoudiger te implementeren op een nieuwe website terwijl u deze opbouwt. Maar als u uw weergegeven HTML doorzoekt met Dev Tools, zou u alle externe bestanden die al worden gebruikt op uw bestaande website moeten kunnen vinden, en deze kunnen opnemen in uw CSP.

Bij het toevoegen van directives aan uw Content Security Policy in de HTTP Headers Plugin, is er een reeks kernwaarden die u kunt gebruiken om te bepalen wat expliciet geladen moet worden door de browser. Dit zijn de basiswaarden om uw eerste Content Security Policy in te stellen.

Voor sommige van de meer geavanceerde directives zijn andere opties beschikbaar, een uitgebreidere lijst en voorbeelden van hun gebruik zijn te vinden op de website van de Content Security Policy (CSP) Quick Reference Guide.

• 'none' blokkeert het gebruik van dit type bron.
• 'self' komt overeen met de huidige oorsprong (maar niet subdomeinen).
• 'unsafe-inline' staat het gebruik van inline JS en CSS toe.
• 'unsafe-eval' staat het gebruik van mechanismen zoals eval() toe.

Laten we eens kijken naar enkele van die directives. Hier is een lijst van enkele directives die beschikbaar zijn in de Joomla HTTP Headers plugin, samen met een korte beschrijving, dankzij Content Security Policy. Ik raad u aan deze website te bezoeken voor meer informatie en voorbeelden.

default-src

De default-src directive bepaalt het standaardbeleid voor het ophalen van bronnen zoals JavaScript, Afbeeldingen, CSS, Lettertypen, AJAX-verzoeken, Frames, HTML5 Media.
VOORBEELD DEFAULT-SRC BELEID
default-src 'self' https://cdn.example.com

script-src

Bepaalt geldige bronnen van JavaScript.
VOORBEELD SCRIPT-SRC BELEID
script-src 'self' https://js.example.com

style-src

Bepaalt geldige bronnen van stylesheets of CSS.
VOORBEELD STYLE-SRC BELEID
style-src 'self' css.example.com

img-src

Bepaalt geldige bronnen van afbeeldingen.
VOORBEELD IMG-SRC BELEID
img-src 'self' https://img.example.com https://example.com

connect-src

Is van toepassing op XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> of EventSource. Indien niet toegestaan emuleert de browser een 400 HTTP-statuscode.
VOORBEELD CONNECT-SRC BELEID
connect-src 'self'

font-src

Bepaalt geldige bronnen van lettertypebronnen (geladen via @font-face).
VOORBEELD FONT-SRC BELEID
font-src https://font.example.com https://example.com

object-src

Bepaalt geldige bronnen van plugins, bijv. <object>, <embed> of <applet>.
VOORBEELD OBJECT-SRC BELEID
object-src 'self'

media-src

Bepaalt geldige bronnen van audio en video, bijv. HTML5 <audio>, <video> elementen.
VOORBEELD MEDIA-SRC BELEID
media-src https://media.example.com

frame-src

Bepaalt geldige bronnen voor het laden van frames. In CSP Niveau 2 werd frame-src afgeraden ten gunste van de child-src directive. CSP Niveau 3 heeft frame-src weer in gebruik genomen en zal nog steeds teruggrijpen op child-src als deze niet aanwezig is.
VOORBEELD FRAME-SRC BELEID
frame-src 'self'

sandbox

Schakelt een sandbox in voor de opgevraagde bron, vergelijkbaar met het sandbox-attribuut van iframe. De sandbox past een beleid binnen dezelfde oorsprong toe, voorkomt pop-ups, plugins en scriptverwerking wordt geblokkeerd. U kunt de sandbox-waarde leeg houden om alle beperkingen te behouden, of waarden toevoegen: allow-forms allow-same-origin allow-scripts allow-pop-ups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, en allow-top-navigation.
VOORBEELD SANDBOX BELEID
sandbox allow-forms allow-scripts

report-uri

Instrueert de browser om rapporten van beleidsfouten te POSTen naar deze URI. U kunt ook Content-Security-Policy-Report-Only gebruiken als de HTTP header naam om de browser te instrueren alleen rapporten te verzenden (er wordt niets geblokkeerd). Deze richtlijn is in CSP Level 3 afgeschaft ten gunste van de report-to richtlijn.
VOORBEELD REPORT-URI
report-uri /some-report-uri

child-src

Definieert geldige bronnen voor webworkers en geneste browsingcontexten die geladen worden met elementen zoals <frame> en <iframe>
VOORBEELD CHILD-SRC POLICY
child-src 'self'

form-action

Definieert geldige bronnen die gebruikt kunnen worden als een HTML <form> actie.
VOORBEELD FORM-ACTION POLICY
form-action 'self'

frame-ancestors

Definieert geldige bronnen voor het insluiten van de bron met <frame> <iframe> <object> <embed> <applet>. Deze richtlijn instellen op 'none' zou ongeveer gelijk moeten zijn aan X-Frame-Options: DENY. Wanneer deze richtlijn actief is, en als de browser het ondersteunt, zal het de instellingen in X-frame-options overschrijven.
VOORBEELD FRAME-ANCESTORS POLICY
frame-ancestors 'none'

plugin-types

Definieert geldige MIME-typen voor plugins die worden aangeroepen via <object> en <embed>. Om een <applet> te laden moet u application/x-java-applet opgeven.
VOORBEELD PLUGIN-TYPES POLICY
plugin-types application/pdf

base-uri

Definieert een set toegestane URL's die gebruikt kunnen worden in het src attribuut van een HTML base tag.
VOORBEELD BASE-URI POLICY
base-uri 'self'

report-to

Definieert een rapportagegroepnaam gedefinieerd door een Report-To HTTP response header. Zie de Reporting API voor meer informatie.
VOORBEELD REPORT-TO RICHTLIJN
report-to groupName

worker-src

Beperkt de URL's die geladen mogen worden als een Worker, Shared Worker of Service Worker.
VOORBEELD WORKER-SRC POLICY
worker-src 'none'

manifest-src

Beperkt de URL's waarvan applicatiemanifesten geladen kunnen worden.
VOORBEELD MANIFEST-SRC POLICY
manifest-src 'none'

prefetch-src

Definieert geldige bronnen voor het vooraf ophalen en vooraf renderen van verzoeken, bijvoorbeeld via de link tag met rel="prefetch" of rel="prerender":
VOORBEELD PREFETCH-SRC POLICY
prefetch-src 'none'

navigate-to

Beperkt de URL's waar het document op welke manier dan ook naartoe mag navigeren. Bijvoorbeeld, wanneer er op een link geklikt wordt, een formulier verzonden wordt, of window.location aangeroepen wordt. Als form-action aanwezig is, wordt deze richtlijn genegeerd bij het verzenden van formulieren. Implementatiestatus
VOORBEELD NAVIGATE-TO POLICY
navigate-to https://example.com

Joomla’s HTTP Headers plugin geeft u ook de mogelijkheid om enkele algemene parameters in te stellen in het Content Security Policy tabblad.

U kunt ervoor kiezen om de CSP toe te passen op uw website, de beheerder website, of beide met de instelling Adverteerder.

Met de optie ‘Alleen rapport’ kunt u uw richtlijnen testen en controleren op fouten met Dev Tools voordat u live gaat. Het is altijd leuk om de reden voor CSP-fouten in Google's console op te sporen!

Vervolgens is er de instelling ‘Nonce’. Nonce, wat 'eenmalig gebruikt nummer' betekent, is een systeem dat een willekeurig gegenereerde reeks toepast op een inline <script> of <style> tag die via de Joomla API in uw HTML is opgenomen. Deze gevallen worden meestal geïmplementeerd door externe Joomla component-/module-/plugin-ontwikkelaars wanneer u die extra functionaliteit op uw website installeert.

In de onderstaande afbeelding kunt u de <style> tag zien met een nonce rel attribuut dat is toegevoegd aan de CSS <styles> die door de Akeeba Backup component aan mijn HTML-document zijn toegevoegd.

Interessant genoeg bevat de kern-JavaScript- en CSS-code van Joomla die aan het HTML-document wordt toegevoegd momenteel geen ‘nonce’ tag. Dit komt doordat ze onderdeel zijn van de ‘kern’ in plaats van te worden toegevoegd via de Joomla API.

Als u de ‘Nonce’ schakelaar in de CSP-instellingen inschakelt, zorgt u ervoor dat die inline scripts en stijlen door de browser als ‘veilig’ worden weergegeven. U moet ook de Joomla {nonce} tag instellen in uw script-src policy directive als script-src 'self' {nonce}. Als terugvaloptie voor oudere browsers die geen 'nonces' ondersteunen, kunt u ook {script-hashes} toevoegen na de {nonce} placeholder, zoals dit script-src 'self' {nonce} {script-hashes} (let op de spaties). Maar vergeet niet eerst Script Hashes in te schakelen.

Joomla genereert willekeurig de ‘nonce’ tekstreeks en voegt deze toe aan de <style> en <script> tags. Wanneer u de ‘nonce’ optie in de plugin-instellingen inschakelt, wordt de tekstreeks doorgegeven aan de HTTP Header. De browser interpreteert vervolgens de HTTP Header en verwerkt het bijbehorende <script> of <style>. Tegelijkertijd verwijdert het de Nonce tekstreeks uit de weergegeven HTML in de browser.

Dit voorkomt op zijn beurt dat meneer Hacker de nonce tekstreeks kan kapen en aan zijn eigen geïnjecteerde code kan toevoegen. Zelfs als meneer Hacker erin slaagt zijn kwaadaardige JavaScript in uw HTML te injecteren, zal de browser het blokkeren.

Script Hashes

We weten allemaal dat we geen inline JavaScript in onze HTML zouden moeten opnemen, u zou het moeten schrijven in een my-javascript.js bestand en toevoegen aan de <head> of net voor de </body> tag plaatsen. Maar we maken ons er allemaal wel eens schuldig aan.

Het probleem is dat als u dit doet en vervolgens de CSP directive ‘script-src 'self'’ toevoegt, alle inline JavaScript standaard wordt geblokkeerd. Het is zo ontworpen om te voorkomen dat meneer Hackers geïnjecteerde JavaScript op uw website kan draaien.

Er is een override hiervoor met de directive script-src 'unsafe-inline', die het mogelijk maakt dat meneer Hackers inline JavaScript draait, naast uw betrouwbare code. Dit is om voor de hand liggende redenen niet de beste optie.

Script Hashes tot de redding!

Joomla's HTTP Headers plugin verzamelt automatisch alle <styles> en <scripts> die via de Joomla API naar de website worden doorgegeven. Vervolgens genereert het de bijbehorende hashes en geeft deze door via de HTTP Header. De browser genereert vervolgens de hashes op de website zelf en bevestigt dat de hashes overeenkomen. Als dat zo is, worden de scripts uitgevoerd, anders worden ze geblokkeerd.

Om deze pluginfunctie in te schakelen, zet u de schakelaar op 'Ingeschakeld'. Voeg vervolgens in uw script-src policy directive de waarde 'self' {script-hashes} toe. Als u de 'nonce' functie gebruikt, naast 'script hashes', stel dan de directive waarde in zoals in het nonce voorbeeld hierboven.

Dat is nog eens slim.

Maar wat nog beter is, is dat we hetzelfde idee kunnen gebruiken om scripthashes handmatig te verwerken en ze toe te voegen aan onze directive script-src 'self'. Het kost wat moeite om in te stellen en te onderhouden, maar het kan u redden als u JavaScript hebt toegevoegd aan een artikel of een aangepaste module.

Er zijn meer gedetailleerde manieren om dit te doen met een sha256-, sha384- of sha512-hashgenerator. Maar aangezien de meeste mensen slechts kleine stukjes JavaScript aan hun artikel of aangepaste module toevoegen, laten we Google's Dev Tools het werk voor ons doen.

Het proces is eenvoudig. Het enige verschil is hoe we de hash genereren.

Ervan uitgaande dat u de Joomla HTTP Headers plugin hebt ingeschakeld, CSP actief is en u de directive script-src 'self' hebt ingesteld en opgeslagen.

Stap 1 - Voeg uw inline JavaScript toe aan uw artikel of aangepaste module en sla het op. Vergeet niet uw tekstverwerkerinstellingen aan te passen zodat de tekstverwerker uw code niet verwijdert bij het opslaan.

Stap 2 - Navigeer naar uw webpagina met uw script erin. Open Dev Tools en in het tabblad console ziet u een fout die lijkt op:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='), or a nonce ('nonce-...') is required to enable inline execution.

Stap 3 - Nu hoeft u alleen de hash uit het foutbericht te kopiëren/plakken in uw JavaScript directive in de plugin en het opnieuw op te slaan:

script-src 'self' 'sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='

Herlaad vervolgens uw webpagina en controleer opnieuw in Google's Dev Tools. De fout zal nu verdwenen zijn en de browser zal uw script op de webpagina laden.

Notitie: Er wordt in mijn voorbeeld nog steeds een fout getoond omdat de JavaScript die aan mijn artikel is toegevoegd niet compleet is. Maar het toont wel dat de inline code in ieder geval probeert te werken.

Het toevoegen van hashes aan uw inline code is een goede manier om ze op de witte lijst te zetten in de HTTP header zodat ze toch uitgevoerd worden, terwijl elke inline code die niet expliciet gehasht en toegevoegd is aan uw CSP nog steeds geblokkeerd zal worden. Zo wordt de poging van de hacker om uw website te compromitteren verijdeld.

Notitie:

Als u uw JavaScript wijzigt, moet u uw hash opnieuw berekenen en de waarde in de CSP directive wijzigen.

Als u problemen ondervindt om uw hashes te laten werken, zijn er 3 veelvoorkomende problemen, u kunt oplossingen vinden op de webpagina Using a hash with CSP.

Strict Dynamic

Als u de optie Strict Dynamic inschakelt in uw CSP, neemt dit de expliciete autoriteit die u via een Hash of Nonce aan een script hebt gegeven en past deze toe op elk ander script dat er direct aan gekoppeld is of ervanuit aangeroepen wordt. Deze actie overschrijft ook standaard directives zoals 'self' of 'unsafe-inline' die toegepast zijn in uw algemene CSP directives op die childscripts. Ze zullen genegeerd worden.

Style Hashes

De Style Hash van de CSP werkt op precies dezelfde manier als de JavaScript hashes hierboven, maar gebruik dit als u CSS <style> blokken toevoegt aan uw HTML body. Net zoals bij 'Script Hashes', schakel de plugin functie in en stel een style-src Policy Directive in om ernaar te verwijzen met de waarde 'self' {style-hashes}.

Notitie:

Als u uw inline CSS wijzigt, in plaats van CSS die door de Joomla API wordt gemaakt, moet u uw hash opnieuw berekenen en de waarde in de CSP-richtlijn wijzigen.

Frame Ancestors ‘self’

Met deze optie in de plugin kan een pagina geframed worden, bijvoorbeeld binnen een iframe, maar alleen vanaf dezelfde website.

Als u expliciet een andere website wilt toestaan om uw inhoud te framen, kunt u een specifieke richtlijn ‘frame-src’ instellen.

Laatste opmerking / Conclusie:

Bij het schrijven van dit artikel realiseerde ik me dat ik slechts het oppervlak van dit enorme onderwerp heb aangeraakt.

Ik vind het heerlijk om onderwerpen te ontdekken die ik voorheen heb genegeerd, of waar ik niets vanaf wist. Heeft u dat ook?

De conclusie waar ik toe ben gekomen bij het onderzoeken van het onderwerp HTTP Headers, en in het bijzonder het gebruik van Joomla’s nieuwe J4 plugin om deze in te stellen, is dat we dit onderwerp allemaal moeten beheersen. Er zijn veel te veel mensen (hackers) die alleen maar wachten op een kans om misbruik te maken van websites met een zwakke beveiliging. Help uw gebruikers dus niet om slachtoffer te worden.

Veel plezier met het onderzoeken van de Joomla HTTP headers plugin en leer hoe deze uw website kan helpen beveiligen.

Ik raad u wel aan om eerst wat meer onderzoek te doen naar dit interessante onderwerp voordat u begint. Hieronder vindt u links om uw eigen onderzoek op gang te brengen. U krijgt een veel beter begrip van hoe het internet werkt en hoe uw website ermee samenwerkt.

Ter referentie

Als u de plugin moet resetten: de HTTP Headers plugin werd geïnstalleerd met de volgende instellingen ingesteld:

De plugin is standaard Ingeschakeld.

• De HSTS- en CSP-tabbladen zijn standaard Uitgeschakeld.
• De X-Frame-Options zijn standaard Ingeschakeld.
• De Referrer-Policy wordt aanvankelijk ingesteld op: strict-origin-when-cross-origin.
• De Cross-Origin-Opener-Policy wordt aanvankelijk ingesteld op same-origin.

Als u dit zo ver heeft gelezen en dacht “Dat is niet eerlijk, hoe zit het met J3?”, “Waarom kunnen we dezelfde functies niet hebben in Joomla 3?”. Welnu, het goede nieuws is dat dit wel kan. Al moet u de plugin wel downloaden van de JED.

Wanneer u uw HTTP headers heeft ingesteld met de Joomla 4 plugin, kunt u uw HTTP Headers testen op de Security Headers website.

Hoe heeft u gescoord?

Houd er rekening mee dat activering van de HTTP Headers plugin onverwachte acties kan veroorzaken aan de voorkant.

Tot slot wil ik Tobias Zulauf & Ced Keiflin bedanken voor hun bijdrage om dit artikel op tijd af te krijgen!