Livewire 4.4.8, що вийшов 21 жовтня, закриває вразливість GHSA-mhf7-xp6r-6qrc: атрибут #[Authorize] можна було обійти, і користувач міг виконати захищену дію над записом, на який не має прав. Оцінка CVSS - 6.5, серйозність середня. Того ж тижня NativePHP опублікувала свої перші попередження безпеки - одразу сім для NativePHP for Mobile. Обидва випадки не критичні, але в обох є що зробити вже сьогодні.
Що не так з #[Authorize] у Livewire
Атрибут #[Authorize] з'явився в Livewire 4.3 і швидко став зручною заміною ручному $this->authorize(): політику вказуєш над методом, а не першим рядком у ньому. Саме ця частина й виявилася вразливою. Попередження описує три проблеми:
- Переставлені ключі параметрів дії.
#[Authorize] знаходив модель-параметр за ключем масиву, а сама дія отримувала параметри позиційно. Запит, що передає параметри об'єктом із переставленими цілими ключами (на кшталт {"1": 2, "0": 1}), проходив перевірку зі «своїм» записом, а дія отримувала інший.
- Те саме для слухачів подій. Методи з
#[On] і #[Authorize], що приймають модель, були вразливі так само - через виклик __dispatch.
- Методи з
#[Json] виконувалися до авторизації. Відповідь приходила з кодом 403, але побічні ефекти, як-от записи в базу даних, уже відбулися.
Типовий вразливий метод виглядає цілком безневинно:
use Livewire\Attributes\Authorize;
#[Authorize('delete', 'comment')]
public function deleteComment(Comment $comment)
{
$comment->delete();
}
До 4.4.8 у такому методі користувач міг видалити чужий коментар.
Хто вразливий
- Livewire від 4.3.0 до 4.4.7 включно.
- Лише застосунки, що використовують
#[Authorize]: на методах із параметрами-моделями (перші дві проблеми) або на методах з #[Json] (третя).
- Livewire 3.x не зачеплено.
- Авторизацію всередині методу через
$this->authorize(...) не зачеплено.
Вразливість знайшов і повідомив Yousef Aman.
Що робити
Оновіться до 4.4.8:
composer update livewire/livewire
Після оновлення параметри виклику дії чи події мають бути списком або мати рядкові ключі - інакше запит відхиляється. Методи з #[Json] тепер авторизуються до виконання.
Якщо оновитися прямо зараз не можна, перенесіть перевірку всередину методу:
public function deleteComment(Comment $comment)
{
$this->authorize('delete', $comment);
$comment->delete();
}
Так перевіряється саме той запис, з яким працюватиме дія. Коли оновитеся, можна повернути атрибут.
NativePHP for Mobile: сім попереджень
NativePHP опублікувала свої перші попередження безпеки - сім для NativePHP for Mobile (огляд на Laravel News). Виправлення - в nativephp/mobile 4.6.1 і 3.3.11 та в плагіні nativephp/mobile-file 1.0.3.
Більшість проблем походять із внутрішніх маршрутів /_native/api/*, через які web view спілкується з нативною частиною: на них не було жодного middleware, а частина функцій мосту приймала вхідні дані без перевірок. Для більшості атак зловмисникові вже потрібен JavaScript, що виконується у web view застосунку: XSS або скомпрометований сторонній скрипт.
| Попередження |
Серйозність |
Суть |
Виправлено в |
| GHSA-9884-fw9c-mq85 |
High, 8.1 |
ін'єкція коду через ідентифікатор асинхронного завдання (4.5.0+) |
4.6.1 |
| GHSA-83jv-8h7x-287p |
High, 7.7 |
/_native/api/events створював об'єкт будь-якого класу з запиту |
4.6.1, 3.3.11 |
| GHSA-3w4w-cchh-qvrw |
High, 7.7 |
File.Move і File.Copy приймали будь-який шлях у пісочниці |
4.6.1 |
| GHSA-7927-vv5p-fv4f |
High, 7.7 |
те саме в плагіні mobile-file |
1.0.3 |
| GHSA-9g37-88p8-75j2 |
High, 7.4 |
unserialize() даних асинхронних завдань без автентифікації (4.5.0+) |
4.6.1 |
| GHSA-76px-r497-93p9 |
Medium, 5.9 |
обхід шляху в /_assets: читання файлів поза public/, зокрема бази SQLite |
4.6.1, 3.3.11 |
| GHSA-27jx-7m9x-fx5c |
Medium, 4.1 |
Android-збірки писали сесійну cookie і XSRF-токен у logcat |
4.6.1, 3.3.11 |
Дві зміни можуть вплинути на поведінку застосунку. Події, які відправляють через /_native/api/events, тепер мають реалізовувати інтерфейс Native\Mobile\Events\Contracts\DispatchableFromNative - це стосується авторів плагінів із власними подіями. А дані асинхронних завдань тепер шифруються ключем застосунку, тож без APP_KEY асинхронні завдання не запускаються.
Мобільний застосунок треба перезібрати
Тут головна відмінність від звичайного вебзастосунку: composer update нікого не захищає. Частина виправлень - у нативному коді Swift, Kotlin і C, який генерується в проєкт застосунку, і до користувачів він дійде лише з новою збіркою. Порядок дій:
- Оновіть
nativephp/mobile до 4.6.1 (на гілці 3.x - до 3.3.11).
- На 4.x видаліть плагін
nativephp/mobile-file: ядро має власні, вже обмежені File.Move і File.Copy, а плагін може їх перекрити й повернути вразливість. На 3.x оновіть плагін до 1.0.3.
- Перегенеруйте нативний проєкт командою
php artisan native:install --force і перезберіть застосунок.
- Відправте нову збірку в App Store і Google Play. Доки користувачі її не встановлять, вони вразливі.
Версії 1.x і 2.x більше не підтримуються і виправлень не отримають - команда радить переходити на 4.x.
Є й друга причина перезібрати застосунок: NativePHP везе всередині власну копію PHP. Після критичних релізів PHP 21 жовтня команда перезібрала всі бінарники PHP, які розповсюджує, на 8.5.12, 8.4.27 і 8.3.36, але у ваш застосунок вони потраплять тим самим шляхом: оновлення, native:install --force, нова збірка, реліз.
Наостанок
Не варто перебільшувати масштаб: Livewire - це середня серйозність і лише застосунки з #[Authorize] на конкретних методах, NativePHP - здебільшого атаки, яким уже потрібен чужий JavaScript у web view. Але обидва виправлення дешеві.
Для Livewire пошукайте в проєкті #[Authorize] - якщо знайшлося, оновлення до 4.4.8 стоїть першим у черзі. Для NativePHP закладіть у план не лише оновлення пакета, а й цикл перевірки в магазинах застосунків: від composer update до захищених користувачів тут минають дні, а не хвилини. І заразом перевірте, які сторонні скрипти завантажує ваш web view - більшість цих атак починається саме звідти.
