Biztonsági fejlécek weboldalakhoz: security header helyes beállítása

Röviden: A security headerek a webszerver utasításai a böngésző számára, amelyek a látogatókat olyan támadások ellen védik, mint a Cross-Site Scripting, a clickjacking és a titkosítatlan kapcsolatok. A legfontosabbak a HSTS, a Content-Security-Policy, az X-Content-Type-Options, az idegen keretek elleni védelem, a Referrer-Policy és a Permissions-Policy. Értelmes keményítést jelentenek, de nem pótolják a szerveren végzett frissítéseket.

Mit tudnak a security headerek, és mit nem

Minden oldalmeghíváskor a webszerver a tartalom mellett fejléceket is küld. Ezek némelyike a böngésző biztonsági funkcióit vezérli. Így például rögzíthető, hogy egy oldalt csak HTTPS-en töltsenek be, vagy hogy a böngésző ne futtasson szkripteket idegen domainekről.

Az üzemeltetők számára a besorolás fontos: a fejlécek elsősorban a látogatókat védik, például a munkamenetek elfogásától vagy a manipulált űrlapoktól. A szerveren lévő réseket nem zárják le. A PHP-ban, a CMS-ben vagy egy bővítményben lévő sebezhetőség megmarad, bármilyen jól vannak is beállítva a fejlécek. Rendezett kóddal együtt azonban jelentősen korlátozzák sok hiba következményeit.

A legfontosabb security headerek áttekintése

A HSTS-t csak akkor állítsa be, ha az összes aldomain megbízhatóan elérhető HTTPS-en. A böngésző a megadott ideig megjegyzi az utasítást; egy hibát ekkor nem lehet azonnal visszavonni. Adott esetben rövid futamidővel kezdje, és sikeres tesztek után növelje. A kiegészítő preload opció tartósan felveszi a domaint a böngészőgyártók listáiba, és csak gondos ellenőrzés után szabad beállítani.

A fejlécek egyébként nem az egyetlen hely, ahol a böngésző védelmet kínál. A cookie-k viseljék a Secure, HttpOnly és SameSite attribútumokat, hogy a munkameneteket ne lehessen titkosítatlan kapcsolatokon vagy szkripteken keresztül elfogni. Hogyan állíthatja ezt be PHP-ban, azt a munkamenetekről szóló útmutató írja le.

Security headerek beállítása Nginxben

Az Nginxben a fejlécek az adott weboldal server blokkjába tartoznak. Az always kiegészítés gondoskodik arról, hogy a hibaoldalaknál is elküldjék őket.

server {
    # ...
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" 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;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'" always;

    server_tokens off;
}

Az Nginx egyik sajátossága: ha egy location blokk saját add_header utasításokat állít be, a server blokk fejléceit ott nem veszi át. Ezért az aloldalakat és a statikus fájlokat is ellenőrizze. Erről a kombinációról további keményítést ír le az Az Nginx és a PHP-FPM biztonságos beállítása oldal.

Security headerek beállítása Apache-ban

Apache alatt szüksége van a mod_headers modulra. Az utasítások a VirtualHostba tartoznak, vagy ha ahhoz nincs hozzáférés, a .htaccess-be.

<IfModule mod_headers.c>
    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"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

ServerTokens Prod
ServerSignature Off

A ServerTokens és a ServerSignature a fő konfigurációba tartozik. Megakadályozzák, hogy a szerver a válaszokban és a hibaoldalakon megnevezze a pontos verzióját. A php.ini-ben ugyanezt a PHP-nál az expose_php = Off értékkel éri el.

A Content Security Policy fokozatos bevezetése

A Content Security Policy a leghatékonyabb, de egyben a legigényesebb fejléc. Meghatározza, mely forrásokból tölthetők be szkriptek, stíluslapok, képek, betűtípusok és keretek. Ha egy bejuttatott szkriptet idegen domainről töltenek utána, a böngésző blokkolja.

A modern weboldalak gyakran elemző eszközöket, fizetési szolgáltatókat, térképszolgáltatásokat vagy videókat ágyaznak be. Egy túl szigorú irányelv ekkor funkciókat bénít meg. Ezért lépésekben járjon el:

• Először a Content-Security-Policy-Report-Only-val kezdjen. A böngésző a szabálysértéseket a fejlesztői konzolban vagy egy gyűjtőcímre jelenti, de nem blokkol semmit.
• Mérje fel az összes szükséges forrást, és célzottan engedélyezze őket, általános helyettesítők használata helyett.
• A beágyazott szkripteket fokozatosan szervezze ki fájlokba, vagy lássa el nonce-okkal, hogy az 'unsafe-inline' mellőzhető legyen.
• Csak egy váratlan üzenetek nélküli tesztidőszak után váltson át Content-Security-Policy-ra.

A fejlécek ellenőrzése és a tipikus hibák elkerülése

Minden módosítás után ellenőrizze, hogy a fejlécek ténylegesen megérkeznek-e. Ez további eszközök nélkül is megy a curl-lel:

# A konfiguráció tesztelése és újratöltése
nginx -t && systemctl reload nginx

# A nyitóoldal és egy statikus fájl fejléceinek megjelenítése
curl -sI https://www.example.de/ | grep -iE 'strict|content-security|x-content|x-frame|referrer|permissions|server'
curl -sI https://www.example.de/favicon.ico | grep -iE 'strict|x-content'

Tipikus hibák: kétszer beállított fejlécek, ha a webszerver és az alkalmazás ugyanazokat a fejléceket küldi; egy előtte álló CDN, amely eltávolítja vagy felülírja a fejléceket; és olyan fejlécek, amelyek csak a nyitóoldalon jelennek meg, az átirányításoknál vagy a hibaoldalakon azonban nem. Ellenőrizze emellett a CMS vagy a biztonsági bővítmények frissítései után, hogy megváltoztak-e a fejlécek.

Rögzítse ezért azt az egy helyet, ahol a fejléceket gondozzák, a legjobb a webszerver vagy az előtte álló szolgáltatás. Sok CMS-bővítmény szintén kínál beállításokat a biztonsági fejlécekhez. Ez kényelmes, de könnyen vezet kétszeres vagy ellentmondó adatokhoz, ha emellett a szerver is állít be fejléceket. Egyes tesztekhez a böngésző fejlesztői eszközei is megfelelnek: a hálózat fülön minden kéréshez látja a válaszfejléceket, a konzol pedig kijelzi a Content Security Policy megsértéseit.

Hogyan segít konkrétan a PHP SOS?

• Ellenőrizzük az összes weboldala aktuális fejléceit, a CDN és a proxy mögött is, és rámutatunk a hiányosságokra és az ellentmondásokra.
• A fejléceket a szerver-keményítés keretében központilag a webszerverben állítjuk be, és teszteljük a nyitóoldalt, az aloldalakat és a hibaoldalakat.
• A Content Security Policyt Report-Only módban vezetjük be, kiértékeljük az üzeneteket, és egyeztetés után élesítjük.
• Ahol a kódmódosítás nem lehetséges azonnal, a védelmet WAF-szabályokkal és virtuális javítással egészítjük ki.

Gyakori kérdések

Források

• OWASP Cheat Sheet Series (HTTP Headers)
• OWASP Top 10
• BSI: ajánlások webszerverekhez (a német Szövetségi Információbiztonsági Hivatal)