Чекліст безпеки для застосунків, створених за допомогою ШІ: що перевірити перед запуском

Перш ніж реальні люди почнуть користуватися застосунком, створеним за допомогою ШІ, перевірте сім речей: кожна сторінка та кожен API перевіряють, хто користувач і що йому дозволено; секретні ключі зберігаються на сервері, а не в браузері чи чаті; усі дані перевіряються на сервері; кожен користувач має доступ лише до своїх записів; вхід і дорогі кінцеві точки обмежені за кількістю запитів; залежності оновлені; а дані можна відновити, якщо щось піде не так. Чекліст нижче перетворює кожен із цих пунктів на конкретні перевірки, які можна виконати, не читаючи код.

Конструктори застосунків на основі ШІ добре вміють робити так, щоб функції працювали. Але вони не є обережними автоматично, адже «обережність» рідко є в запиті. Більшість проблем нижче виникають через речі, про які ніхто не просив, тож виправлення зазвичай полягає в тому, щоб про це попросити.

Як користуватися чеклістом

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

• Обов’язково — зробіть це, перш ніж застосунком скористається будь-хто інший.
• Бажано — зробіть це, перш ніж у вас з’являться реальні користувачі або реальні дані.
• Пізніше — варто зробити, коли застосунок росте.

Якщо маєте лише годину, зробіть усі пункти «Обов’язково».

1. Автентифікація: хто це?

Автентифікація означає підтвердження того, хто є користувачем, зазвичай через вхід. Основи дивіться в що таке автентифікація, а варіанти — у як додати вхід до свого застосунку.

• Обов’язково: Кожна сторінка, що показує приватні дані, вимагає входу. Перевірка: вийдіть із системи, потім вставте адресу приватної сторінки безпосередньо в браузер.
• Обов’язково: Кожна кінцева точка API за цими сторінками також вимагає входу, а не лише сторінка. Перевірка: вийдіть із системи, відкрийте вкладку мережі в браузері та повторіть запит, який застосунок надсилав, поки ви були ввійшли.
• Обов’язково: Паролі зберігаються у вигляді хешів за допомогою повільного алгоритму хешування паролів, ніколи не у відкритому тексті. Рекомендації OWASP щодо зберігання паролів радять насамперед Argon2id, а альтернативами є scrypt, bcrypt або PBKDF2. Запитайте: «Як зберігаються паролі?»
• Бажано: Посилання для скидання пароля завершуються через певний час і працюють лише один раз.
• Бажано: Файли cookie сесії позначено як Secure, HttpOnly і SameSite, а вихід із системи завершує сесію на сервері.
• Пізніше: Запропонуйте двофакторну автентифікацію або вхід через провайдера, який її підтримує.

Перевірте кожен маршрут API і кожну сторінку, що повертає дані користувача. Кожен має відхиляти запити від користувачів, які не ввійшли, на сервері, а не лише в коді сторінки. Перелічіть маршрути, які ви перевірили.

2. Авторизація: що їм дозволено робити?

Авторизація — це крок після входу: вирішення того, що саме цей користувач може бачити й змінювати. Саме тут у застосунках на основі ШІ найчастіше бувають серйозні діри, бо застосунок виглядає правильно: панель кожного користувача показує лише його дані, тоді як сервер охоче віддасть чиїсь дані, якщо про них прямо попросити.

• Обов’язково: Кожне читання, оновлення та видалення перевіряє на сервері, що запис належить поточному користувачу (або його команді).
• Обов’язково: Перевірте це: створіть два облікові записи, A і B. Увійшовши як A, відкрийте один із записів A і запам’ятайте ідентифікатор в адресі або мережевому запиті. Увійдіть як B і запросіть той самий ідентифікатор. B має отримати помилку, а не дані A.
• Обов’язково: Сторінки адміністратора та кінцеві точки API адміністратора перевіряють роль користувача на сервері. Приховане посилання на адмінку не є захистом.
• Обов’язково: Користувачі не можуть змінити власну роль, ціну, баланс або поля власника, редагуючи запит. Перевірка: у вкладці мережі подивіться, що надсилає оновлення профілю. Якщо там є поля на кшталт role або isAdmin, попросіть ШІ ігнорувати їх із боку клієнта.
• Бажано: Ідентифікатори в адресах важко вгадати (випадкові ідентифікатори, а не 1, 2, 3). Це не заміна перевірок дозволів, але це обмежує шкоду, коли якась із них відсутня.

Для кожної кінцевої точки, що читає або змінює запис, перевірте на сервері, що ввійшлий користувач є її власником або має доступ. Якщо ні, поверніть 404. Потім покажіть, як би ви перевірили це з двома обліковими записами.

3. Доступ на рівні рядків у базі даних

«Доступ на рівні рядків» означає, що кожен рядок таблиці (одне бронювання, один рахунок) видимий лише тим користувачам, яким він належить. Є два поширені способи це забезпечити:

Обидва способи можна зробити добре. Важливо таке:

• Обов’язково: Якщо браузер звертається до бази даних напряму (деякі хостингові продукти бази даних це дозволяють), правила доступу на рівні рядків увімкнено для кожної таблиці. Без них кожен, хто має публічний ключ, може прочитати всю таблицю.
• Обов’язково: Запити фільтрують за поточним користувачем або командою, а не за ідентифікатором, який надіслав браузер.
• Бажано: Спільні дані (проєкти команди) мають чітке правило щодо того, хто входить до команди, і це правило застосовується в одному місці.

4. Секрети та API-ключі

API-ключ — це пароль до сервісу. Ним користуються Stripe, сервіси електронної пошти та провайдери ШІ. Довідкову інформацію дивіться в що таке змінні середовища та секрети.

• Обов’язково: Ключі зберігаються у змінних середовища або секретах проєкту, а ніколи не записуються в код.
• Обов’язково: Ключі, які можуть витрачати гроші або читати приватні дані, використовуються лише на сервері. Перевірка: відкрийте свій живий сайт, перегляньте джерело сторінки та файли JavaScript у інструментах розробника і шукайте початок вашого ключа (наприклад, sk_). Його там бути не повинно.
• Обов’язково: Ключі ніколи не вставлялися в чат, публічний репозиторій чи на скріншот. Якщо так сталося, перевипустіть ключ у провайдера (створіть новий і видаліть старий).
• Бажано: Використовуйте обмежені ключі або ключі з обмеженою областю, де провайдер це пропонує. Stripe, наприклад, рекомендує обмежені ключі, які мають лише дозволи, потрібні вашій інтеграції.
• Бажано: Тестові та бойові ключі розділені, а живий застосунок використовує бойові ключі лише тоді, коли ви готові.

Деякі ключі призначені бути публічними, наприклад публікований ключ Stripe (pk_…) або ключ карт, обмежений вашим доменом. Правило стосується ключів, які дають повноваження, а не кожного рядка, що схожий на ключ.

5. Перевірка введених даних

Будь-що, що надсилає користувач, — поля форм, завантажені файли, параметри адреси — може бути чим завгодно, а не лише тим, що дозволяє ваша форма.

• Обов’язково: Перевірка відбувається на сервері, а не лише в браузері. Перевірки в браузері існують для зручності; їх може обійти будь-хто.
• Обов’язково: Запити до бази даних використовують параметри, а не текст, склеєний із введених користувачем даних (це запобігає SQL-ін’єкціям). Попросіть ШІ підтвердити це.
• Обов’язково: Текст, який вводять користувачі, відображається як текст, а не виконується як HTML. Перевірка: введіть <b>hello</b> як своє ім’я. Ви маєте побачити теги, а не жирний текст.
• Бажано: Завантаження файлів перевіряють тип і розмір, а завантажені файли не подаються з головного домену вашого застосунку як виконувані сторінки.
• Бажано: Помилки, які бачать користувачі, мають простий вигляд («Щось пішло не так»); докладні помилки потрапляють лише в журнали сервера.
• Бажано: Вебхуки від сервісів на кшталт Stripe перевіряють підпис провайдера, перш ніж діяти. Дивіться що таке вебхук.

Додайте перевірку на сервері до кожної форми та кінцевої точки API: обов’язкові поля, довжини, формати та дозволені значення. Усе інше відхиляйте з чітким повідомленням. Не показуйте користувачам внутрішні деталі помилок.

6. Ліміти запитів і зловживання

Ліміт запитів обмежує, скільки запитів може зробити людина за певний період. Без них будь-хто може цілий день підбирати паролі, заповнювати вашу форму реєстрації або збільшувати рахунок за платний API.

• Обов’язково: Вхід, реєстрація та скидання пароля обмежені за кількістю запитів для кожної IP-адреси та для кожного облікового запису.
• Обов’язково: Усе, що коштує вам грошей за кожен виклик — запити до моделей ШІ, SMS, електронна пошта, — має ліміт для кожного користувача та вимагає входу.
• Бажано: Публічні форми (контакти, список очікування) мають захист від спаму: ліміт запитів, приховане поле-пастка або CAPTCHA.
• Бажано: Встановіть ліміти витрат або сповіщення у ваших платних провайдерів, щоб помилка або зловмисник не спричинили необмежений рахунок.

7. Залежності

Застосунки складаються з пакетів з відкритим кодом, а в пакетів іноді є відомі вразливості.

• Бажано: Попросіть ШІ перевірити відомі вразливості (для проєктів на JavaScript — npm audit або еквівалент для вашого менеджера пакетів) і оновити уражені.
• Бажано: Видаліть пакети, які застосунок більше не використовує.
• Бажано: Будьте обережні з пакетами, якими користуються дуже мало людей, або з назвами, схожими на друкарські помилки в популярних.
• Пізніше: Перевіряйте щомісяця або раз на два місяці або ввімкніть автоматичні сповіщення, якщо ваш код розміщено на GitHub.

8. Резервні копії та відновлення

Безпека включає можливість відновитися після помилок — ваших, ШІ чи зловмисника.

• Обов’язково: Знайте, де зберігаються ваші дані і чи є їх резервні копії. Не припускайте — перевірте документацію вашого хостингу.
• Бажано: Робіть власний періодичний експорт важливих даних (наприклад, за допомогою функції експорту в CSV або дампу бази даних) і зберігайте його окремо.
• Бажано: Зберігайте код у системі контролю версій, щоб будь-яку версію можна було відновити.
• Бажано: Деструктивні дії (видалення облікового запису, видалення проєкту) вимагають підтвердження, і варто розглянути «м’яке видалення», яке можна скасувати протягом певного часу.
• Пізніше: Один раз справді протестуйте відновлення. Резервна копія, яку ніколи не відновлювали, — це сподівання, а не план.

9. Перед запуском

• Обов’язково: Живий сайт скрізь використовує HTTPS.
• Обов’язково: Зразкові дані, тестові облікові записи та налагоджувальні сторінки з розробки видалено.
• Бажано: Політика конфіденційності пояснює, які дані ви збираєте і навіщо, — у багатьох місцях це обов’язково, якщо ви збираєте персональні дані. Не заявляйте про сертифікації (SOC 2, HIPAA), яких у вас немає.
• Бажано: У вас є спосіб, щоб з вами могли зв’язатися щодо проблем безпеки, і ви знаєте, як швидко перевипустити кожен ключ.

Що стосується ширшої перевірки перед запуском, понад безпеку, дивіться як перевести прототип ШІ у робочий продукт.

Коли варто залучити фахівця для перевірки

Чекліст ловить типові помилки, але не замінює експерта. Розгляньте можливість оплатити перевірку, якщо ви самі обробляєте номери карток, а не через захищену сторінку оплати, зберігаєте медичні, фінансові чи дитячі дані, продаєте компаніям, які вимагають анкет з безпеки, або могли б зазнати серйозної шкоди через витік. Можливість експортувати код значно полегшує таку перевірку.

Безпека під час створення на Mythex

Mythex не має панелі сканування безпеки, тому наведений вище чекліст — це процес, якого варто дотримуватися. Ось кілька речей, які допоможуть:

• Секрети проєкту. Зберігайте ключі в налаштуваннях проєкту → Секрети або через картку секретів, яку агент показує в чаті, щоб вони не потрапляли в код і повідомлення. Після зміни секрета для живого застосунку опублікуйте його знову.
• Режими «План» і «Запитання». Попросіть агента перевірити дозволи без редагування: «У режимі запитань перелічіть кожен маршрут API і яку перевірку дозволів він виконує».
• /test змушує агента пройти ваш попередній перегляд як користувач — це корисно для тесту з двома обліковими записами з розділу 2.
• Контрольні точки дозволяють відкотити зміну, яка щось зламала.

Дивіться Безпека застосунків, які ви створюєте і Змінні середовища та секрети у документації. Якщо далі додаєте облікові записи користувачів, прочитайте як додати вхід до свого застосунку.

Запитання