Nincs kitett fájl

A webszerver minden fájlt kiad, ami a nyilvános mappában van, hacsak nem tiltod. Egy elfelejtett hibanapló, egy szerkesztő által készült konfigurációs másolat vagy egy környezeti fájl hozzáférési adatokat, belső útvonalakat, programkódot tartalmazhat. Ez a teszt négy ilyen, WordPress-oldalon gyakori fájl nyilvános elérhetőségét ellenőrzi.

Az OWASP Web Security Testing Guide is külön említi az elfelejtett, mentési és nem hivatkozott fájlokat: szerkesztő- és kézi mentések (például fájl~, .old, .bak) gyakran más kiterjesztéssel, ezért futtatás helyett sima szövegként adódnak ki, és így a kód vagy a hozzáférési adatok kiszivároghatnak. A naplófájlokban érzékeny adat is lehet.

Ha az oldal nem WordPress, a teszt nem értelmezhető.

Hogyan mérjük

A teszt a mért oldal hosztján négy címet kér le, mindegyikből legfeljebb az első 64 KB-ot (részleges lekérés). A tartalmat nem őrzi meg.

Fájl	Hol keresi	Mikor számít kitettnek
readme.html	a WordPress gyökerében (Bedrocknál /wp/readme.html)	200 vagy 206 válasz, és a tartalma a WordPress saját readme-oldala
debug.log	a tartalommappában (/wp-content/debug.log, Bedrocknál /app/debug.log)	200 vagy 206, nem HTML tartalomtípus, és a törzs naplósorokkal kezdődik ([nap-hónap-év óra:perc:másodperc alakú időbélyeg)
.env	a webroot gyökerében (/.env)	200 vagy 206, nem HTML, és NÉV=érték alakú sorokat tartalmaz
wp-config.php~	a WordPress gyökerében	200 vagy 206, nem HTML tartalomtípus, és tartalmaz <?php jelölést (vagy DB_NAME szöveget, ha nem HTML-oldal); a szerkesztő által készült konfigurációs másolat

Az átmeneti hibaoldalakat (HTML-ben kiadott „nem található” oldalak 200 kóddal) a teszt nem számolja találatnak.

Eredmény	Mikor
Megfelelő	Mind a négy fájlt sikerült lekérni, és egyik sem kitett.
Hiba (magas súlyosság)	Legalább egy fájl kitett. A kártya felsorolja, melyik.
Hiba (alacsony súlyosság)	Csak a readme.html kitett.
Nem értelmezhető	Nem WordPress az oldal, vagy nem sikerült mind a négy ellenőrzés (például időtúllépés vagy kérésszám-korlát miatt) és semmi nem volt kitett: részleges ellenőrzésre a teszt nem ad megfelelőt.

Mit nem néz a teszt. Csak ezt a négy fájlt. Más mentési vagy konfigurációs másolatot (például más néven mentett adatbázis-exportot, tömörített mentést, verziókezelő mappát) nem keres, ezért a zöld eredmény nem jelenti azt, hogy a nyilvános mappában nincs más érzékeny fájl.

Hogyan javítsd

A cél kettős: a fájl ne legyen nyilvános, és ami egyszer nyilvános volt, azt tekintsd kiszivárgottnak.

1. Töröld a fájlt a nyilvános mappából, ha nincs rá szükség. Ez a legbiztosabb megoldás: wp-config.php~, .env a webrootból, a debug.log a tartalommappából.
2. Cseréld a benne lévő titkokat. Ha a kitett fájl hozzáférési adatot tartalmazhatott (adatbázis-jelszó, API-kulcs, sózó kulcsok), cseréld ezeket, és nézd át a hozzáféréseket. A törlés nem vonja vissza azt, hogy a fájl addig elérhető volt.
3. Kapcsold ki a hibanaplót éles oldalon, vagy vidd a nyilvános mappán kívülre. A WordPress dokumentációja szerint a WP_DEBUG_LOG igaz értéknél a debug.log a tartalommappába kerül, de érvényes fájlútvonal is megadható, így máshová menthető. Éles oldalon a hibák kiírását (WP_DEBUG_DISPLAY) is kapcsold ki.
4. Tiltsd le a hozzáférést szerver szinten, hogy a fájl akkor se legyen elérhető, ha valamiért újra megjelenik. Az alábbi szabályokban hagyd meg azokat a neveket, amelyeket a riport kitettnek jelzett.
5. Bedrock-alapú oldalon a webroot a web/ mappa legyen, akkor a gyökérben lévő .env nem érhető el.
6. Ne hagyj mentést a nyilvános mappában. A szerkesztők és a kézi másolatok (~, .old, .bak) maradjanak a webrooton kívül.

nginx

Tedd a többi regex location elé, a location ~ \.php blokk elé is, mert az nginx az elsőt használja, amelyik illeszkedik. Ha a többi location egy location / { … } belsejében van, oda, azok elé tedd. Ha egy illeszkedő prefix location ^~ jelölésű, a regexeket az nginx nem nézi: oda is tedd be. A legjobb, ha a fájlokat törlöd.

nginx

location ~* (^|/)(readme\.html|debug\.log|\.env|wp-config\.php~)(/|$) {
    deny all;
}

Apache (.htaccess)

A webroot .htaccess fájljának elejére, minden más átírási szabály (RewriteRule) elé; WordPress alatt a # BEGIN WordPress sor fölé tedd, mert azon belüli sorokat a WordPress felülírhatja.

.htaccess

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule (^|/)(readme\.html|debug\.log|\.env|wp-config\.php~)(/|$) - [F,L,NC]
</IfModule>

Ha egy almappában saját .htaccess van RewriteEngine sorral, az nem örökli ezeket a szabályokat, csak ha ott RewriteOptions Inherit is szerepel. Bedrocknál a webroot a web/ mappa legyen, akkor a .env nem érhető el.

WordPress

A hibanapló kikapcsolása éles oldalon a wp-config.php fájlban, a „That’s all, stop editing!” sor elé:

wp-config.php

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Ha a naplóra szükséged van, a WP_DEBUG_LOG értéke fájlútvonal is lehet, akkor a napló oda kerül. Válassz a nyilvános mappán kívüli útvonalat. Hibakeresésről lásd még: Hibakeresés WordPress-ben.

Hogyan ellenőrizd

1. Futtasd újra a riportot.
2. Nézd meg parancssorból, hogy a fájlok már nem adódnak ki (a kívánt eredmény 403 vagy 404), a pelda.hu helyére a saját címed kerül:

Terminál

curl -s -o /dev/null -w '%{http_code}\n' https://pelda.hu/readme.html
curl -s -o /dev/null -w '%{http_code}\n' https://pelda.hu/wp-content/debug.log
curl -s -o /dev/null -w '%{http_code}\n' https://pelda.hu/.env
curl -s -o /dev/null -w '%{http_code}\n' 'https://pelda.hu/wp-config.php~'

3. Bedrock-alapú oldalon a címek: /wp/readme.html, /app/debug.log; a wp-config.php~ a /wp/ alatt.
4. Ha az oldal előtt gyorsítótár van, az ellenőrzésnél egyszeri paramétert is fűzhetsz a címhez (például ?v=1), hogy ne egy korábbi, tárolt választ kapj.