Egy hét, ami mindent megváltoztatott

Tavaly ősszel három különböző magyar webtárhely szolgáltató is bejelentette, hogy kritikus biztonsági hibát találtak a feltöltési rendszerükben. Nem véletlenül kerültek egyszerre a címlapokra – mind a három eset ugyanaz a gyökérok állt a háttérben.

Ez nem újdonság a szakmában. Évek óta ismert probléma, mégis újra és újra felbukkan. A következmények pedig súlyosak: milliós károk, ügyfélvesztés, jogi felelősség.

Mi a "validation by shortcut"?

A fejlesztőknek sokszor gyorsan kell dolgozniuk. Egy fájlfeltöltés megvalósításánál a legegyszerűbb út gyakran azt jelenti, hogy:

• megnézzük, megfelelő-e a fájl kiterjesztése
• ellenőrizzük a MIME típust
• megnézzük, nem túl nagy-e a méret

Ezek önmagukban nem rossz ellenőrzések. A baj az, hogy sokan itt megállnak – és ez óriási hiba.

A "validation by shortcut" lényege: elvégezzük a minimális ellenőrzést, majd feltételezzük, hogy a fájl biztonságos. Olyan ez, mintha egy csomagot anélkül nyitnál ki, hogy alaposan megnéznéed a tartalmát.

A sebezhetőség anatómiája

Az ominózus héten felfedezett hibák mind ugyanazt a mintát követték:

1. Hiányos kiterjesztés-ellenőrzés: A rendszerek engedték a dupla kiterjesztéseket (.php.jpg) és az ismeretlenebb végződéseket (.phtml, .phar)

2. Tartalomvizsgálat hiánya: A fájl tényleges tartalmát senki nem vizsgálta. Így polyglot fájlok – amelyek képenek tűnnek, de kódot tartalmaznak – gond nélkül feljutottak a szerverekre

3. Rossz tárolási hely: A feltöltött fájlok a web gyökérkönyvtárában landoltak, ahol bárki elérhette őket

4. Nincs futtatási védelem: A szerver konfigurációja nem akadályozta meg az исполнение fájlok futtatását

Együttesen ezek a hiányosságok azt jelentették, hogy bárki – autentikáció nélkül – tetszőleges kódot tölthetett fel és futtathatott a szervereken.

Miért térünk vissza ehhez a hibához?

Időnyomás: A prod környezet gyorsaságot követel. A teljes validáció luxusnak tűnik, főleg ha "a tesztben működött a kiterjesztés-ellenőrzés."

Hamis biztonságérzet: A tesztkörnyezet tiszta fájlokat használ. Minden zöld, megy ki a kód – aztán az élesben szétesik.

Tudáshiány: Nem minden fejlesztő kapott biztonsági képzést. Nem tudják, mennyire kreatívan tudnak támadók fájlokat manipulálni.

Feltételezett védelem: A csapatok néha bíznak benne, hogy "majd a WAF megfogja" vagy "a szerverhardvering elegendő." Ez veszélyes naivitás.

Így kell jól csinálni

A biztonságos fájlfeltöltés védelmet igényel rétegekből. Nem elég egyetlen fal – kell a várfal is.

1. Tartalom alapján ellenőrizz, ne kiterjesztésből

# Rossz megoldás – megbízik a felhasználóban
if file.filename.endswith('.jpg'):
    save_file(file)

# Jobb megközelítés – valódi tartalmat vizsgál
import magic

mime_type = magic.from_buffer(file.read(1024), mime=True)
file.seek(0)

if mime_type in ALLOWED_MIME_TYPES:
    save_file(file)

A python-magic vagy a libmagic könyvtárak megmondják, mi van a fájlban – nem azt, amit a fájlnév sugall.

2. Újranevezés és szanitizáció

Soha ne használd az eredeti fájlnevet. Generálj teljesen újat:

import uuid
import os

secure_filename = f"{uuid.uuid4().hex}.{allowed_extension}"
filepath = os.path.join(UPLOAD_DIR, secure_filename)

3. Tárolás a web gyökéren kívül

Ha fontos az alkalmazás, ez nem opcionális. Ha a fájlokat szolgáltatni kell, használj letöltési scriptet, ami ellenőrzi a jogosultságot és nem árulja el a valódi elérési utat.

4. Szerveroldali futtatás tiltása

# Apache - tiltás az uploads könyvtárban
<Directory "/var/www/uploads">
    <FilesMatch "\.(php|phtml|phar|py|pl|exe)$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>

5. További védelmi rétegek

• Magic bytes ellenőrzés: vizsgáld a fájl első bájtjait
• Képek újrakódolása: futtasd át őket imagemagick-en, így eltűnik minden beágyazott kód
• Méretkorlátok: ne csak a fájlméret, hanem a dimenziók is számítsanak
• Rate limiting: ne engedd a gyors egymásutánban történő feltöltéseket

Az emberi oldal

A hibák mögött nem csak technikai számok állnak:

• Ügyfelek, akiknek az adata kikerült
• Vállalkozások, amelyek bírságot és pert kaptak
• Fejlesztők, akiknek a karrierjét ez ahol elrontotta
• Felhasználók, akik bíztak egy szolgáltatásban

A biztonság nem feature – hanem felelősség.

Mit tehetnek a szolgáltatók?

Ha hosting platformot üzemeltetsz vagy fájlfeltöltési rendszert építesz:

1. Vizsgáld át a meglévő kódot – hol spóroltak a validáción?
2. Implementálj tartalom-alapú típusellenőrzést
3. Vidd ki a fájlokat a web-elérhető könyvtárból
4. Tegyél fel WAF szabályokat plusz védelemként
5. Készíts incident response tervet – nem az a kérdés, hogy lesz-e baj, hanem hogy mikor
6. Fektess a biztonsági képzésbe – a csapat a legjobb befektetés

Záró gondolatok

A tavalyi héten felfedezett hibák nem kifinomult támadások vagy ismeretlen zero-dayek voltak. Egyszerűen csak fejlesztési sietség és spórolás az ellenőrzéseken.

Ez tulajdonképpen jó hír: a javítások elérhetők. Nem kell újraírni a biztonságot – csak komolyan kell venni.

A kérdés nem az, hogy tesztelni fogják-e az alkalmazásod. Az a kérdés, hogy megállod-e a helyzet, amikor eljön az idő.

Szánj időt a rendes validációra. A felhasználóid számítanak rá.