Vad är HTTP-säkerhetsrubriker och hur använder du dem?

Läsare som du hjälper till att stödja MUO. När du gör ett köp med hjälp av länkar på vår webbplats kan vi tjäna en affiliate-provision.

När du vill besöka en webbplats tar webbläsaren du använder en del data från den webbplatsen. Som ett resultat uppstår en dialog mellan din enhet och webbplatsen. Detta händer med protokollet som heter HTTP. Det är möjligt att vidta ytterligare säkerhetsåtgärder genom att ingripa i denna dialog.

MAKEUSE AV DAGENS VIDEO

Om du driver en webbplats eller siktar på karriär som webbutvecklare är HTTP-säkerhetsrubriker ovärderliga för dig, eftersom de spelar en aktiv roll i säkerheten för både användaren och webbplatsen.

hitta en romantisk roman efter beskrivning

Vad är HTTP Strict-Transport-Security (HSTS)?

HTTP Strict Transport Security (HSTS) tvingar användare att använda HTTPS för varje begäran de gör i sin webbläsare. Detta är ett solidt sätt att bekämpa cyberattacker som nedgraderingar och för att säkerställa säkerheten för all trafik.

Att aktivera HSTS är ganska enkelt. Tänk på dialogen mellan klienten och servern. När du försöker komma åt en webbplats via din webbläsare är du klienten. Webbplatsen du vill öppna beror på servern. Ditt mål är att säga till servern 'Jag vill öppna den här webbplatsen'. Detta är en begäran. Servern, å andra sidan, dirigerar dig till sajten om du uppfyller de önskade villkoren.

Tänk på detta när det gäller denna exempelflagga för HTTP-huvud:

Strict-Transport-Security: max-age=16070200;

När du lägger till denna flagga i huvudinformationen för HTTP-svaret kommer alla användargenererade förfrågningar att bli HTTPS. Vad användaren än skriver här kommer webbläsaren automatiskt att utvärdera protokollet som HTTPS och upprätta en säker anslutning.

Hur man använder HSTS

Istället för att lägga till all denna HTTP-huvudinformation i kodlagret kan du göra det på Apache, IIS, Nginx, Tomcat och andra webbserverapplikationer.

Så här aktiverar du HSTS i Apache:

LoadModule headers_module modules/mod_headers.so 
<VirtualHost *:443> 
    Header always set Strict-Transport-Security "max-age=2592000; includeSubDomains" 
</VirtualHost>

Så här aktiverar du HSTS i Nginx:

add_header Strict-Transport-Security max-age=2592000; includeSubdomains

Så här aktiverar du HSTS med IIS web.config:

<system.webServer> 
   <httpProtocol> 
       <customHeaders> 
           <add name="Strict-Transport-Security" value="max-age=63072000"/> 
       </customHeaders> 
   </httpProtocol> 
</system.webServer>

För Cloudflare-användare

Cloudflare tillhandahåller gratis HTTPS-tjänst för alla med sin Keyless SSL-tjänst; innan du ansöker om HSTS preload bör du veta att ditt certifikat inte tillhör dig. Många webbplatser använder SSL-certifikat eftersom de är ett enkelt sätt att hålla data säker.

Dock Cloudflare nu stöder HSTS-funktionen . Du kan aktivera alla HSTS-funktioner, inklusive förladdning, via Cloudflares webbgränssnitt utan att behöva kämpa med konfigurationerna på webbservern.

Vad är X-Frame-Options?

Öka säkerheten på webbplatsen med HTTP-rubriker

X-Frame-Options är ett säkerhetshuvud som stöds av alla moderna webbläsare. X-Frame-Options syftar till att skydda mot klickstöld som Clickjacking. Som namnet antyder handlar det om hur en sårbar inline-ram fungerar, även känd som en iframe. Dessa är element på en webbplats som bäddar in en annan HTML-sida på 'förälder'-webbplatsen, så att du kan använda innehåll från andra källor på din webbplats. Men angripare använder iframes under sin egen kontroll för att få användare att utföra åtgärder som de inte vill.

Av denna anledning måste du förhindra att angripare kan hitta iframes på webbplatsen.

Var och hur använder man X-Frame-Options?

Vad X-Frame-Options gör, försöker vissa utvecklare göra med språk som JavaScript. Detta är inte helt fel. Det finns dock fortfarande en risk eftersom koderna skrivna i många aspekter inte räcker. Så det skulle vara klokt att lämna denna uppgift till webbläsaren du använder.

Men som utvecklare finns det tre parametrar att veta om X-Frame-Options:

Förneka : Förhindra helt att sidan anropas i någon iframe.
SAMEORIGIN : Förhindra någon annan domän än din egen från att ringa inom iframen.
TILLÅT-FRÅN uri : Acceptera iframe-anrop av URI som anges som parameter. Blockera andra.

Här, den SAMEORIGIN funktion sticker ut mer. För medan du kan anropa applikationer i dina olika underdomäner med iframes inom varandra, kan du förhindra att de anropas över domänen under angriparens kontroll.

Här är exempel på hur du kan använda SAMEORIGIN och X-Frame-Options med NGINX, Apache och IIS:

Använda X-Frame-Options SAMEORIGIN för Nginx:

add_header X-Frame-Options SAMEORIGIN;

Använda X-Frame-Options SAMEORIGIN för Apache:

Header always append X-Frame-Options SAMEORIGIN

Använda X-Frame-Options SAMEORIGIN för IIS:

<httpProtocol> 
   <customHeaders> 
     <add name="X-Frame-Options" value="SAMEORIGIN" /> 
   </customHeaders> 
 </httpProtocol>

Att bara lägga till SAMEORIGIN-huvudet kommer att ge större säkerhet för dina besökare.

Vad är X-XSS-skydd?

Att använda X-XSS-Protection-huvudinformation kan skydda användare från XSS-attacker. För det första måste du eliminera XSS-sårbarheter på applikationssidan. Efter att ha tillhandahållit kodbaserad säkerhet krävs ytterligare åtgärder, det vill säga X-XSS-Protection headers, mot XSS-sårbarheter i webbläsare.

Hur man använder X-XSS-Protection

Moderna webbläsare kan upptäcka potentiella XSS-nyttolaster genom att filtrera applikationsgenererat innehåll. Det är möjligt att aktivera denna funktion med X-XSS-Protection-huvudinformationen.

Så här aktiverar du X-XSS-Protection-huvudet i Nginx:

add_header X-Frame-X-XSS-Protection 1;

Så här aktiverar du X-XSS-Protection-huvudet i Apache:

Header always append X-XSS-Protection 1

Så här aktiverar du X-XSS-Protection-huvudet i IIS:

<httpProtocol> 
   <customHeaders> 
     <add name="X-XSS-Protection" value="1" /> 
   </customHeaders> 
 </httpProtocol>

För att förhindra att kodblocket med XSS-attack körs som standard, kan du använda något så här:

X-XSS-Protection: 1; mode=block

Denna mindre ändring måste göras om det finns en potentiellt farlig situation och du vill förhindra att allt innehåll renderas.

Vad är X-Content-Type-Options?

Webbläsare utför en analys som kallas MIME Type Sniffing på innehåll som presenteras för dem av webbapplikationen. Om det till exempel finns en begäran om åtkomst till en PDF-fil eller PNG-fil, härleder webbläsare som utför analys av HTTP-svaret filtypen.

Överväg en fil med filtillägget jpeg men som faktiskt har text/HTML-innehåll. Efter att ha använt tilläggen och överföringsskydden i uppladdningsmodulen har filen laddats upp. Den uppladdade filen anropas via URL:en och MIME Typ sniffning returnerar Text/HTML som ett resultat. Det återger innehållet som HTML. Det är då XSS-sårbarheten uppstår.

Så du måste förhindra webbläsare från att bestämma innehåll genom att sniffa med MIME-typ. För att göra detta kan du använda nosniff.

X-Content-Type-Options header för Nginx:

add_header X-Content-Type-Options nosniff;

X-Content-Type-Options header för Apache:

Header always X-Content-Type-Options nosniff

X-Content-Type-Options-rubrik för IIS:

<httpProtocol> 
   <customHeaders> 
     <add name="X-Content-Type-Options" value="nosniff" /> 
   </customHeaders> 
 </httpProtocol>

Webbapplikationer spårar användarnas sessioner via sessions-ID. Webbläsare kommer att lagra detta och automatiskt lägga till det i varje HTTP-förfrågan inom cookiens räckvidd.

Det är möjligt att använda cookies för ändamål annat än överföringen av sessionsnyckeln, dock. Hackare kan ta reda på användardata genom att använda den tidigare nämnda XSS-sårbarheten eller genom en Cross-Site Request Forgery (CSRF)-attack. Så vilka cookies är viktigast med tanke på säkerheten?

Du kan betrakta informationen i den senaste bilden du klickade på i bildgalleriet som ett exempel. På så sätt blir HTTP-trafiken mindre och en del av belastningen kan lösas av användarens webbläsare med skript på klientsidan.

Användning av HTTP-rubriker för att skydda konfidentiell information på webbplatsen

Det är där Endast Http kommer in. Nedan är ett exempel på hur cookie-tilldelningen ska vara:

Set-Cookie: user=t=cdabe8a1c2153d726; path=/; HttpOnly

Lägg märke till HttpOnly-värdet som skickas i Set-Cookie drift. Webbläsaren kommer att se detta och kommer inte att bearbeta värden med HttpOnly-flaggan när cookien nås via document.cookie variabel. En annan flagga som används i Set-Cookie-processen är Secure-flaggan. Detta indikerar att cookievärdet kommer att läggas till i rubriken endast för HTTPS-förfrågningar. E-handelssajter använder det vanligtvis för att de vill minska nätverkstrafiken och öka prestandan.

Med den här metoden kan du dölja användarnas viktiga data som användarnamn, lösenord och kreditkortsinformation. Men det är ett problem. Användare som slutför inloggningsprocessen tilldelas ett cookievärde utan Säker-flaggan. Användaren kan ha sessionsnyckeln när de gör en HTTP-förfrågan till icke-HTTPS-länkar. Det är enkelt att lägga till den säkra flaggan:

varför är gtx 1080 så dyra

Set-Cookie: user=t=cdabe8a1c2153d726; path=/; Secure

När ska du inte använda HttpOnly? Om du förlitar dig på Javascript bör du vara försiktig eftersom det kan göra din webbplats mindre säker istället.

Små steg fungerar för bredare webbsäkerhet

Du behöver ingen avancerad mjukvara och serverkunskap för att öka säkerheten för webbapplikationer. Genom att bara ändra några rader kan du förhindra några allvarliga attacker. Naturligtvis räcker inte detta. Det är dock ett litet men effektivt steg för webbplatssäkerhet. Kunskap är det bästa förebyggande medlet, så det är också användbart att känna till de subtila nyanserna av hur HTTPS skyddar data under överföring.