Elavult PHP, WordPress és plugin-verziók

A kockázat nem elméleti

A nyilvános sebezhetőségekhez napokon belül kész eszköz tartozik. A botok nem válogatnak látogatószám szerint. Egy napi tíz látogatós céges oldal ugyanúgy célpont, mint egy nagy webshop.

A SEO-számla utólag jön

A feltört oldal első ránézésre rendben van. Jellemzően rejtett aloldalak kerülnek fel rá, idegen nyelvű kulcsszavakkal. A Google ezeket indexeli, a domain pedig megkapja a figyelmeztetést. Ez az index-szennyezés (spam-oldalak a Google-indexben), és a takarítása hetekbe telik.

Amit a látogató lát belőle

Ha a domain bekerül a Safe Browsing listára, a böngésző piros figyelmeztetést tesz az oldal elé. A forgalom nem lassan csökken, hanem egyik napról a másikra elfogy. A riportokban ezt látjuk a legfájdalmasabb végkifejletnek.

A frissítés ára csak nő

Minél régebbi a verzió, annál nagyobb a szakadék. Két minor verziót fél óra átugrani. Öt év lemaradást már csak újraépítéssel lehet behozni.

Vonatkozik rád, ha

• saját tárhelyen futó rendszered van: WordPress, Joomla, Drupal, egyedi PHP-alkalmazás
• külső fejlesztőtől származó bővítmény, sablon vagy modul fut az oldalon
• a tárhelyen régi teszt-példány, archív telepítés vagy bemutató-aloldal is maradt

A staging és az elfelejtett teszt-telepítés a legveszélyesebb. Ezeket senki nem frissíti, viszont ugyanarról a szerverről elérhetők. Egy sérülékeny aloldal az egész fiókot elviheti.

Kevésbé vonatkozik rád, ha

Zárt SaaS-en dolgozol: Shopify, Unas, Shoprenter. Ott a rendszermag verziója a szolgáltató felelőssége. A saját sablonkódod, a beillesztett szkriptjeid és a telepített alkalmazásaid viszont maradnak nálad.

1. Nyisd meg a böngésző devtools Network fülét, és töltsd újra az oldalt. Kattints az első dokumentum-kérésre.
2. A Response Headers alatt keresd a Server és az X-Powered-By sort. Jegyezd fel, ha verziószám van bennük.
3. Nézd meg a forráskódot (Ctrl+U), és keress rá a generator szóra.
4. WordPress esetén próbáld meg a /readme.html és a /wp-json/ címet is.
5. Admin felületen nyisd meg a Vezérlőpult > Állapot > Információ oldalt. Itt látod a PHP-, az adatbázis- és a szerververziót.
6. Vesd össze a talált verziót a gyártó életciklus-táblázatával. PHP-nál ez a php.net/supported-versions oldal.

Jó jel

• a PHP-ág aktív vagy biztonsági támogatás alatt áll
• a CMS a legfrissebb minor verzión fut
• nincs olyan bővítmény, amelyhez 12 hónapja nem jelent meg frissítés
• a Site Health nem ír verzió-figyelmeztetést

Rossz jel

• X-Powered-By: PHP/7.4.33 vagy bármilyen 8.0 alatti ág
• több tucat függőben lévő frissítés az adminban
• olyan bővítmény, amit a hivatalos tárolóból már eltávolítottak
• a szerver saját verziója is régi, nem csak a CMS-é

A riportokban ezt látjuk a leggyakrabban: a CMS friss, a PHP viszont évek óta ugyanaz.

WordPress

1. Készíts teljes mentést, fájl és adatbázis szinten. Próbáld ki, hogy a visszatöltés is működik.
2. Másold az oldalt staging környezetbe. A legtöbb tárhelynél ez egy kattintás.
3. Frissítsd előbb a bővítményeket és a sablont, csak utána a rendszermagot. Általában a régi plugin hasal el az új PHP-n.
4. Állítsd át a PHP-verziót a tárhely vezérlőpultjában a támogatott ágra, és teszteld staging-en.
5. Kapcsold be a minor rendszermag-frissítések automatikus telepítését.
6. Élesítés után járd végig a kritikus útvonalakat: belépés, űrlap, kosár, fizetés.

Shopify

1. A platform verzióját a szolgáltató kezeli, azzal nincs dolgod.
2. Nézd át a telepített alkalmazásokat, és távolítsd el a nem használtakat.
3. Frissítsd a sablon verzióját, majd told át rá az egyedi módosításaidat.

Unas

1. A rendszermagot a szolgáltató frissíti, ez a saját felületén követhető.
2. Ellenőrizd a beillesztett külső szkripteket, és cseréld a régi könyvtár-verziókat.
3. Töröld a már nem használt sablonváltozatokat és tesztoldalakat.

Shoprenter

1. A platformverzió szintén szolgáltatói oldalon frissül.
2. Vizsgáld felül az aktív alkalmazásokat és a saját sablonmódosításokat.
3. A régi API-kulcsokat és integrációkat vond vissza, ha már nem élnek.

Egyedi fejlesztés

1. Futtass composer outdated és npm audit parancsot, és nézd végig a kritikus találatokat.
2. Emeld a PHP-verziót a Dockerfile-ban vagy a szerver konfigjában, és futtasd le a tesztkészletet.
3. Tervezz negyedéves frissítési ablakot. A magyar KKV-oldalak többségén ez a rutin hiányzik.
4. Tedd a függőség-ellenőrzést a CI-be, hogy ne emlékezetből menjen.

• A verziószám elrejtése javításnak számít. A fejléc kitakarása nem foltozza be a hibát, a szkenner más ujjlenyomatból is felismeri a rendszert.
• Csak a CMS frissül, a PHP nem. A tárhely vezérlőpultjában egy legördülő menü dönt, és évekig senki nem nyúl hozzá.
• Deaktivált bővítmény a fájlrendszerben marad. A kikapcsolt plugin kódja sok esetben továbbra is elérhető HTTP-n keresztül.
• Automatikus frissítés mentés és staging nélkül. Egy eltört fizetési folyamat drágább, mint a fél óra előkészület.
• Elfelejtett teszt- és archív telepítések. A /regi/ vagy /test/ mappában futó ősrégi példány ugyanarról a fiókról elérhető.
• Nulled vagy kalózverziós sablon. Ezekhez sosem jön frissítés, ráadásul gyakran már telepítéskor tartalmaznak hátsó kaput.
• A frissítés egyszeri projekt, nem folyamat. Fél év múlva ugyanott vagy, ahonnan indultál.

Először nézd meg, mit árul el az oldal magáról kívülről:

# HTTP-fejlécek és a generator meta tag
curl -sI https://pelda.hu | grep -iE "^server|^x-powered-by"
curl -s https://pelda.hu | grep -i "name=\"generator\""

Egy elavult telepítés jellemző válasza:

Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.4.33
<meta name="generator" content="WordPress 5.8.2" />

Ez a három sor együtt pontos célzást ad egy támadónak. WP-CLI-vel a szerveren belülről is gyorsan leltárt csinálhatsz:

php -v
wp core check-update
wp plugin list --update=available --fields=name,version,update_version

A wp plugin list kimenetében minden sor egy nyitott kockázat, amíg nem frissíted.