# Helyreállítás a 2026-09-16-i incidens után

## Mit javít ez a változás?

- A Backpack csak `admin` vagy `super-admin` szerepkörrel érhető el. A szerepkör nélküli vásárló 403 választ kap, a vendég a belépéshez kerül.
- A `UserSeeder` csak local/testing környezetben futtatható. Élesen korábban törölhette volna a felhasználókat és ismert jelszavakat állított volna be.
- Apache alatt a public/.htaccess tiltja a közvetlen scriptelérést a gyökér index.php kivételével, továbbá a rejtett fájlokat (az ACME .well-known kivételével). Ez a régi sablonok önálló PHP-végpontjait is letiltja; a Laravel útvonalain működő kapcsolatfelvétel megmarad.
- Nincs adatbázis-migráció. A vásárlói regisztráció megmarad.
- A Telescope alkalmazásprovider csak helyi környezetben és telepített Telescope mellett töltődik be, így a fejlesztői függőségek nélküli éles kiadás is elindulhat.
- Eltávolítottuk a nem használt `laravel-lang/lang` függőséget; a fordítások továbbra is a resources/lang könyvtárban vannak. A Composer a rögzített 7.0.9 verzió telepítését malware-jelzés miatt blokkolta. Ez nem bizonyít kapcsolatot a jQuery-incidenssel. Forrás: https://packagist.org/packages/laravel-lang/lang/filter-lists/malware/

Ez nem teljes kártevő-eltávolítás: az éles fájlokat, naplókat és adatbázist helyben nem vizsgáltuk.

Helyi ellenőrzés: 9 célzott PHPUnit-teszt / 14 assertion sikeres, beleértve a tényleges admin dashboard és elFinder elutasítását normál felhasználóval. Elkülönített Apache alatt az index.php, kép és ACME-próbafájl 200, a PHP/PHTML feltöltés, nagybetűs PHP, PHP path-info és .env 403 választ adott. A fejlesztői csomagok nélküli alkalmazás elindult. A teszt PHP 8.2-es konténerben futott; az öreg függőségek telepítésénél csak ebben az elkülönített tesztmásolatban kellett figyelmen kívül hagyni a PHP-verziókorlátot. Ez nem teljes alkalmazás-kompatibilitási vizsgálat, éles telepítésnél a platformellenőrzést meg kell tartani.

## 1. Lezárás és bizonyítékmentés

A tárhelyszolgáltatóval állítsd le az éles ÉS a test webhely külső kiszolgálását, a statikus fájlokat is beleértve. A `php artisan down` a fertőzött JavaScript elérését önmagában nem tiltja.

Mentsék a teljes tárhelyet, adatbázist, hozzáférési naplókat, cronbejegyzéseket, fájlidőpontokat és a két fertőzött fájlt weben nem elérhető helyre. A mentés fertőzött bizonyíték, nem tiszta visszaállítási alap. Exportáld a users ID=10 rekordját és kapcsolódó szerepköreit, jogosultságait is.

Vizsgálják át a teljes tárhelyfiókot: plusz PHP-fájlok, .user.ini, .htaccess, auto_prepend_file, cronfeladatok, uploads, storage, régi tesztpéldányok. Ellenőrizzék az új és módosult felhasználókat/szerepköröket. A 10-es fiók nem feltétlenül az egyetlen idegen hozzáférés.

## 2. Tiszta alkalmazás és konfiguráció

A forrásból ellenőrzött alkalmazást telepítsd. A felülmásolás önmagában nem törli a támadó által hozzáadott fájlokat. Az ismeretlen fájlokat a szolgáltató vizsgálja meg; feltöltéseket ne törölj vakon.

A módosított composer.json és composer.lock is a kiadás része. Tiszta kiadási könyvtárban, az élesen használt PHP-val építsd újra a függőségeket (ne kapcsold ki a Composer malware- vagy platformellenőrzését):

```bash
composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction
composer audit --locked --no-dev
```

Az audit jelenleg további ismert sérülékenységeket jelez; ez a gyorsjavítás nem oldja meg a teljes régi függőségállomány frissítését. Auditelt, támogatott verziókra történő átállás külön feladat. A régi vendor könyvtárat ne emeld át az új kiadásba. Ha a telepítés hibát ad, ne kerüld meg a védelmeket; az új kiadást ne aktiváld.

Mindkét érintett webhelyen cseréld a public/assets/js/jquery-2.2.4.min.js fájlt az ellenőrzött helyi példányra. Annak SHA-256 értéke:

```text
05b85d96f41fff14d8f608dad03ab71e2c1017c2da0914d7c59291bad7a54f8e
```

A szerveren ellenőrizd:

```bash
cd /home/rubandroll/public_html/rubandroll
sha256sum public/assets/js/jquery-2.2.4.min.js
```

A test példányban is ugyanezt végezd el, vagy maradjon lekapcsolva. A rejtett public/.htaccess fájlt is telepítsd.

Az éles .env meglévő értékeit módosítsd (ne készíts duplikált kulcsokat):

```dotenv
APP_ENV=production
APP_DEBUG=false
API_DEBUG=false
BACKPACK_REGISTRATION_OPEN=false
SESSION_SECURE_COOKIE=true
```

Az utolsó beállítás HTTPS-t igényel. A Backpack-regisztráció tiltása nem tiltja a vásárlói regisztrációt; az admin-hozzáférést a szerepkörellenőrzés védi.

A következő parancsokat csak a megtisztított alkalmazásban futtasd:

```bash
php artisan down
php artisan config:clear
php artisan route:clear
php artisan view:clear
```

## 3. Valódi admin hozzáférése és idegen fiók eltávolítása

Nyisd meg a Tinkert:

```bash
php artisan tinker
```

Először listázd a meglévő szerepköröket, és ellenőrizd a saját fiókodat. A képen szereplő ID=1/email párost használjuk; eltérésnél a firstOrFail leáll, ne cseréld le ellenőrzés nélkül másik felhasználóra.

```php
App\Models\User::with('roles')->get()->map(fn ($u) => ['id' => $u->id, 'email' => $u->email, 'roles' => $u->roles->pluck('name')->all()])->all();
$owner = App\Models\User::where('id', 1)->where('email', 'papiirka@gmail.com')->firstOrFail();
Spatie\Permission\Models\Role::findOrCreate('super-admin', 'web');
$owner->assignRole('super-admin');
```

Csak bizonyítottan jogos munkatársaknak adj admin szerepkört. A meglévő demo fiókot is vizsgáld felül. Az adminok jelszavát cseréld erős, egyedi jelszóra, mert a régi seeder ismert jelszavakat tartalmazott.

A bizonyítékmentés UTÁN az általad idegenként azonosított fiók törlése (az ID és email együttesen kötelező):

```php
$intruder = App\Models\User::where('id', 10)->where('email', 'okanbilgi35s@gmail.com')->firstOrFail();
Illuminate\Support\Facades\DB::transaction(function () use ($intruder) {
    $intruder->syncRoles([]);
    $intruder->syncPermissions([]);
    $intruder->delete();
});
```

Ha idegen kulcs miatt sikertelen a törlés, ne kapcsold ki az adatbázis integritásellenőrzését: a kapcsolódó rekordokat külön fel kell tárni. A webhely addig maradjon lezárva.

## 4. Minden bejelentkezés visszavonása

Ez minden felhasználót kijelentkeztet, és a munkamenetben tárolt kosarak is elveszhetnek. Továbbra is Tinkerben:

```php
App\Models\User::query()->update(['remember_token' => null]);
app(Spatie\Permission\PermissionRegistrar::class)->forgetCachedPermissions();
config('session.driver');
```

Ha a kapott érték `file`, futtasd:

```php
foreach (glob(config('session.files').'/*') as $file) {
    if (is_file($file) && preg_match('/^[A-Za-z0-9]{40}$/', basename($file))) {
        if (!unlink($file)) { throw new RuntimeException('Session deletion failed'); }
    }
}
```

Ha `database`, a konfigurált sessiontáblát ürítsd:

```php
Illuminate\Support\Facades\DB::connection(config('session.connection'))->table(config('session.table', 'sessions'))->delete();
```

Redis, cookie vagy más driver esetén ne használd ezeket helyettesítőként: a szolgáltatóval a tényleges sessiontárat kell érvényteleníteni. A cookie nevének átírása önmagában nem vonja vissza a szerveren meglévő sessionöket. Redis esetén ne futtass közös adatbázison FLUSHALL-t. Az API-tokeneket, ha vannak, külön vissza kell vonni.

Lépj ki a Tinkerből (`exit`), majd:

```bash
php artisan config:cache
php artisan view:clear
```

## 5. Tárhelyvédelem és visszanyitás

- A document root az alkalmazás public könyvtára legyen. Az .env, vendor, storage/logs és mentések ne legyenek közvetlenül elérhetők.
- A PHP/webfolyamat ne írhassa az alkalmazáskódot, .htaccess-t és a JavaScript-fájlokat. Csak a szükséges storage, bootstrap/cache és feltöltési területek legyenek írhatók. A chmod 644 önmagában nem véd, ha a PHP a fájl tulajdonosaként fut; tulajdonosi elkülönítés kell.
- Feltöltési területeken szerverkonfigurációból tiltsák a scriptfuttatást és a helyi konfigurációs felülbírálást. Az alkalmazás .htaccess-e kiegészítő védelem, nem helyettesíti ezt. Nginx nem olvassa a .htaccess-t; ott külön konfiguráció kell.
- Cseréld a tárhely-, FTP/SFTP/SSH-, admin-, adatbázis- és az esetleg olvasható .env szolgáltatási hozzáféréseit. Az APP_KEY-t ne cseréld vakon: meglévő titkosított adatok elveszhetnek.
- Külön felhasználó/jogosultság alá kerüljön az éles és tesztpéldány. Kérj új teljes szkennelést és fájlváltozás-figyelést.
- A szolgáltató ürítse a CDN/proxy gyorsítótárat és indítsa újra a PHP-folyamatokat az OPcache frissítéséhez.

Szolgáltatói IP-korlátozás mellett, a karbantartási mód feloldása után ellenőrizd:

```bash
php artisan up
```

- Saját admin be tud lépni.
- Új normál felhasználó nem fér hozzá az adminhoz és az admin/elfinder felülethez (403).
- A gyanús fiók nem tud belépni, a régi munkamenetek nem működnek.
- Az index.php és a normál oldalak működnek; más közvetlen PHP-elérés 403/404. A feltöltési területben egy ártalmatlan próba-PHP-t sem szabad végrehajtani; a próbafájlt utána töröljék.
- Kapcsolati űrlap, képek, PDF-ek és admin médiakezelés működnek.
- A kiszolgált jQuery hash-e is a fenti érték, és az ismételt szkennelés tiszta.

Csak ezután oldják fel a külső hozzáférés korlátozását. Hiba esetén maradjon lezárva; ne állítsd vissza a mindenkit beengedő adminellenőrzést.

Ne futtass `migrate:fresh`, `db:seed`, `key:generate` vagy általános `composer update` parancsot élesen. A keretrendszer és függőségek frissítése külön, tesztelt kiadást igényel.