Læsere som dig hjælper med at støtte MUO. Når du foretager et køb ved hjælp af links på vores websted, kan vi optjene en affiliate-kommission.
Når du vil besøge et websted, modtager den internetbrowser, du bruger, nogle data fra det pågældende websted. Som et resultat opstår der en dialog mellem din enhed og webstedet. Dette sker med protokollen kaldet HTTP. Det er muligt at tage nogle yderligere sikkerhedsforanstaltninger ved at gribe ind i denne dialog.
Hvis du driver en hjemmeside eller sigter efter en karriere som webudvikler, er HTTP-sikkerhedsheadere uvurderlige for dig, fordi de spiller en aktiv rolle i sikkerheden for både brugeren og hjemmesiden.
Hvad er HTTP Strict-Transport-Security (HSTS)?
HTTP Strict Transport Security (HSTS) tvinger brugerne til at bruge HTTPS for hver anmodning, de foretager i deres browser. Dette er en solid måde at bekæmpe cyberangreb som nedgraderinger og til at sikre sikkerheden for al trafik.
Det er ret nemt at aktivere HSTS. Overvej dialogen mellem klienten og serveren. Når du forsøger at få adgang til et websted via din browser, er du klienten. Det websted, du vil åbne, afhænger af serveren. Dit mål er at fortælle serveren, "Jeg vil åbne denne side". Dette er en anmodningsoperation. Serveren derimod dirigerer dig til siden, hvis du opfylder de ønskede betingelser.
Husk dette med hensyn til dette eksempel på HTTP-header-flag:
Strict-Transport-Security: max-age=16070200;
Når du føjer dette flag til headeroplysningerne for HTTP-svaret, bliver alle brugergenererede anmodninger til HTTPS. Uanset hvad brugeren skriver her, vil browseren automatisk evaluere protokollen som HTTPS og etablere en sikker forbindelse.
Sådan bruges HSTS
I stedet for at tilføje al denne HTTP-headerinformation i kodelaget, kan du gøre det på Apache, IIS, Nginx, Tomcat og andre webserverapplikationer.
Sådan aktiverer du HSTS i Apache:
LoadModule headers_module modules/mod_headers.so
<VirtualHost *: 443>
Header altid sætStreng-Transportere-Sikkerhed "maks-alder=2592000; includeSubDomains"
</VirtualHost>
For at aktivere HSTS i Nginx:
add_header Strict-Transport-Security max-age=2592000; omfatter underdomæner
Sådan aktiverer du HSTS med IIS web.config:
<system.webServer>
<httpProtokol>
<customHeaders>
<tilføje navn ="Streng-Transport-Sikkerhed" værdi="max-alder=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Til Cloudflare-brugere
Cloudflare leverer gratis HTTPS-tjeneste til alle med sin Keyless SSL-tjeneste; før du ansøger om HSTS preload, skal du vide, at dit certifikat ikke tilhører dig. Mange websteder bruger SSL-certifikater fordi de er en enkel måde at holde data sikre på.
Dog Cloudflare nu understøtter HSTS-funktionen. Du kan aktivere alle HSTS-funktioner, inklusive preload, via Cloudflare-webgrænsefladen uden at skulle kæmpe med konfigurationerne på webserveren.
Hvad er X-Frame-Options?
X-Frame-Options er en sikkerhedsheader, der understøttes af alle moderne browsere. X-Frame-Options har til formål at beskytte mod kliktyveri såsom Clickjacking. Som navnet antyder, handler det om arbejdet med en sårbar inline-ramme, også kendt som en iframe. Disse er elementer på et websted, der indlejrer en anden HTML-side på det "overordnede" websted, så du kan bruge indhold fra andre kilder på dit websted. Men angribere bruger iframes under deres egen kontrol for at få brugere til at udføre handlinger, de ikke vil.
Af denne grund skal du forhindre angribere i at kunne finde iframes på webstedet.
Hvor og hvordan bruger man X-Frame-Options?
Hvad X-Frame-Options gør, prøver nogle udviklere at gøre med sprog som JavaScript. Dette er ikke helt forkert. Der er dog stadig en risiko, fordi de koder, der er skrevet i mange aspekter, ikke er nok. Så det ville være klogt at overlade denne opgave til den internetbrowser, du bruger.
Men som udvikler er der tre parametre at vide om X-Frame-Options:
- Nægte: Forhindr fuldstændigt, at siden bliver kaldt i enhver iframe.
- SAMEORIGIN: Undgå andre domæner end dit eget i at ringe inden for iframen.
- TILLAD-FRA uri: Accepter iframe-kald af URI givet som parameter. Bloker andre.
Her, den SAMEORIGIN funktion skiller sig mere ud. For mens du kan kalde applikationer i dine forskellige underdomæner med iframes inden i hinanden, kan du forhindre dem i at blive kaldt over domænet under angriberens kontrol.
Her er eksempler på, hvordan du kan bruge SAMEORIGIN og X-Frame-Options med NGINX, Apache og IIS:
Brug af X-Frame-Options SAMEORIGIN til Nginx:
add_header X-Frame-Options SAMEORIGIN;
Brug af X-Frame-Options SAMEORIGIN til Apache:
Overskrift tilføj altid X-Frame-Options SAMEORIGIN
Brug af X-Frame-Options SAMEORIGIN til IIS:
<httpProtokol>
<customHeaders>
<tilføje navn ="X-Frame-indstillinger" værdi="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
Blot at tilføje SAMEORIGIN-headeren alene vil give større sikkerhed for dine besøgende.
Hvad er X-XSS-beskyttelse?
Brug af X-XSS-Protection headeroplysninger kan beskytte brugere mod XSS-angreb. For det første skal du eliminere XSS sårbarheder på ansøgningssiden. Efter at have leveret kodebaseret sikkerhed kræves yderligere foranstaltninger, dvs. X-XSS-Protection headers, mod XSS-sårbarheder i browsere.
Sådan bruges X-XSS-Protection
Moderne browsere kan registrere potentielle XSS-nyttelaster ved at filtrere applikationsgenereret indhold. Det er muligt at aktivere denne funktion med X-XSS-Protection header-information.
Sådan aktiverer du X-XSS-Protection-headeren i Nginx:
add_header X-Frame-X-XSS-Beskyttelse 1;
Sådan aktiverer du X-XSS-Protection-headeren i Apache:
Header tilføj altid X-XSS-Protection 1
Sådan aktiverer du X-XSS-Protection-headeren i IIS:
<httpProtokol>
<customHeaders>
<tilføje navn ="X-XSS-beskyttelse" værdi="1" />
</customHeaders>
</httpProtocol>
For at forhindre kodeblokken med XSS-angreb som standard i at køre, kan du bruge noget som dette:
X-XSS-beskyttelse: 1; mode=blok
Denne mindre ændring skal foretages, hvis der er en potentielt farlig situation, og du vil forhindre alt indhold i at blive gengivet.
Hvad er X-Content-Type-Options?
Browsere udfører en analyse kaldet MIME Type Sniffing på indhold, der præsenteres for dem af webapplikationen. Hvis der for eksempel er en anmodning om adgang til en PDF-fil eller PNG-fil, udleder browsere, der udfører analyse af HTTP-svaret, filtypen.
Overvej en fil med en jpeg-udvidelse, men som faktisk har tekst/HTML-indhold. Efter at have brugt udvidelserne og videregivelsesbeskyttelsen i uploadmodulet, er filen uploadet. Den uploadede fil kaldes via URL'en og MIME Type sniffing returnerer tekst/HTML som et resultat. Det gengiver indholdet som HTML. Det er, når XSS-sårbarheden opstår.
Så du skal forhindre browsere i at bestemme indholdet ved hjælp af MIME Type-sniffing. For at gøre dette kan du bruge nosniff.
X-Content-Type-Options header til Nginx:
add_header X-Content-Type-Options nosniff;
X-Content-Type-Options header til Apache:
Header altid X-Content-Type-Options nosniff
X-Content-Type-Options header til IIS:
<httpProtokol>
<customHeaders>
<tilføje navn ="X-Content-Type-Options" værdi="nosniff" />
</customHeaders>
</httpProtocol>
Hvad er HttpOnly Cookie Flag?
Webapplikationer sporer brugernes sessioner via sessions-id. Browsere gemmer dette og tilføjer det automatisk til hver HTTP-anmodning inden for cookiens omfang.
Det er muligt at bruge cookies til formål dog andet end overførsel af sessionsnøglen. Hackere kunne finde ud af brugerdata ved hjælp af den førnævnte XSS-sårbarhed eller gennem et Cross-Site Request Forgery (CSRF)-angreb. Så hvilke cookies er vigtigst i forhold til sikkerheden?
Du kan betragte informationen i det sidste billede, du klikkede på i billedgalleriet, som et eksempel. På denne måde er HTTP-trafik mindre, og en del af belastningen kan løses af brugerens internetbrowser med scripting på klientsiden.
Det er der Kun Http kommer i. Nedenfor er et eksempel på, hvordan cookie-tildelingen skal være:
Sæt- Cookie: bruger=t=cdabe8a1c2153d726; sti=/; Kun Http
Bemærk HttpOnly-værdien sendt i Sæt-Cookie operation. Browseren vil se dette og behandler ikke værdier med HttpOnly-flaget, når der tilgås cookien via document.cookie variabel. Et andet flag, der bruges i Set-Cookie-processen, er Secure-flaget. Dette indikerer, at cookieværdien kun vil blive tilføjet til overskriften for HTTPS-anmodninger. E-handelswebsteder bruger det normalt, fordi de ønsker at reducere netværkstrafikken og øge ydeevnen.
Ved at bruge denne metode kan du skjule brugernes kritiske data såsom brugernavne, adgangskoder og kreditkortoplysninger. Men der er et problem. Brugere, der fuldfører login-processen, tildeles en cookieværdi uden Secure-flaget. Brugeren kan have sessionsnøglen, når de laver en HTTP-anmodning til ikke-HTTPS-links. Det er nemt at tilføje det sikre flag:
Sæt- Cookie: bruger=t=cdabe8a1c2153d726; sti=/; Sikker
Hvornår bør du ikke bruge HttpOnly? Hvis du stoler på Javascript, bør du være på vagt, da dette i stedet kan gøre dit websted mindre sikkert.
Små trin arbejder for bredere websikkerhed
Du behøver ikke avanceret software og serverviden for at øge sikkerheden i webapplikationer. Ved kun at ændre nogle få linjer kan du forhindre nogle alvorlige angreb. Det er selvfølgelig ikke nok. Det er dog et lille, men effektivt skridt til webstedssikkerhed. Viden er det bedste forebyggende, så det er også nyttigt at kende de subtile nuancer af, hvordan HTTPS beskytter data under overførsel.
