Dankzij partijen als Google Chrome, die vanaf eind juli in de nieuwste versie van hun browser standaard HTTP-websites als onveilig bestempelt, is het omzetten naar HTTPS belangrijker dan ooit. In ons eerdere artikel in deze serie was al te lezen hoe u uw configuratie zo kunt aanpassen dat uw website altijd over HTTPS bereikt wordt door uw bezoekers. Maar het is ook verstandig om verder te kijken dan dat. Hoe staat het met uw content?

Mixed content

Uw configuratie is helemaal tot in de puntjes correct en verzorgd, en uw website verbindt netjes via HTTPS met de server. Maar toch zou het kunnen dat uw website niet 100% HTTPS-conform is. Het embedden van content van een externe locatie is vaak de oorzaak: de content wordt zo overgenomen en loopt alsnog over een HTTP-verbinding. Wanneer u zeker wilt weten dat er niet stiekem ergens een HTTP-verbinding wordt gemaakt met een externe bron, zou u uw code door moeten kijken om te controleren of er geen linkjes instaan naar externe locaties die nog aangeroepen worden met een HTTP-link, en ze handmatig veranderen. Voor een kleine website is dit wellicht nog te overzien, maar wanneer een website al een tijdje bestaat, en veel legacy code bevat, zou het zomaar kunnen dat dit een klus van jewelste is. Gelukkig staat u er niet alleen voor.

HTTP headers: Content-security-policy

De meeste webpagina’s maken gebruik van HTTP headers, die meegegeven worden aan de server of browser, en bepaalde eigenschappen, kenmerken of opdrachten afgeven voor de opgevraagde pagina. Een HTTP header kan voor heel veel dingen worden gebruikt: zo kan een HTTP header gebruikt worden om cookies vast te leggen of sessies aan te maken voor gebruikers, hoe lang een sessie in leven gehouden mag worden voordat er een relog gedaan moet worden, maar ook om bepaalde waarden af te dwingen. Maar headers kunnen ook regels bevatten die uw content beveiligt en reguleert. Dit zijn Content Security Policy headers.

Een HTTP header kan op verschillende manieren worden meegegeven. Zo bespraken we in het vorige artikel al de HSTS header, die in het configuratiebestand werd geplaatst. Een header kan ook worden opgenomen in een htaccess-bestand, of direct in uw code worden geplaatst. Als laatste redmiddel zou er ook als alternatief een meta-tag aan uw HTML kunnen worden toegevoegd. Dit heeft echter niet de voorkeur, omdat het alleen wordt aangeroepen wanneer iemand daadwerkelijk uw website bezoekt. Wanneer iemand bijvoorbeeld direct naar een afbeelding linkt die op uw website staat en daar een HTTP-link voor gebruikt, zal deze niet worden aangepast naar een HTTPS-link.

Onderstaande adviezen zijn van toepassing op servers die geheel of gedeeltelijk in eigen beheer zijn, waarbij de website-eigenaar aanpassingen kan en mag maken aan configuratiebestanden. Zoals eerder aangegeven is het altijd verstandig om een slag om de arm te houden en niet klakkeloos content te kopiëren naar uw eigen configuratie. Sla de handleiding van uw serversoftware er op na om er zeker van te zijn dat de aanpassingen werken voor uw omgeving.

Upgrade-insecure-requests in de configuratie

Met de content security policy header ‘upgrade-insecure-requests’ kunt u afdwingen dat alle HTTP requests worden behandeld alsof het een HTTPS request was. Zo voorkomt u dat uw website als onveilig wordt gezien, terwijl u toch echt een certificaat en een goede configuratie hebt ingesteld.

Deze content header kunt u toevoegen aan uw (Apache) configuratiebestand met de volgende regel:

Content-Security-Policy: upgrade-insecure-requests;

U kunt deze regel code ook toevoegen aan een .htaccess-bestand, wanneer u liever geen aanpassingen maakt aan uw configuratiebestand of daar niet de mogelijkheid toe hebt. In dat geval voegt u de volgende regel toe aan uw .htaccess-bestand:

Header always set Content-Security-Policy “upgrade-insecure-requests;”

Hoewel de meningen onder security experts kunnen verschillen, is het aan te raden om bij twijfel te gaan voor een aanpassing aan het .htaccess-bestand. Aanpassingen die direct in de config worden gedaan zullen namelijk niet actief worden zonder eerst de server te moeten herstarten, wat andere mogelijke gevolgen met zich mee kan brengen. Ook wordt deze CSP header niet door alle browsers meer ondersteund.

Upgrade-insecure-requests in de code

Een alternatief voor het aanpassen van uw configuratie is het toevoegen van headers in de code van uw website. Het toevoegen hiervan hangt echter volledig af van de taal waarin uw website is geprogrammeerd. Zo bevat PHP het header()-commando, waarin u een header kunt definiëren en dus de upgrade-insecure-requests-header mee kunt geven. Andere programmeertalen gebruiken vergelijkbare functies om headers mee te kunnen geven. Zelfs wanneer u geen toegang hebt tot de code van uw website maar, bijvoorbeeld, alleen aanpassingen kunt maken in de HTML van een template, is er nog een mogelijkheid om een content header mee te geven: gebruik in dat geval deze meta-tag:

<meta http-equiv=”Content-Security-Policy” content=”upgrade-insecure-requests”>

Niet aan te raden

Maar let op: het toevoegen van header-commando’s in uw code luistert nauw. Zo is het erg belangrijk dat u oplet waar het commando wordt aangeroepen. De meeste programmeertalen kunnen er niet tegen wanneer een header wordt aangeroepen terwijl er al andere server requests zijn uitgevoerd. Alleen wanneer het header-commando het allereerste is wat de server voor zijn kiezen krijgt, zal het naar behoren werken. Daarnaast is het alleen van toepassing wanneer uw website daadwerkelijk wordt aangeroepen. Wanneer iemand linkt naar een plaatje op uw website en de HTTP-link hiervoor gebruikt, wordt het script niet daadwerkelijk aangeroepen en zal er dus nooit een header-commando worden geactiveerd.

Report-uri en report-to

Maar alleen insecure requests upgraden doet natuurlijk niks voor uw content. U zult nog steeds zelf uw code af moeten struinen naar alle onbeveiligde content en die aan moeten passen. De security policies report-uri en report-to kunnen hier gelukkig een handje bij helpen. De report-uri policy stuurt een bericht naar een URI wanneer er een pagina wordt aangeroepen waarop onveilige content staat, en voegt hier de locatie en foutmelding aan toe. Deze waarschuwingen kunt u vervolgens uitlezen en gebruiken om de gevonden fouten op te lossen.

Helaas is de report-uri functie inmiddels wel deprecated en wordt hij binnenkort uitgefaseerd. De functie report-to zal hem gaan vervangen. Deze functie is iets uitgebreider en staat bijvoorbeeld ook toe dat u een functie aanroept waarin u kunt opsplitsen wat voor melding er wordt gegeven in verschillende situaties. Dit betekent dat er maar één keer een report-to functie hoeft te worden gedeclareerd, die meerdere situaties kan afvangen.

Conclusie

Zoals al eerder gezegd is het belangrijk dat u uw eigen situatie in ogenschouw neemt, wanneer u aan de slag gaat met content security headers en uw server configuraties. Ook wanneer u buiten uw configuratie om wilt werken en headers wilt setten via uw code, zult u altijd uw eigen situatie in acht moeten nemen en niet blind gegevens overnemen van externe bronnen.

Wanneer u wel uw headers wilt aanpassen, zijn er tools beschikbaar die mee kunnen kijken en controleren of u ze goed hebt ingesteld. Een goed voorbeeld hiervan is https://securityheaders.com/ (voormalig https://securityheaders.io ). Deze analysetool van de hand van Scott Helme bekijkt de settings van uw server en geeft handige informatie over eventueel fout ingestelde headers.

Volgende keer bekijken we mogelijkheden om uw SSL certificaat in te zetten voor betere website prestaties.

Lees relevante artikelen

Categorie  SSL & Security | Tags  https Security ssl