Ghid pentru Verificare antete HTTP

Ce fac antetele de securitate

Fiecare răspuns HTTP poartă antete pe care browserul le citește înainte de a reda pagina. O mână dintre ele activează protecții pe care browserul nu le poate aplica implicit fără să strice site-urile mai vechi: acces exclusiv prin HTTPS, restricții asupra surselor de scripturi, protecție împotriva încadrării paginii de către alt site. Trimiterea lor nu costă aproape nimic și închide clase întregi de atacuri. Niciuna nu cere modificări în codul aplicației; cele mai multe sunt o singură linie adăugată în configurația serverului web. De aceea antetele de securitate se numără printre măsurile cu cel mai bun raport între efort și câștig.

Antetele se aplică per răspuns. Un antet setat într-un bloc de server sau pe o rută a aplicației nu se propagă automat la celelalte, iar proxy-urile și CDN-urile pot adăuga, modifica sau elimina antete. De aceea verificarea răspunsului real din exterior este mai sigură decât citirea fișierelor de configurare. Când părți diferite ale aceluiași site sunt servite de straturi diferite, rezultatul este adesea surprinzător: pagina principală vine cu antetele complete, în timp ce fișierele statice sau paginile de eroare rămân descoperite. Merită, prin urmare, să verificați nu o singură adresă, ci câteva adrese reprezentative ale site-ului.

Cum folosiți Verificare antete HTTP

1. Deschideți Verificare antete HTTP și introduceți un domeniu, de exemplu example.com. Nu este nevoie să scrieți schema.
2. XGM cere https://example.com, urmărește redirecționările și citește antetele paginii finale.
3. Parcurgeți verdictul și constatarea pentru fiecare antet, analiza CSP (surse nesigure, directive lipsă, raportare) și antetele de cache. Antetele lipsă sau slabe vin cu câte un fragment de cod pentru nginx, Apache, Caddy și Cloudflare, pe care îl puteți copia.
4. Deschideți "Toate antetele răspunsului" pentru lista brută, inclusiv antetele de cache și cele de server.
5. După ce schimbați configurația, rulați verificarea din nou; linkul permanent păstrează domeniul în URL. Fila Raport complet adaugă un raport de antete cu punctaj și recomandări.

Pentru că antetele vin de la pagina finală, o redirecționare de la example.com către www.example.com înseamnă că vedeți antetele lui www. Verificați separat răspunsurile de redirecționare ale domeniului gol cu Verificator de redirecționări, mai ales pentru HSTS, care ar trebui trimis și pe redirecționări. Răspunsul de redirecționare este și el un răspuns și își poartă propriile antete. Browserul află de HSTS din primul răspuns pe care îl vede, așa că punerea antetului doar pe pagina finală întârzie protecția cu un pas.

Antetele și ce așteaptă verificatorul

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Scurgeri de versiune și flaguri de cookie

Antete precum Server: nginx/1.18.0 sau X-Powered-By: PHP/7.4.3 spun oricui ce versiuni de software rulați. Asta nu creează în sine o vulnerabilitate, dar economisește timp atacatorilor atunci când o versiune are probleme cunoscute. Verificatorul raportează numerele de versiune din Server, X-Powered-By și din antetele de versiune ASP.NET ca fiind constatări informative. Ascunderea numărului de versiune nu ține locul actualizărilor de securitate; treaba de bază rămâne să rulați versiuni la zi. Totuși, faptul că nu atrageți atenția scanerelor automate reduce simțitor zgomotul pe care îl primiți.

# nginx
server_tokens off;

# PHP (php.ini)
expose_php = Off

Cookie-urile setate de pagină sunt verificate pentru trei flaguri. Secure ține cookie-ul departe de HTTP simplu, HttpOnly îl ascunde de JavaScript, ceea ce contează mai ales la cookie-urile de sesiune, iar SameSite limitează momentele în care browserul îl trimite cu cereri cross-site. Un cookie de sesiune fără aceste flaguri este vizibil mai ușor de furat sau de folosit abuziv. Verificatorul vede doar cookie-urile setate de pagina publică; pe cele emise după autentificare trebuie să le inspectați singuri. Lista de cookie-uri din instrumentele de dezvoltare ale browserului este mai mult decât suficientă pentru asta.

Set-Cookie: session=4f9c2b…; Path=/; Secure; HttpOnly; SameSite=Lax

Greșeli frecvente

Antetul X-XSS-Protection este încă recomandat de unele liste de verificare vechi. Browserele moderne au eliminat funcția pe care o controla, așa că antetul nu mai este util; locul lui a fost luat de o Content Security Policy. Trimiterea lui în continuare nu face rău, dar nu face nimic altceva decât să mărească răspunsul. Același lucru este valabil pentru Expect-CT: este depășit și nu ar trebui adăugat în configurații noi.

Setarea antetelor pe alte servere și platforme

Fragmentele nginx din constatări se traduc direct pentru alte servere web. Setați antetele o singură dată, în stratul care servește fiecare răspuns, și preferați serverul web sau CDN-ul în locul codului aplicației, ca să le primească și fișierele statice, și paginile de eroare. Stratul intermediar al aplicației atinge doar răspunsurile produse de aplicație, însă suprafața care trebuie protejată este mai largă de atât. Singura excepție sunt situațiile în care aveți nevoie de o CSP specifică pentru anumite rute.

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

example.com {
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }
}

CDN-urile și platformele de găzduire oferă de obicei o secțiune de reguli sau de antete în panoul lor ori un fișier de configurare în depozit, pentru adăugarea antetelor de răspuns. După ce le modificați, goliți răspunsurile din cache dacă platforma memorează antetele împreună cu conținutul, apoi verificați din nou din exterior. Pe unele platforme regula se aplică doar răspunsurilor HTML; verificați separat și fișierele de resurse. Propagarea schimbării către toate nodurile de margine poate dura câteva minute, așa că este normal să vedeți valorile vechi la prima verificare.

Țineți o evidență scurtă a stratului care răspunde de fiecare antet. Când un site se mută pe o platformă nouă, antetele de securitate sunt printre setările pierdute cel mai des, pentru că nimic nu se strică vizibil atunci când dispar. Rularea verificatorului după fiecare migrare prinde asta în câteva secunde. Aceeași evidență vă ajută și după o actualizare majoră de versiune sau după o schimbare de reverse proxy. Acest obicei mic este cea mai ieftină cale de a împiedica o configurație să se erodeze tăcut de-a lungul anilor.

Alte antete care merită o privire

Lista brută de antete arată și setările de cache și de performanță. Cache-Control decide cât timp păstrează browserele și CDN-urile un răspuns, iar paginile cu date personale ar trebui să folosească private sau no-store. Compresia apare ca Content-Encoding: gzip sau br, iar Vary explică ce antete de cerere schimbă răspunsul. Un Vary greșit setat poate face ca un cache partajat să dea răspunsul unui utilizator altcuiva. De aceea antetele de cache merită citite cu cel puțin aceeași atenție ca antetele de securitate.

Antetele de izolare între origini (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy și Cross-Origin-Resource-Policy) contează pentru aplicațiile care au nevoie de funcții puternice ale browserului sau care vor o izolare strictă față de alte site-uri. Pentru majoritatea site-urilor nu sunt obligatorii, așa că verificatorul le enumeră fără să le noteze. Dacă folosiți funcții precum SharedArrayBuffer, primele două sunt oricum necesare. În rest, adăugarea lor este o întărire sigură pentru site-urile care nu depind de conținut încorporat de la terți.

Întrebări frecvente

Surse

• MDN: referință pentru antetele HTTP
• RFC 6797: HTTP Strict Transport Security
• W3C: Content Security Policy Level 3
• RFC 6265: HTTP State Management Mechanism (cookie-uri)
• OWASP HTTP Security Response Headers Cheat Sheet