Kas ir HTTP drošības galvenes un kā tās izmantot?

Tādi lasītāji kā jūs palīdz atbalstīt MUO. Veicot pirkumu, izmantojot saites mūsu vietnē, mēs varam nopelnīt filiāles komisiju.

Kad vēlaties apmeklēt vietni, jūsu izmantotā interneta pārlūkprogramma saņem dažus datus no šīs vietnes. Tā rezultātā starp jūsu ierīci un vietni notiek dialogs. Tas notiek ar protokolu, ko sauc par HTTP. Ir iespējams veikt dažus papildu drošības pasākumus, iejaucoties šajā dialogā.

DIENAS VIDEO MAKEUSEOF

Ja vadāt vietni vai plānojat tīmekļa izstrādātāja karjeru, HTTP drošības galvenes jums ir nenovērtējamas, jo tām ir aktīva loma gan lietotāja, gan vietnes drošībā.

kā darbojas google dokumenti?

Kas ir HTTP stingrā transporta drošība (HSTS)?

HTTP stingrā transporta drošība (HSTS) liek lietotājiem izmantot HTTPS katram pieprasījumam, ko viņi veic savā pārlūkprogrammā. Tas ir labs veids, kā cīnīties pret kiberuzbrukumiem, piemēram, pazemināšanu, un nodrošināt visas satiksmes drošību.

HSTS aktivizēšana ir diezgan vienkārša. Apsveriet dialogu starp klientu un serveri. Mēģinot piekļūt vietnei, izmantojot pārlūkprogrammu, jūs esat klients. Vietne, kuru vēlaties atvērt, ir atkarīga no servera. Jūsu mērķis ir pateikt serverim: 'Es vēlos atvērt šo vietni'. Šī ir pieprasījuma darbība. No otras puses, serveris novirza jūs uz vietni, ja atbilstat vēlamajiem nosacījumiem.

Paturiet to prātā saistībā ar šo HTTP galvenes karoga paraugu:

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

Pievienojot šo karogu HTTP atbildes galvenes informācijai, visi lietotāja ģenerētie pieprasījumi kļūs par HTTPS. Neatkarīgi no tā, ko lietotājs šeit raksta, pārlūkprogramma automātiski novērtēs protokolu kā HTTPS un izveidos drošu savienojumu.

Kā lietot HSTS

Tā vietā, lai koda slānī pievienotu visu šo HTTP galvenes informāciju, varat to izdarīt Apache, IIS, Nginx, Tomcat un citās tīmekļa servera lietojumprogrammās.

Lai iespējotu HSTS programmā Apache:

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

Lai iespējotu HSTS Nginx:

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

Lai iespējotu HSTS ar IIS web.config:

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

Cloudflare lietotājiem

Cloudflare nodrošina bezmaksas HTTPS pakalpojumu ikvienam ar savu Keyless SSL pakalpojumu; pirms pieteikšanās HSTS priekšielādēšanai, jums jāzina, ka jūsu sertifikāts jums nepieder. Daudzas vietnes izmanto SSL sertifikātus jo tie ir vienkāršs veids, kā nodrošināt datu drošību.

Tomēr Cloudflare tagad atbalsta HSTS funkciju . Varat aktivizēt visas HSTS funkcijas, tostarp priekšielādēšanu, izmantojot Cloudflare tīmekļa saskarni, bez problēmām ar tīmekļa servera konfigurācijām.

Kas ir X-Frame-Options?

Vietnes drošības paaugstināšana ar HTTP galvenēm

X-Frame-Options ir drošības galvene, ko atbalsta visas mūsdienu pārlūkprogrammas. X-Frame-Options mērķis ir aizsargāt pret klikšķu zādzību, piemēram, Clickjacking. Kā norāda nosaukums, runa ir par ievainojama iekļautā rāmja, kas pazīstams arī kā iframe, darbību. Tie ir vietnes elementi, kas iegulst citu HTML lapu “sākumvietnē”, lai savā vietnē varētu izmantot saturu no citiem avotiem. Taču uzbrucēji savā kontrolē izmanto iframe, lai liktu lietotājiem veikt darbības, kuras viņi nevēlas.

Šī iemesla dēļ jums ir jānovērš uzbrucēju iespēja vietnē atrast iframe.

Kur un kā izmantot X-Frame-Options?

Tas, ko dara X-Frame-Options, daži izstrādātāji cenšas darīt ar tādām valodām kā JavaScript. Tas nav pilnīgi nepareizi. Tomēr joprojām pastāv risks, jo daudzos aspektos rakstītie kodi nav pietiekami. Tāpēc būtu prātīgi atstāt šo uzdevumu izmantotajai interneta pārlūkprogrammai.

Tomēr kā izstrādātājam par X-Frame-Options ir jāzina trīs parametri:

Noliegt : pilnībā novērsiet lapas izsaukšanu jebkurā iframe.
SAMEIZCELSMES : neļaujiet kādam citam domēnam zvanīt iframe ietvaros.
ATĻAUJ-NO uri : pieņemt URI iframe izsaukumus, kas norādīti kā parametrs. Bloķēt citus.

Lūk, SAMEIZCELSMES funkcija izceļas vairāk. Tā kā, lai gan jūs varat izsaukt lietojumprogrammas savos dažādos apakšdomēnos ar iframe savā starpā, varat novērst to izsaukšanu, izmantojot uzbrucēja kontrolēto domēnu.

Šeit ir piemēri, kā varat izmantot SAMEORIGIN un X-Frame-Options ar NGINX, Apache un IIS:

Izmantojot X-Frame-Options SAMEORIGIN for Nginx:

add_header X-Frame-Options SAMEORIGIN;

X-Frame-Options SAMEORIGIN izmantošana darbam ar Apache:

Header always append X-Frame-Options SAMEORIGIN

X-Frame-Options SAMEORIGIN izmantošana IIS:

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

Vienkārši pievienojot galveni SAMEORIGIN, jūsu apmeklētājiem tiks nodrošināta lielāka drošība.

Kas ir X-XSS aizsardzība?

Izmantojot X-XSS-Protection galvenes informāciju, var aizsargāt lietotājus no XSS uzbrukumiem. Pirmkārt, jums ir jānovērš XSS ievainojamības pieteikuma pusē. Pēc uz kodu balstītas drošības nodrošināšanas ir nepieciešami turpmāki pasākumi, t.i., X-XSS-Protection galvenes pret XSS ievainojamību pārlūkprogrammās.

Kā lietot X-XSS-Protection

Mūsdienu pārlūkprogrammas var noteikt potenciālo XSS lietderīgo slodzi, filtrējot lietojumprogrammu ģenerētu saturu. Šo funkciju var aktivizēt, izmantojot X-XSS-Protection galvenes informāciju.

Lai iespējotu X-XSS-Protection galveni Nginx:

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

Lai iespējotu X-XSS-Protection galveni Apache:

Header always append X-XSS-Protection 1

Lai iespējotu X-XSS-Protection galveni IIS:

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

Lai novērstu koda bloka darbību ar XSS uzbrukumu pēc noklusējuma, varat izmantot kaut ko līdzīgu:

X-XSS-Protection: 1; mode=block

Šīs nelielās izmaiņas ir jāveic, ja pastāv potenciāli bīstama situācija un vēlaties novērst visa satura renderēšanu.

Kas ir X-Content-Type-Options?

Pārlūkprogrammas veic tīmekļa lietojumprogrammas piedāvātā satura analīzi, ko sauc par MIME tipa sniffing. Piemēram, ja ir pieprasījums piekļūt PDF failam vai PNG failam, pārlūkprogrammas, kas veic HTTP atbildes analīzi, nosaka faila veidu.

Apsveriet failu ar jpeg paplašinājumu, bet kurā faktiski ir teksta/HTML saturs. Pēc paplašinājumu izmantošanas un aizsardzības nokārtošanas augšupielādes modulī fails tiek veiksmīgi augšupielādēts. Augšupielādētais fails tiek izsaukts, izmantojot URL, un MIME tipa sniffing atgriež tekstu/HTML. Tas atveido saturu kā HTML. Tieši tad rodas XSS ievainojamība.

Tāpēc jums ir jānovērš tas, ka pārlūkprogrammas pieņem lēmumu par saturu, izmantojot MIME tipa šņaukšanu. Lai to izdarītu, varat izmantot nosniff.

X-Content-Type-Options galvene Nginx:

add_header X-Content-Type-Options nosniff;

Apache X-Content-Type-Options galvene:

Header always X-Content-Type-Options nosniff

IIS galvene X-Content-Type-Options:

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

Tīmekļa lietojumprogrammas izseko lietotāju sesijas, izmantojot sesijas ID. Pārlūkprogrammas to saglabās un automātiski pievienos katram HTTP pieprasījumam sīkfaila darbības jomā.

Tas ir iespējams izmantot sīkdatnes mērķiem izņemot sesijas atslēgas pārsūtīšanu. Hakeri varētu uzzināt lietotāja datus, izmantojot iepriekš minēto XSS ievainojamību vai izmantojot Cross-Site Request Forgery (CSRF) uzbrukumu. Tātad, kuri sīkfaili ir vissvarīgākie drošības ziņā?

Kā piemēru varat ņemt vērā informāciju, kas ietverta pēdējā attēlā, uz kura noklikšķinājāt attēlu galerijā. Tādā veidā HTTP trafiks ir mazāks un daļu no slodzes var atrisināt lietotāja interneta pārlūkprogramma ar klienta puses skriptēšanu.

HTTP galveņu izmantošana, lai aizsargātu konfidenciālu informāciju vietnē

Tieši tur HttpOnly Tālāk ir sniegts piemērs tam, kā vajadzētu būt sīkfailu piešķiršanai:

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

Ievērojiet HttpOnly vērtību, kas nosūtīta Set-Cookie darbība. Pārlūkprogramma to redzēs un neapstrādās vērtības ar karodziņu HttpOnly, kad sīkfailam piekļūst, izmantojot document.cookie mainīgs. Vēl viens karogs, ko izmanto Set-Cookie procesā, ir drošs karogs. Tas norāda, ka sīkfaila vērtība tiks pievienota galvenē tikai HTTPS pieprasījumiem. E-komercijas vietnes to parasti izmanto, jo vēlas samazināt tīkla trafiku un palielināt veiktspēju.

kā pārsūtīt no ipod uz itunes

Izmantojot šo metodi, varat paslēpt lietotāju kritiskos datus, piemēram, lietotājvārdus, paroles un kredītkaršu informāciju. Bet ir problēma. Lietotājiem, kuri pabeidz pieteikšanās procesu, tiek piešķirta sīkfaila vērtība bez karoga Secure. Lietotājam var būt sesijas atslēga, kad viņš veic HTTP pieprasījumu saitēm, kas nav HTTPS saites. Drošā karoga pievienošana ir vienkārša:

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

Kad nevajadzētu izmantot HttpOnly? Ja paļaujaties uz Javascript, esiet piesardzīgs, jo tas var padarīt jūsu vietni mazāk drošu.

Mazi soļi nodrošina plašāku tīmekļa drošību

Jums nav nepieciešamas uzlabotas programmatūras un servera zināšanas, lai palielinātu tīmekļa lietojumprogrammu drošību. Mainot tikai dažas rindiņas, jūs varat novērst dažus nopietnus uzbrukumus. Protams, ar to nepietiek. Tomēr tas ir neliels, bet efektīvs solis vietnes drošībai. Zināšanas ir vislabākā profilakse, tāpēc ir arī noderīgi zināt smalkās nianses, kā HTTPS aizsargā datus pārsūtīšanas laikā.