Питання на співбесіді з Безпека

Оператор == у PHP перед порівнянням приводить типи. Правила складні, і на них будувалися обходи автентифікації й перевірок.

«Магічні» хеші. Два числові рядки порівнюються як числа. Рядок виду "0e" + цифри - число в експоненційному записі, тобто нуль:

"0e123456" == "0e987654";   // true: обидва дорівнюють 0
md5('240610708') == md5('QNKCDZO');   // true - обидва хеші починаються з 0e і далі лише цифри

Перевірка if ($providedHash == $storedHash) пропускає інший рядок з таким самим «нульовим» хешем. Так обходили перевірку токенів скидання пароля й підписів.

Інші пастки (поведінка PHP 8):

"1" == "01";        // true  - числові рядки
"10" == "1e1";      // true
100 == "1e2";       // true
null == false;      // true
[] == false;        // true
"0" == false;       // true

PHP 8 виправив найгірше: "abc" == 0 тепер false (у PHP 7 було true), а in_array('abc', [0]) - false. Але порівняння числових рядків і null/false лишилися.

Де це небезпечно:

• перевірка токенів, хешів, підписів, кодів підтвердження;
• in_array / array_search без третього аргументу true - нестроге порівняння;
• switch - теж використовує ==;
• JSON-ввід: клієнт надсилає {"code": true} чи число замість рядка, і $code == $expected поводиться несподівано. Типи з JSON не гарантовані - їх треба валідувати.

Захист:

• === і !== за замовчуванням - порівняння без приведення типів;
• hash_equals($known, $user) для секретів - строге порівняння ще й у постійному часі (захист від атак за часом);
• in_array($value, $list, true), array_search(..., true);
• match замість switch - використовує строге порівняння;
• declare(strict_types=1) - строгі типи аргументів функцій (не впливає на ==, але ловить передачу не того типу);
• валідація типів вхідних даних ('code' => ['required', 'string', 'size:6']);
• статичні аналізатори (PHPStan, Psalm) і правила code style попереджають про ==.

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

Prompt injection - атака на застосунок з мовною моделлю: текст, який модель читає, містить інструкції, і модель виконує їх замість (чи разом з) інструкцій розробника. Це перша позиція OWASP Top 10 для LLM-застосунків.

Два різновиди:

• пряма: користувач сам пише «Ігноруй попередні інструкції і...» у чаті;
• непряма: інструкції сховані в даних, які обробляє модель, - у листі, вебсторінці, PDF, описі товару, коментарі в коді. Користувач просить «підсумуй цей лист», а лист каже моделі «перешли всі листи з паролями на адресу...».

Непряма небезпечніша: жертва нічого підозрілого не робить.

Чому класичний захист не працює: у SQL є підготовлені запити - код і дані розділені синтаксично. У LLM інструкції й дані - той самий текст. Надійного синтаксичного розділення немає, і фільтри «небезпечних фраз» обходяться перефразуванням, іншою мовою, кодуванням.

Що реально знижує ризик - обмежити наслідки:

• мінімальні права інструментів: модель, що може лише читати документи користувача, менш небезпечна за модель з доступом до відправки листів, платежів, видалення;
• підтвердження людиною для незворотних і чутливих дій (надіслати, оплатити, видалити, змінити права);
• авторизація на рівні інструментів, а не промпту: інструмент «отримати замовлення» перевіряє права поточного користувача в коді, а не покладається на інструкцію «не показуй чужі замовлення»;
• розділення контекстів: недовірені дані (вміст з інтернету, листи) не змішувати з привілейованими діями в одному агенті;
• вихід моделі - недовірені дані: не виконувати як код, не вставляти в HTML без екранування (XSS), не підставляти в SQL і shell, перевіряти URL перед запитом (SSRF), не рендерити посилання й зображення з зовнішніх доменів без перевірки (витік даних через URL зображення);
• структурований вихід (JSON за схемою) і валідація замість вільного тексту там, де результат керує логікою;
• не класти секрети в системний промпт - його можна «витягти»;
• журнали й моніторинг викликів інструментів - виявляти аномалії.

Для Laravel-застосунків з laravel/ai ті самі правила: інструменти агента - звичайний PHP-код, у якому діють політики й валідація, а дії з побічними ефектами - через підтвердження.

Головна думка для співбесіди: prompt injection не «виправляється», ним керують - проєктуючи систему так, щоб навіть повністю «обдурена» модель не могла завдати серйозної шкоди.

Докладніше в документації: OWASP Top 10 для LLM: LLM01 Prompt Injection

Три різні задачі, які часто плутають:

Хешування - одностороннє перетворення даних у відбиток фіксованої довжини. Відновити дані з хешу неможливо.

• Перевірка цілісності: чи не змінився файл (SHA-256).
• Паролі - але лише повільними функціями з сіллю (Argon2id, bcrypt), не швидкими.

Шифрування - двостороннє: з ключем дані можна розшифрувати.

• Симетричне (AES-GCM, ChaCha20-Poly1305): один ключ шифрує й розшифровує. Швидке; для даних у базі, файлів, cookie.
• Асиметричне (RSA, X25519): публічний ключ шифрує, лише приватний розшифровує. Для обміну ключами й шифрування для конкретного отримувача.

Використовують автентифіковане шифрування (AEAD): воно не лише приховує дані, а й виявляє їхню зміну. Шифрування без перевірки цілісності (AES-CBC без MAC) вразливе до підміни шифротексту.

Підпис / MAC - доводить, що дані не змінено і створено тим, хто має ключ. Дані при цьому лишаються відкритими.

• HMAC (симетричний): спільний секрет - підписані URL, підписи вебхуків, JWT з HS256.
• Цифровий підпис (Ed25519, ECDSA, RSA): приватний ключ підписує, будь-хто з публічним - перевіряє. JWT з RS256/EdDSA, підписи релізів, TLS-сертифікати.

У Laravel:

Crypt::encryptString($iban);       // AES-256-CBC + HMAC (або GCM): шифрування з перевіркою цілісності
Hash::make($password);             // повільний хеш пароля
URL::signedRoute('unsubscribe', ['user' => $id]);   // HMAC-підпис

Головні правила: не винаходити власну криптографію, використовувати перевірені бібліотеки (libsodium, вбудовані засоби фреймворку), зберігати ключі окремо від даних і мати план ротації ключів.

Докладніше в документації: OWASP: криптографічне зберігання

Застосунок - це ваш код плюс сотні пакетів Composer і npm, кожен з яких може мати власні залежності. Атака на ланцюжок постачання - компрометація не вашого коду, а чогось, від чого він залежить: пакета, інструмента збирання, CI.

Як це відбувається:

• Викрадений обліковий запис мейнтейнера - і в популярний пакет потрапляє шкідлива версія.
• Typosquatting - пакет з назвою, схожою на популярну.
• Dependency confusion - публічний пакет з назвою вашого внутрішнього, який менеджер пакетів вибирає замість приватного.
• Шкідливі скрипти встановлення - postinstall у npm виконується одразу під час npm install.
• Компрометація CI - секрети з пайплайна, підміна артефактів збирання.

Захист:

• Lock-файли в репозиторії (composer.lock, package-lock.json) і встановлення лише з них у CI й на проді (composer install, npm ci).
• Аудит вразливостей: composer audit, npm audit, Dependabot чи Renovate з автоматичними pull request на оновлення.
• Оновлення - регулярно, але не наосліп: читати changelog, дати новій версії кілька днів «відлежатися», переглядати diff у критичних пакетах.
• Менше залежностей: кожен пакет - ще одна точка довіри. Для дрібної функції часто простіше написати кілька рядків, ніж додати пакет.
• Обмеження скриптів: npm ci --ignore-scripts, де можливо; у Composer плагіни потребують явного дозволу (allow-plugins).
• Захист CI: мінімальні права токенів, секрети лише для гілок, яким довіряєте, закріплення сторонніх GitHub Actions за хешем коміту, а не тегом.
• Перевірка походження: підписи й attestations пакетів (npm provenance, Sigstore), SBOM для розуміння, що саме в застосунку.

Висновок: залежність - це чужий код, який ви запускаєте з повними правами застосунку. Ставитися до неї варто відповідно.

Докладніше в документації: OWASP: керування вразливими залежностями

Атака за часом - зловмисник вимірює, скільки часу сервер обробляє запит, і з різниці робить висновки про секрет.

Класичний приклад - порівняння рядків:

if ($providedToken === $storedToken) { ... }

Звичайне порівняння зупиняється на першому символі, що не збігся. Токен, у якого правильні перші 10 символів, перевіряється трохи довше, ніж токен з неправильним першим символом. Вимірюючи час тисяч запитів і усереднюючи шум, теоретично можна підбирати токен посимвольно: замість 62^32 варіантів - 62 × 32 спроби.

hash_equals($known, $user) порівнює рядки за постійний час - незалежно від того, де саме відрізняються символи:

if (hash_equals($storedSignature, $providedSignature)) { ... }

Порядок аргументів важливий: перший - відоме (секретне) значення, другий - від користувача.

Де потрібне порівняння в постійному часі:

• підписи вебхуків і запитів (HMAC);
• API-ключі й токени, якщо порівнюються як рядки;
• коди підтвердження, CSRF-токени;
• підписані URL.

Laravel використовує hash_equals для перевірки CSRF-токенів, підписаних маршрутів, токенів Sanctum.

Інші джерела витоку через час:

• перевірка пароля лише для існуючих користувачів: для неіснуючого email сервер відповідає миттєво, для існуючого - після bcrypt (сотні мілісекунд). Це дає перелік облікових записів. Захист - виконувати хешування завжди;
• різна робота залежно від результату: відправка листа лише якщо обліковий запис існує, запит до бази лише для певних випадків;
• пошук у базі за секретом: WHERE token = ? - час пошуку за індексом теоретично теж може залежати від значення. Тому надійніше шукати за ідентифікатором, а секрет порівнювати окремо через hash_equals (так зроблено в Sanctum: токен має вигляд id|секрет).

Наскільки це реально в інтернеті: мережевий шум у мілісекунди набагато більший за наносекундні різниці порівняння рядків, тож атака на сирі рядкові порівняння через інтернет складна. Але з тисячами вимірювань і статистикою вона можлива, а в межах одного хмарного регіону шум значно менший. Порівняння в постійному часі коштує нічого - немає причин ризикувати.

Не лише рядки: криптографічні реалізації мають бути «constant-time» загалом - тому використовують перевірені бібліотеки (sodium_*, openssl_*), а не власні реалізації алгоритмів.

Докладніше в документації: PHP: hash_equals

«Увійти через Google/GitHub» здається простим, бо бібліотека (у Laravel - Socialite) бере на себе протокол. Але кілька помилок у логіці застосунку роблять його небезпечним.

1. Об'єднання облікових записів за email без перевірки.

$user = User::firstOrCreate(['email' => $socialUser->getEmail()], [...]);
Auth::login($user);

Якщо провайдер дозволяє вказати неперевірений email, зловмисник створює там обліковий запис з email жертви - і входить у її обліковий запис на вашому сайті. Правила:

• зв'язувати лише з підтвердженим у провайдера email (наприклад, email_verified в OpenID Connect);
• зберігати ідентифікатор провайдера (provider + provider_id), а не лише email, і шукати насамперед за ним;
• прив'язку соцмережі до існуючого облікового запису робити з облікового запису (користувач уже увійшов паролем) чи з підтвердженням поштою.

2. Відсутність перевірки state. Параметр state пов'язує відповідь провайдера із сесією користувача, що почав вхід. Без нього можлива CSRF-атака на вхід: жертву непомітно входять в обліковий запис зловмисника (і вона, наприклад, зберігає туди свої дані). Socialite перевіряє state за замовчуванням; stateless() вимикає перевірку - лише для API з PKCE.

3. Відкрите перенаправлення. Параметр «куди повернутися після входу» (?redirect=) без перевірки - фішинг на вашому домені. Дозволений лише відносний шлях свого сайту.

4. Неправильні redirect URI в налаштуваннях провайдера. Шаблони (https://*.example.com/*) чи зайві адреси дозволяють перехопити код авторизації. Точні адреси, лише HTTPS.

5. Довіра до даних профілю. Ім'я, аватар, email від провайдера - звичайні дані користувача: їх треба валідувати й екранувати.

6. Втрата доступу при видаленні облікового запису провайдера. Користувач без пароля, що втратив Google-акаунт, втрачає доступ - потрібні альтернативні способи входу.

7. Зайві права (scopes). Просити лише потрібне (openid email profile), а не доступ до пошти чи диска «на майбутнє».

8. Токени провайдера. Якщо застосунку справді потрібні токени доступу до API провайдера - зберігати їх зашифрованими (encrypted cast) і оновлювати refresh-токенами.

Для співбесіди: найважливіше - пункт 1. Захоплення облікових записів через неперевірений email - найпоширеніша реальна вразливість соціального входу.

Докладніше в документації: OWASP: шпаргалка з OAuth 2.0

Для безпеки потрібна не просто «випадковість», а непередбачуваність: знаючи попередні значення, неможливо вгадати наступні.

Некриптографічні генератори - mt_rand(), rand(), uniqid(), lcg_value(), Math.random() у JavaScript:

• побудовані для швидкості й рівномірного розподілу, а не для безпеки;
• внутрішній стан відновлюється з кількох виходів - для Mersenne Twister (mt_rand) відомі інструменти, що за кількома значеннями обчислюють зерно й передбачають усі наступні;
• uniqid() - це просто поточний час у мікросекундах: передбачуваний.

Криптографічно стійкі генератори (CSPRNG) - з джерела ентропії операційної системи:

random_bytes(32);                 // 32 випадкові байти
bin2hex(random_bytes(32));        // 64 hex-символи
random_int(100000, 999999);       // число в діапазоні - для кодів підтвердження
Str::random(40);                  // Laravel: на основі random_bytes
Str::password(16);                // Laravel: пароль з різними класами символів

PHP 8.2 також має ООП-API Random\Randomizer з рушієм Random\Engine\Secure (за замовчуванням).

Де потрібен CSPRNG: токени сесій і API, токени скидання пароля й підтвердження email, коди 2FA й одноразові паролі, CSRF-токени, ключі шифрування, солі (зазвичай генерує password_hash), ідентифікатори, що служать «секретом» (неперебірні посилання на документи).

Розмір має значення: 128 біт ентропії (16 байтів) - мінімум для токенів, що мають бути неперебірними; 256 біт - з запасом. Шестизначний код - лише ~20 біт, тож його захищає не випадковість, а обмеження спроб і короткий термін дії.

Пастки:

• md5(time()), sha1(uniqid()), md5(rand()) - хешування не додає ентропії: передбачуване значення лишається передбачуваним;
• зменшення діапазону через % (random_bytes + % 10) дає нерівномірний розподіл - для чисел використовувати random_int;
• UUID як секрет: UUIDv4 має 122 випадкові біти і для більшості цілей годиться, якщо генерується CSPRNG. Але UUIDv7 (Laravel HasUuids, Str::uuid7()) містить мітку часу і менше випадкових бітів - як ідентифікатор він добрий, а як секретний токен - ні;
• mt_srand() з фіксованим зерном у коді безпеки - повна передбачуваність.

У JavaScript для безпеки - crypto.getRandomValues() і crypto.randomUUID(), а не Math.random().

Докладніше в документації: PHP: random_bytes

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: шифрування

Довірені проксі. Якщо перед застосунком стоїть балансувальник чи CDN (Cloudflare, AWS ALB, Nginx), справжні IP клієнта, протокол і хост приходять у заголовках X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host. Laravel використовує їх, лише якщо проксі довірений:

->withMiddleware(function (Middleware $middleware): void {
    $middleware->trustProxies(at: ['10.0.0.0/8']);       // адреси своїх балансувальників
    // $middleware->trustProxies(at: '*');                // лише якщо застосунок недоступний напряму
})

Без налаштування: $request->ip() повертає IP балансувальника - ліміти частоти діють на всіх клієнтів разом, логи марні; $request->secure() - false, і генеруються http:// посилання.

З at: '*', коли застосунок доступний і напряму: будь-хто надсилає X-Forwarded-For: 1.2.3.4 - і обходить ліміти частоти за IP, підробляє адреси в журналах аудиту.

Довірені хости. TrustHosts у Laravel за замовчуванням вимкнений - застосунок приймає запити з будь-яким заголовком Host, якщо вебсервер їх пропускає.

Отруєння посилання скидання пароля (host header injection):

1. зловмисник надсилає запит на скидання пароля для email жертви з підробленим заголовком Host: evil.example;
2. якщо URL у листі будується з хоста поточного запиту, жертва отримує справжній лист від вашого сервісу з посиланням https://evil.example/reset-password/{token};
3. жертва переходить - токен потрапляє до зловмисника, і він скидає пароль.

Те саме з будь-якими абсолютними посиланнями, згенерованими з запиту: підтвердження email, запрошення, посилання в кешованих сторінках (отруєння кешу).

Захист:

$middleware->trustHosts(at: ['laravelukraine.com'], subdomains: true);

• trustHosts() - запити з іншим Host відхиляються;
• вебсервер приймає лише свої домени (без «default server», що обслуговує будь-який хост);
• посилання в листах і фонових задачах - з APP_URL (URL::forceRootUrl(config('app.url')) для черг і консолі, де запиту немає);
• URL::forceScheme('https') на продакшені за проксі, якщо схему не можна надійно визначити.

Перевірка: curl -H 'Host: evil.example' https://ваш-сайт/forgot-password - відповідь має бути помилкою, а не нормальною сторінкою.

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

Налаштування в config/session.php (і змінні SESSION_* у .env) безпосередньо визначають, наскільки легко викрасти чи підробити сесію.

Атрибути cookie:

SESSION_SECURE_COOKIE за замовчуванням не задано - Laravel не виставляє Secure, доки ви не ввімкнете. На продакшені з HTTPS - обов'язково true.

Драйвер сесій:

• database, redis - дані на сервері, у cookie лише ідентифікатор. Можна переглянути й завершити сесії користувача («вийти з усіх пристроїв»);
• cookie - усі дані сесії в зашифрованій cookie. Неможливо примусово завершити сесію на сервері, розмір обмежений, а витік APP_KEY дає підробку сесій;
• file - на кількох серверах не працює без спільного сховища.

encrypt (SESSION_ENCRYPT) - шифрувати дані сесії у сховищі. Корисно, якщо в сесії бувають чутливі дані, а доступ до Redis чи таблиці сесій мають інші системи.

Терміни:

• lifetime - хвилини неактивності до завершення сесії (за замовчуванням 120);
• expire_on_close - сесія закінчується при закритті браузера;
• для адмінок і фінансових застосунків - коротші терміни й повторне підтвердження пароля для чутливих дій.

Регенерація ідентифікатора:

• після входу - $request->session()->regenerate() (стандартні контролери автентифікації роблять це) - захист від фіксації сесії;
• при виході - invalidate() і regenerateToken().

Що ще перевірити:

• окремі назви cookie (SESSION_COOKIE) для різних застосунків на одному домені - інакше вони перезаписують сесії одне одного;
• SameSite=None (потрібна для вбудовування в iframe на інших сайтах) - лише з Secure і з усвідомленням, що захист від CSRF тепер повністю на токенах;
• таблиця сесій містить IP і user agent - персональні дані з відповідним терміном зберігання.

Докладніше в документації: Laravel: налаштування сесій

Laravel хешує паролі через Hash::make() (і каст hashed у моделі User). Налаштування - у config/hashing.php.

Алгоритм за замовчуванням - bcrypt з вартістю (BCRYPT_ROUNDS) 12: кожне збільшення на 1 подвоює час обчислення. Альтернатива - Argon2id (HASH_DRIVER=argon2id) з параметрами пам'яті, часу й потоків (ARGON_MEMORY, ARGON_TIME, ARGON_THREADS).

bcrypt чи Argon2id:

• Argon2id - сучасний рекомендований OWASP варіант: вимагає багато пам'яті, тому перебір на GPU й спеціалізованих чипах значно дорожчий;
• bcrypt - перевірений часом, доступний усюди, але має обмеження в 72 байти: усе, що довше, ігнорується. Пароль з 80 символів і той самий пароль з іншими останніми символами дадуть однаковий хеш. Для кирилиці (2 байти на символ) межа - ~36 символів. Laravel має параметр BCRYPT_LIMIT, щоб відхиляти задовгі паролі замість мовчазного обрізання.

Як обирати вартість: обчислення хешу має займати приблизно сотні мілісекунд на вашому сервері. Менше - легше перебирати при витоку бази; більше - повільний вхід і можливість DoS через масові спроби входу. Вартість варто переглядати разом з обладнанням.

Повторне хешування при вході. У Laravel 11+ rehash_on_login увімкнено за замовчуванням: при успішному вході Laravel перевіряє, чи хеш створено з поточними налаштуваннями, і якщо ні - перехешовує пароль (відкритий текст на цей момент відомий). Тому підвищення BCRYPT_ROUNDS чи перехід на Argon2id відбуваються поступово, без примусового скидання паролів.

verify (HASH_VERIFY=true) - перевірка, що хеш створено очікуваним алгоритмом. Захищає від ситуацій, коли в базі опиняються хеші іншого типу (наприклад, після імпорту), що перевірялися б іншим, можливо слабшим, способом.

Ручне перехешування:

if (Hash::needsRehash($user->password)) {
    $user->password = Hash::make($plainPassword);
    $user->save();
}

Типові помилки:

• md5, sha1, sha256 для паролів - швидкі хеші, мільярди перевірок за секунду на GPU;
• шифрування паролів замість хешування;
• власна «сіль» чи комбінації алгоритмів - password_hash і Laravel уже додають сіль автоматично;
• знижена вартість у продакшені через BCRYPT_ROUNDS з тестового .env: у тестах низька вартість доречна для швидкості (phpunit.xml задає BCRYPT_ROUNDS=4), але не на сервері.

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

DOM XSS виникає повністю в браузері: JavaScript бере дані з контрольованого нападником джерела (location.hash, location.search, postMessage, відповідь API) і передає в небезпечний приймач (sink):

element.innerHTML = location.hash.slice(1);      // HTML-приймач
script.src = params.get('widget');               // URL скрипта
setTimeout(userInput);                            // рядок як код
document.write(...);  eval(...);  new Function(...);

Сервер такої вразливості не бачить: шкідливе значення взагалі може не доходити до нього (фрагмент #... не надсилається на сервер). Знайти всі такі місця у великому застосунку й бібліотеках - важко.

Trusted Types змінюють правила гри: з увімкненою політикою небезпечні приймачі відмовляються приймати звичайні рядки. Їм потрібні спеціальні типізовані об'єкти (TrustedHTML, TrustedScript, TrustedScriptURL), які можна створити лише через зареєстровані політики.

Увімкнення - через CSP:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-sanitizer

Політика - єдине місце, де рядок стає «довіреним»:

const sanitizer = trustedTypes.createPolicy('app-sanitizer', {
  createHTML: (input) => DOMPurify.sanitize(input),
});

element.innerHTML = sanitizer.createHTML(userHtml);   // дозволено
element.innerHTML = userHtml;                         // TypeError - заблоковано

Що це дає:

• кількість місць для перевірки зменшується до кількох політик замість сотень присвоєнь innerHTML по всьому коду;
• порушення помітні: спроба записати рядок у приймач кидає помилку (і може звітувати через CSP);
• контроль над бібліотеками: директива trusted-types обмежує, які політики можна створювати, - стороння бібліотека не створить «свою» лазівку непомітно.

Впровадження:

1. Content-Security-Policy-Report-Only: require-trusted-types-for 'script' - зібрати всі місця, де рядки потрапляють у приймачі;
2. переписати їх на безпечні API (textContent, setAttribute для безпечних атрибутів) або пропустити через політику з санітизацією;
3. увімкнути блокування.

Обмеження:

• підтримка браузерами: Trusted Types давно є в Chromium, інші браузери додавали її пізніше - перед покладанням на них як на основний захист варто перевірити актуальну підтримку. Там, де Trusted Types немає, код має лишатися безпечним сам по собі;
• фреймворки (React, Vue) мають власний захист від XSS у шаблонах; Trusted Types закривають «аварійні виходи» на кшталт dangerouslySetInnerHTML, v-html і прямої роботи з DOM.

Докладніше в документації: MDN: Trusted Types API

postMessage - легальний спосіб обміну даними між вікнами різних походжень: сторінка й вбудований <iframe> платіжної форми, вікно OAuth-входу й основний застосунок, віджет на чужому сайті й ваш сервер.

// відправник
iframe.contentWindow.postMessage({ type: 'resize', height: 640 }, 'https://widget.example');

// отримувач
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://app.example') return;   // обов'язкова перевірка
  if (event.data?.type === 'resize') {
    iframe.style.height = `${Number(event.data.height)}px`;
  }
});

Дві обов'язкові перевірки:

1. При відправленні - конкретне targetOrigin, а не '*'.

popup.postMessage({ token }, '*');   // небезпечно

Якщо вікно встигли перенаправити на інший сайт (наприклад, фрейм завантажив сторінку нападника), повідомлення з токеном отримає чужий код. З конкретним targetOrigin браузер просто не доставить повідомлення не тому адресату.

2. При отриманні - перевірка event.origin. Будь-яка сторінка, що має посилання на ваше вікно (відкрила його через window.open чи вбудувала у фрейм), може надіслати йому повідомлення. Без перевірки обробник виконає команди нападника.

Типові помилки:

• перевірка походження за підрядком: event.origin.includes('example.com') пропустить https://example.com.attacker.io. Лише точне порівняння з переліком;
• довіра вмісту від довіреного походження: навіть повідомлення від свого фрейму - це дані, які могли прийти від користувача. Небезпечно передавати їх у innerHTML, eval, location.href (схема javascript:);
• event.source без перевірки - відповідати варто лише на event.source, а не на «будь-яке вікно»;
• чутливі дані в повідомленнях без потреби - кожне повідомлення може побачити розширення браузера чи інший слухач на тій самій сторінці;
• слухачі, що лишилися після закриття фрейму, - накопичуються в SPA.

Структура повідомлень: тип і версія в кожному повідомленні, валідація схеми (як для API). Повідомлення - це міжсайтовий API, і до нього ті самі вимоги.

Альтернатива для однієї вкладки свого ж походження - BroadcastChannel, а для запитів між вікнами з відповіддю - MessageChannel з окремими портами: менше слухачів на глобальному window.

Докладніше в документації: MDN: Window.postMessage()

Після атак класу Spectre стало зрозуміло, що код на сторінці може прочитати дані з пам'яті процесу браузера через побічні канали (точні таймери, спільна пам'ять). Тому браузери ізолюють сайти в окремих процесах, а потужні API (SharedArrayBuffer, таймери високої точності) доступні лише сторінкам у режимі крос-доменної ізоляції.

Три заголовки:

COOP - Cross-Origin-Opener-Policy: розриває зв'язок між вашим вікном і вікнами інших походжень, відкритими через window.open чи посилання.

Cross-Origin-Opener-Policy: same-origin

Чужа сторінка, що відкрила ваш сайт, не отримає посилання на ваше вікно (window.opener = null) - і не зможе ним маніпулювати (атаки на кшталт XS-Leaks, підміна вкладки). same-origin-allow-popups - компроміс для сайтів, яким потрібні спливаючі вікна OAuth чи платежів.

COEP - Cross-Origin-Embedder-Policy: сторінка завантажує сторонні ресурси лише якщо вони явно дозволили вбудовування.

Cross-Origin-Embedder-Policy: require-corp

credentialless - м'якший варіант: сторонні ресурси без дозволу завантажуються, але без cookie.

CORP - Cross-Origin-Resource-Policy: ставить власник ресурсу - хто може його вбудовувати.

Cross-Origin-Resource-Policy: same-origin   # лише свій сайт
Cross-Origin-Resource-Policy: same-site
Cross-Origin-Resource-Policy: cross-origin  # будь-хто (для публічного CDN)

Крос-доменна ізоляція = COOP: same-origin + COEP: require-corp (чи credentialless). Тоді window.crossOriginIsolated === true, і доступні SharedArrayBuffer, точні таймери, performance.measureUserAgentSpecificMemory().

Кому це потрібно:

• застосункам на WebAssembly з потоками (відео- й аудіоредактори, ігри, CAD), обчисленням у браузері;
• CORP і COOP корисні всім як захист від витоків між сайтами, навіть без повної ізоляції.

Ціна COEP: кожен сторонній ресурс (зображення з CDN, шрифти, рекламні й аналітичні скрипти, фрейми) має надсилати CORP чи CORS-заголовки - інакше перестане завантажуватися. Для сайтів з великою кількістю стороннього вмісту повна ізоляція часто нереальна без credentialless.

Практичний мінімум для звичайного сайту: COOP: same-origin (чи same-origin-allow-popups) і CORP: same-origin для приватних ресурсів (файли користувачів, API) - дешевий захист від частини витоків між вкладками.

Докладніше в документації: MDN: crossOriginIsolated

Скрипт, підключений на сторінку через <script src>, має ті самі права, що й ваш код: бачить DOM, введення в поля форм (включно з паролями й картками), робить запити від імені користувача, читає localStorage. Аналітика, пікселі реклами, чат підтримки, A/B-тести - кожен сторонній скрипт - це довіра до постачальника й усього його ланцюжка постачання.

Реальні сценарії атак:

• компрометація постачальника - скрипт аналітики чи віджета на CDN підмінили, і він крав дані платіжних форм на тисячах сайтів (атаки класу Magecart);
• тег-менеджер (Google Tag Manager тощо) - маркетологи додають скрипти без рев'ю розробників. Обліковий запис тег-менеджера стає способом виконати довільний код на сайті;
• прострочений домен: скрипт підключено з домену, який постачальник перестав продовжувати, - його реєструє нападник.

Як зменшити ризик:

1. Мінімізація: прибирати скрипти, якими ніхто не користується. Не підключати сторонній код на найчутливіших сторінках (оплата, вхід, налаштування безпеки).

2. CSP: явний перелік дозволених джерел, connect-src - щоб навіть скомпрометований скрипт не міг відправити дані на довільний домен.

3. SRI для незмінних сторонніх файлів із фіксованою версією.

4. Власна копія (self-hosting) - бібліотеки з npm у своєму бандлі замість CDN.

5. Ізоляція в <iframe> з sandbox - сторонній віджет працює в окремому походженні й не має доступу до вашої сторінки:

<iframe
  src="https://widget.example/embed"
  sandbox="allow-scripts allow-forms"
  referrerpolicy="no-referrer"
></iframe>

sandbox без значень забороняє все: скрипти, форми, спливаючі вікна, навігацію верхнього вікна. Дозволи додаються по одному.

Головна пастка sandbox: allow-scripts разом із allow-same-origin для вмісту з вашого ж походження знецінює пісочницю: скрипт усередині може дістатися до батьківської сторінки й прибрати атрибут sandbox у свого фрейму. Користувацький HTML варто віддавати з окремого домену (як usercontent.example) і в пісочниці.

6. Процес: перелік сторонніх скриптів з власником і метою, рев'ю перед додаванням у тег-менеджер, двофакторна автентифікація й мінімальні права для облікових записів тег-менеджера.

Регуляторний аспект: PCI DSS 4.0 вимагає інвентаризації й контролю цілісності всіх скриптів на сторінках оплати.

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