Mitä ovat HTTP-suojausotsikot ja kuinka käytät niitä?

Mitä ovat HTTP-suojausotsikot ja kuinka käytät niitä?
Kaltaisesi lukijat auttavat tukemaan MUO:ta. Kun teet ostoksen käyttämällä sivustollamme olevia linkkejä, voimme ansaita kumppanipalkkion.

Kun haluat vierailla verkkosivustolla, käyttämäsi Internet-selain vastaanottaa tietoja kyseiseltä sivustolta. Tämän seurauksena laitteesi ja verkkosivuston välillä syntyy dialogi. Tämä tapahtuu HTTP-nimisen protokollan kanssa. On mahdollista toteuttaa joitain lisäturvatoimia puuttumalla tähän vuoropuheluun.





PÄIVÄN VIDEON TEKEMINEN

Jos pyörität verkkosivustoa tai haet uraa verkkokehittäjänä, HTTP-tietoturvaotsikot ovat sinulle korvaamattomia, koska niillä on aktiivinen rooli sekä käyttäjän että verkkosivuston turvallisuudessa.





Mikä on HTTP Strict-Transport-Security (HSTS)?

HTTP Strict Transport Security (HSTS) pakottaa käyttäjät käyttämään HTTPS:ää jokaisessa selaimessaan tekemässään pyynnössä. Tämä on vankka tapa torjua kyberhyökkäyksiä, kuten alennusversioita, ja varmistaa kaiken liikenteen turvallisuus.





HSTS:n aktivointi on melko helppoa. Harkitse vuoropuhelua asiakkaan ja palvelimen välillä. Kun yrität päästä sivustolle selaimesi kautta, olet asiakas. Sivu, jonka haluat avata, riippuu palvelimesta. Tavoitteesi on kertoa palvelimelle 'Haluan avata tämän sivuston'. Tämä on pyyntötoiminto. Palvelin puolestaan ​​ohjaa sinut sivustolle, jos täytät halutut ehdot.

Pidä tämä mielessä tämän esimerkin HTTP-otsikkolipun suhteen:



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

Kun lisäät tämän lipun HTTP-vastauksen otsikkotietoihin, kaikista käyttäjien luomista pyynnöistä tulee HTTPS. Mitä tahansa käyttäjä tänne kirjoittaa, selain arvioi protokollan automaattisesti HTTPS:ksi ja muodostaa suojatun yhteyden.

Kuinka käyttää HSTS:ää

Sen sijaan, että lisäisit kaikki nämä HTTP-otsikkotiedot koodikerrokseen, voit tehdä sen Apache-, IIS-, Nginx-, Tomcat- ja muissa verkkopalvelinsovelluksissa.





HSTS:n käyttöönotto Apachessa:

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

HSTS:n käyttöönotto Nginxissä:





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

HSTS:n käyttöönotto IIS web.config -sovelluksella:

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

Cloudflare-käyttäjille

Cloudflare tarjoaa ilmaisen HTTPS-palvelun kaikille avaimettomalla SSL-palvelullaan; Ennen kuin haet HSTS-esilatausta, sinun tulee tietää, että sertifikaattisi ei kuulu sinulle. Monet sivustot käyttävät SSL-varmenteita koska ne ovat yksinkertainen tapa pitää tiedot turvassa.

Kuitenkin Cloudflare nyt tukee HSTS-ominaisuutta . Voit aktivoida kaikki HSTS-ominaisuudet, mukaan lukien esilatauksen, Cloudflare-verkkoliittymän kautta ilman, että sinun tarvitsee kamppailla verkkopalvelimen asetusten kanssa.

Mikä on X-Frame-Options?

  Sivuston turvallisuuden lisääminen HTTP-otsikoilla

X-Frame-Options on suojausotsikko, jota kaikki nykyaikaiset selaimet tukevat. X-Frame-Options pyrkii suojaamaan napsautusvarkauksia, kuten Clickjacking, vastaan. Kuten nimestä voi päätellä, kyse on haavoittuvan sisäisen kehyksen, joka tunnetaan myös nimellä iframe, toiminnasta. Nämä ovat sivuston elementtejä, jotka upottavat toisen HTML-sivun 'emosivustolle', jotta voit käyttää sivustosi sisältöä muista lähteistä. Mutta hyökkääjät käyttävät iframe-kehyksiä omassa hallinnassaan saadakseen käyttäjät suorittamaan toimintoja, joita he eivät halua.

Tästä syystä sinun on estettävä hyökkääjiä löytämästä iframe-kehyksiä sivustolta.

Voinko peruuttaa venmo -maksun

Missä ja miten X-Frame-optioita käytetään?

Mitä X-Frame-Options tekee, jotkut kehittäjät yrittävät tehdä JavaScriptin kaltaisilla kielillä. Tämä ei ole täysin väärin. Riski on kuitenkin olemassa, koska monilta osin kirjoitetut koodit eivät riitä. Joten olisi viisasta jättää tämä tehtävä käyttämällesi Internet-selaimelle.

Kehittäjänä X-Frame-Optionsista on kuitenkin tiedettävä kolme parametria:

  • Kiellä : Estä kokonaan sivun kutsuminen iframe-kehyksessä.
  • SAMEALKUPERÄ : Estä muita verkkotunnuksia kuin omaasi kutsumasta iframe-kehyksessä.
  • SALLI-FROM uri : Hyväksy parametrina annetun URI:n iframe-kutsut. Estä muut.

Tässä, SAMEALKUPERÄ ominaisuus erottuu enemmän. Koska vaikka voit kutsua eri aliverkkotunnuksissasi olevia sovelluksia, joissa on iframe-kehykset toistensa sisällä, voit estää niiden kutsumisen hyökkääjän hallinnassa olevan toimialueen kautta.

Tässä on esimerkkejä siitä, kuinka voit käyttää SAMEORIGIN- ja X-Frame-Options -asetuksia NGINX:n, Apachen ja IIS:n kanssa:

X-Frame-Options SAMEORIGINin käyttö Nginxille:

add_header X-Frame-Options SAMEORIGIN; 

X-Frame-Options SAMEORIGINin käyttäminen Apachelle:

Header always append X-Frame-Options SAMEORIGIN 

X-Frame-Options SAMEORIGINin käyttäminen IIS:ssä:

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

Pelkästään SAMEORIGIN-otsikon lisääminen parantaa vierailijoiden turvallisuutta.

Mikä on X-XSS-suojaus?

X-XSS-Protection-otsikkotietojen käyttäminen voi suojata käyttäjiä XSS-hyökkäyksiltä. Ensinnäkin sinun on poistettava XSS-haavoittuvuudet sovelluksen puolella. Koodipohjaisen suojauksen tarjoamisen jälkeen tarvitaan lisätoimenpiteitä, eli X-XSS-Protection-otsikot, selainten XSS-haavoittuvuuksia vastaan.

Kuinka käyttää X-XSS-suojaa

Nykyaikaiset selaimet voivat havaita mahdolliset XSS-hyötykuormat suodattamalla sovellusten luomaa sisältöä. Tämä ominaisuus on mahdollista aktivoida X-XSS-Protection-otsikkotiedoilla.

Voit ottaa X-XSS-Protection-otsikon käyttöön Nginxissä seuraavasti:

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

X-XSS-Protection-otsikon käyttöönotto Apachessa:

Header always append X-XSS-Protection 1 

X-XSS-Protection-otsikon käyttöönotto IIS:ssä:

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

Voit estää oletusarvoisesti XSS-hyökkäyksen sisältävän koodilohkon suorittamisen käyttämällä jotain tällaista:

X-XSS-Protection: 1; mode=block 

Tämä pieni muutos on tehtävä, jos kyseessä on mahdollisesti vaarallinen tilanne ja haluat estää kaiken sisällön näyttämisen.

Mikä on X-Content-Type-Options?

Selaimet suorittavat MIME Type Sniffing -nimisen analyysin verkkosovelluksen niille tarjoamasta sisällöstä. Jos esimerkiksi PDF- tai PNG-tiedostoon pääsyä pyydetään, HTTP-vastauksen analysointia suorittavat selaimet päättelevät tiedostotyypin.

Harkitse tiedostoa, jossa on jpeg-tunniste, mutta jossa on todella teksti-/HTML-sisältöä. Kun olet käyttänyt laajennuksia ja läpäissyt suojaukset latausmoduulissa, tiedosto on ladattu onnistuneesti. Ladattua tiedostoa kutsutaan URL-osoitteen kautta, ja MIME-tyypin sniffing palauttaa tekstin/HTML-koodin. Se tekee sisällön HTML-muodossa. Silloin XSS-haavoittuvuus ilmenee.

Joten sinun on estettävä selaimia päättämästä sisällöstä MIME-tyypin haistelemalla. Voit tehdä tämän käyttämällä nosniffia.

X-Content-Type-Options-otsikko Nginxille:

add_header X-Content-Type-Options nosniff; 

X-Content-Type-Options-otsikko Apachelle:

Header always X-Content-Type-Options nosniff 

IIS:n X-Content-Type-Options-otsikko:

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

Verkkosovellukset seuraavat käyttäjien istuntoja istuntotunnuksen avulla. Selaimet tallentavat tämän ja lisäävät sen automaattisesti jokaiseen HTTP-pyyntöön evästeen puitteissa.

On mahdollista käyttää evästeitä tarkoituksiin muuta kuin istuntoavaimen siirtoa. Hakkerit voivat löytää käyttäjätiedot käyttämällä edellä mainittua XSS-haavoittuvuutta tai Cross-Site Request Forgery (CSRF) -hyökkäystä. Mitkä evästeet ovat turvallisuuden kannalta tärkeimpiä?

Voit pitää esimerkkinä kuvagalleriassa viimeisen napsauttamasi kuvan sisältämiä tietoja. Tällä tavalla HTTP-liikennettä on vähemmän ja osan kuormituksesta voidaan ratkaista käyttäjän internetselaimella asiakaspuolen komentosarjan avulla.

  HTTP-otsikoiden käyttö sivuston luottamuksellisten tietojen suojaamiseen

Siellä HttpOnly tulee sisään. Alla on esimerkki siitä, kuinka evästeen tulisi olla:

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

Huomaa HttpOnly-arvo, joka on lähetetty Aseta eväste operaatio. Selain näkee tämän eikä käsittele arvoja HttpOnly-lipulla, kun evästettä käytetään document.cookie muuttuja. Toinen Set-Cookie-prosessissa käytetty lippu on Secure-lippu. Tämä tarkoittaa, että evästearvo lisätään otsikkoon vain HTTPS-pyyntöjen yhteydessä. Verkkokauppasivustot käyttävät sitä yleensä, koska ne haluavat vähentää verkkoliikennettä ja parantaa suorituskykyä.

Tällä menetelmällä voit piilottaa käyttäjien tärkeät tiedot, kuten käyttäjätunnukset, salasanat ja luottokorttitiedot. Mutta siinä on ongelma. Käyttäjille, jotka suorittavat kirjautumisprosessin, määritetään evästearvo ilman Secure-lippua. Käyttäjällä voi olla istuntoavain, kun hän tekee HTTP-pyynnön muille kuin HTTPS-linkeille. Turvallisen lipun lisääminen on helppoa:

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

Milloin sinun ei pitäisi käyttää HttpOnlya? Jos luotat Javascriptiin, sinun tulee olla varovainen, koska se voi heikentää sivustosi turvallisuutta.

kuinka siirtää höyrystiedot toiselle tietokoneelle

Pienet askeleet edistävät laajempaa verkkoturvallisuutta

Et tarvitse kehittynyttä ohjelmisto- ja palvelinosaamista lisätäksesi verkkosovellusten turvallisuutta. Muutamalla vain muutaman rivin voit estää vakavia hyökkäyksiä. Tämä ei tietenkään riitä. Se on kuitenkin pieni mutta tehokas askel verkkosivuston turvallisuuden kannalta. Tieto on paras ehkäisy, joten on myös hyödyllistä tietää hienovaraiset vivahteet siitä, kuinka HTTPS suojaa tietoja siirron aikana.