Lezers zoals jij steunen MUO. Wanneer u een aankoop doet via links op onze site, kunnen we een aangesloten commissie verdienen.
Wanneer u een website wilt bezoeken, ontvangt de internetbrowser die u gebruikt enkele gegevens van die site. Hierdoor ontstaat er een dialoog tussen uw apparaat en de website. Dit gebeurt met het protocol genaamd HTTP. Het is mogelijk om enkele aanvullende beveiligingsmaatregelen te nemen door in te grijpen in deze dialoog.
Als u een website beheert of een carrière als webontwikkelaar nastreeft, zijn HTTP-beveiligingsheaders van onschatbare waarde voor u, omdat ze een actieve rol spelen in de beveiliging van zowel de gebruiker als de website.
Wat is HTTP Strict-Transport-Security (HSTS)?
HTTP Strict Transport Security (HSTS) dwingt gebruikers om HTTPS te gebruiken voor elk verzoek dat ze in hun browser doen. Dit is een solide manier om cyberaanvallen zoals downgrades te bestrijden en om de veiligheid van al het verkeer te waarborgen.
Het activeren van HSTS is vrij eenvoudig. Denk aan de dialoog tussen de client en de server. Wanneer u probeert toegang te krijgen tot een site via uw browser, bent u de klant. Welke site u wilt openen, is afhankelijk van de server. Uw doel is om de server te vertellen: "Ik wil deze site openen". Dit is een verzoekbewerking. De server daarentegen leidt u naar de site als u aan de gewenste voorwaarden voldoet.
Houd hier rekening mee met betrekking tot dit voorbeeld van een HTTP-headervlag:
Strikte transportbeveiliging: max-leeftijd=16070200;
Wanneer u deze vlag toevoegt aan de koptekstinformatie van het HTTP-antwoord, worden alle door de gebruiker gegenereerde verzoeken HTTPS. Wat de gebruiker hier ook schrijft, de browser zal het protocol automatisch evalueren als HTTPS en een veilige verbinding tot stand brengen.
HSTS gebruiken
In plaats van al deze HTTP-headerinformatie in de codelaag toe te voegen, kunt u dit doen op Apache, IIS, Nginx, Tomcat en andere webservertoepassingen.
Om HSTS in Apache in te schakelen:
LoadModule headers_module modules/mod_headers.so
<VirtueleHost *:443>
Kop altijd setStreng-Vervoer-Beveiliging "max-leeftijd=2592000; includeSubDomains"
</VirtualHost>
Om HSTS in Nginx in te schakelen:
add_header Strict-Transport-Security max-age=2592000; includeSubdomeinen
HSTS inschakelen met IIS web.config:
<systeem.webServer>
<httpProtocol>
<customHeaders>
<naam toevoegen="Strenge transportbeveiliging" waarde="max-leeftijd=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Voor Cloudflare-gebruikers
Cloudflare biedt gratis HTTPS-service voor iedereen met zijn Keyless SSL-service; voordat u HSTS preload aanvraagt, moet u weten dat uw certificaat niet van u is. Veel sites maken gebruik van SSL-certificaten omdat ze een eenvoudige manier zijn om gegevens veilig te houden.
Echter, Cloudflare nu ondersteunt de HSTS-functie. Je kunt alle HSTS-functies activeren, inclusief preload, via de Cloudflare-webinterface zonder te worstelen met de configuraties op de webserver.
Wat zijn X-Frame-opties?
X-Frame-Options is een beveiligingsheader die door alle moderne browsers wordt ondersteund. X-Frame-Options heeft als doel bescherming te bieden tegen klikdiefstal zoals Clickjacking. Zoals de naam al doet vermoeden, gaat het om de werking van een kwetsbaar inline frame, ook wel iframe genoemd. Dit zijn elementen op een site die een andere HTML-pagina insluiten in de "bovenliggende" site, zodat u inhoud van andere bronnen op uw site kunt gebruiken. Maar aanvallers gebruiken iframes onder hun eigen controle om gebruikers acties te laten uitvoeren die ze niet willen.
Om deze reden moet u voorkomen dat aanvallers iframes op de site kunnen vinden.
Waar en hoe X-Frame-opties te gebruiken?
Wat X-Frame-Options doet, proberen sommige ontwikkelaars te doen met talen als JavaScript. Dit is niet helemaal verkeerd. Er is echter nog steeds een risico omdat de codes die in veel aspecten zijn geschreven niet voldoende zijn. Het is dus verstandig om deze taak over te laten aan de internetbrowser die u gebruikt.
Als ontwikkelaar zijn er echter drie parameters die u moet weten over X-Frame-opties:
- Ontkennen: Volledig voorkomen dat de pagina wordt aangeroepen in een iframe.
- ZELFDE OORSPRONG: Voorkom dat een ander domein dan uw eigen domein binnen het iframe belt.
- TOESTAAN-VAN uri: accepteer iframe-oproepen van URI die als parameter zijn opgegeven. Blokkeer anderen.
Hier de ZELFDE OORSPRONG kenmerk valt meer op. Want hoewel u applicaties in uw verschillende subdomeinen kunt aanroepen met iframes in elkaar, kunt u voorkomen dat ze worden aangeroepen via het domein dat onder controle van de aanvaller staat.
Hier zijn voorbeelden van hoe u SAMEORIGIN en X-Frame-Options kunt gebruiken met NGINX, Apache en IIS:
X-Frame-opties SAMEORIGIN gebruiken voor Nginx:
add_header X-Frame-Opties SAMEORIGIN;
X-Frame-Options SAMEORIGIN gebruiken voor Apache:
Header voeg altijd X-Frame-Options SAMEORIGIN toe
X-Frame-opties SAMEORIGIN voor IIS gebruiken:
<httpProtocol>
<customHeaders>
<naam toevoegen="X-Frame-opties" waarde="ZELFDE OORSPRONG" />
</customHeaders>
</httpProtocol>
Door alleen de SAMEORIGIN-header toe te voegen, krijgt u meer veiligheid voor uw bezoekers.
Wat is X-XSS-beveiliging?
Het gebruik van X-XSS-Protection-headerinformatie kan gebruikers beschermen tegen XSS-aanvallen. Ten eerste moet je elimineren XSS-kwetsbaarheden aan de applicatiekant. Na het bieden van op code gebaseerde beveiliging zijn verdere maatregelen, d.w.z. X-XSS-Protection-headers, vereist tegen XSS-kwetsbaarheden in browsers.
Hoe X-XSS-bescherming te gebruiken
Moderne browsers kunnen potentiële XSS-payloads detecteren door door applicaties gegenereerde inhoud te filteren. Het is mogelijk om deze functie te activeren met de X-XSS-Protection header-informatie.
Om de X-XSS-Protection-header in Nginx in te schakelen:
add_header X-Frame-X-XSS-bescherming 1;
Om de X-XSS-Protection-header in Apache in te schakelen:
Header voeg altijd X-XSS-Protection 1 toe
Om de X-XSS-Protection-header in IIS in te schakelen:
<httpProtocol>
<customHeaders>
<naam toevoegen="X-XSS-bescherming" waarde="1" />
</customHeaders>
</httpProtocol>
Om te voorkomen dat het codeblok met standaard XSS-aanval wordt uitgevoerd, kunt u zoiets als dit gebruiken:
X-XSS-bescherming: 1; modus=blok
Deze kleine wijziging moet worden aangebracht als er een mogelijk gevaarlijke situatie is en u wilt voorkomen dat alle inhoud wordt weergegeven.
Wat is X-Content-Type-Options?
Browsers voeren een analyse uit die MIME Type Sniffing wordt genoemd op inhoud die door de webtoepassing aan hen wordt gepresenteerd. Als er bijvoorbeeld een verzoek om toegang tot een PDF-bestand of PNG-bestand wordt gedaan, leiden browsers die een analyse van het HTTP-antwoord uitvoeren het bestandstype af.
Overweeg een bestand met een jpeg-extensie maar dat eigenlijk tekst-/HTML-inhoud bevat. Na het gebruik van de extensies en het passeren van beveiligingen in de uploadmodule, is het bestand succesvol geüpload. Het geüploade bestand wordt aangeroepen via de URL en MIME Type sniffing retourneert Text/HTML als resultaat. Het geeft de inhoud weer als HTML. Dat is wanneer de XSS-kwetsbaarheid optreedt.
U moet dus voorkomen dat browsers beslissen over inhoud door middel van MIME Type sniffing. Om dit te doen, kunt u nosniff gebruiken.
X-Content-Type-Options-header voor Nginx:
add_header X-Content-Type-Opties nosniff;
X-Content-Type-Options-header voor Apache:
Header altijd X-Content-Type-Opties nosniff
X-Content-Type-Options-header voor IIS:
<httpProtocol>
<customHeaders>
<naam toevoegen="X-Content-Type-Opties" waarde="snuif" />
</customHeaders>
</httpProtocol>
Wat is de HttpOnly-cookievlag?
Webapplicaties volgen de sessies van gebruikers via sessie-ID. Browsers slaan dit op en voegen het automatisch toe aan elk HTTP-verzoek binnen het bereik van de cookie.
Het is mogelijk om cookies voor doeleinden te gebruiken behalve de overdracht van de sessiesleutel. Hackers zouden gebruikersgegevens kunnen achterhalen met behulp van de eerder genoemde XSS-kwetsbaarheid of via een Cross-Site Request Forgery (CSRF)-aanval. Dus welke cookies zijn het belangrijkst op het gebied van veiligheid?
U kunt de informatie in de laatste afbeelding waarop u in de afbeeldingengalerij heeft geklikt als voorbeeld beschouwen. Op deze manier is er minder HTTP-verkeer en kan een deel van de belasting worden opgelost door de internetbrowser van de gebruiker met client-side scripting.
Dat is waar HttpAlleen komt binnen. Hieronder ziet u een voorbeeld van hoe de cookietoewijzing zou moeten zijn:
Set-Koekje: gebruiker=t=cdabe8a1c2153d726; pad=/; HttpAlleen
Let op de HttpOnly-waarde die is verzonden in de Set-cookie operatie. De browser ziet dit en verwerkt geen waarden met de HttpOnly-vlag wanneer de cookie wordt geopend via de document.cookie variabel. Een andere vlag die wordt gebruikt in het Set-Cookie-proces is de Secure-vlag. Dit geeft aan dat de cookiewaarde alleen voor HTTPS-verzoeken aan de header wordt toegevoegd. E-commercesites gebruiken het meestal omdat ze het netwerkverkeer willen verminderen en de prestaties willen verbeteren.
Met deze methode kunt u de kritieke gegevens van gebruikers, zoals gebruikersnamen, wachtwoorden en creditcardgegevens, verbergen. Maar er is een probleem. Gebruikers die het inlogproces voltooien, krijgen een cookiewaarde toegewezen zonder de Secure-vlag. De gebruiker kan de sessiesleutel hebben wanneer hij een HTTP-verzoek doet voor niet-HTTPS-links. Het toevoegen van de beveiligde vlag is eenvoudig:
Set-Koekje: gebruiker=t=cdabe8a1c2153d726; pad=/; Zeker
Wanneer mag je HttpOnly niet gebruiken? Als u op Javascript vertrouwt, moet u op uw hoede zijn, omdat dit uw site in plaats daarvan minder veilig kan maken.
Kleine stappen werken voor bredere webbeveiliging
U heeft geen geavanceerde software- en serverkennis nodig om de beveiliging van webapplicaties te verhogen. Door slechts een paar regels te wijzigen, kunt u ernstige aanvallen voorkomen. Dit is natuurlijk niet genoeg. Het is echter een kleine maar effectieve stap voor websitebeveiliging. Kennis is de beste preventieve maatregel, dus het is ook handig om de subtiele nuances te kennen van hoe HTTPS gegevens beschermt tijdens de overdracht.