Що може зловмисник, який отримав APP_KEY Laravel-застосунку?

APP_KEY часто сприймають як «ще одну змінну в .env», хоча його витік - один з найсерйозніших інцидентів для Laravel-застосунку.

Що дає ключ зловмиснику:

1. Розшифрування даних. Усе, що зашифровано Crypt чи кастами encrypted: токени сторонніх API, секрети 2FA, персональні дані - якщо зловмисник має й дамп бази.

2. Підробка cookie й сесій. Cookie Laravel шифруються й підписуються ключем. З ключем можна створити валідну зашифровану cookie з довільним вмістом. Наслідки залежать від конфігурації:

• з драйвером сесій cookie сесія повністю зберігається в cookie - зловмисник створює сесію будь-якого користувача;
• історично Laravel серіалізував вміст cookie, і підроблена cookie з об'єктом давала виконання коду на сервері через небезпечну десеріалізацію. У сучасних версіях cookie за замовчуванням не серіалізуються, але застосунки зі старими налаштуваннями чи сторонні механізми, що десеріалізують розшифровані дані, лишаються вразливими.

3. Підробка підписаних URL: підтвердження email для чужих адрес, «чарівні посилання» входу, одноразові посилання на файли, відписки - усе, що захищено signed.

4. Підробка даних сторонніх механізмів, що підписують дані ключем застосунку: наприклад, знімки стану Livewire - контрольна сума перестає захищати від зміни стану компонента.

Як ключі витікають:

• .env у репозиторії (включно з історією Git), у Docker-образі, в архіві бекапу;
• .env доступний з вебу через неправильний корінь вебсервера;
• ключ з прикладів і туторіалів, який скопіювали в продакшен;
• сторінка налагодження чи phpinfo() з змінними оточення;
• логи CI/CD, що вивели змінні оточення.

Реагування на витік:

1. новий APP_KEY; старий - не в APP_PREVIOUS_KEYS (інакше підроблені дані й далі розшифровуватимуться), тож свідомо прийняти, що всі сесії й посилання стануть недійсними;
2. перешифрувати дані в базі (потрібен старий ключ для читання - тимчасово в окремому скрипті);
3. завершити всі сесії, відкликати токени;
4. розслідувати, як ключ витік, і перевірити логи на ознаки використання;
5. ротувати й інші секрети з того самого .env - найімовірніше, витік не обмежився одним ключем.

Профілактика: секрети поза репозиторієм і образами (змінні оточення, менеджер секретів, env:encrypt), корінь вебсервера на public/, сканування репозиторіїв на секрети.

Докладніше в документації: Laravel: шифрування