Авторка: Катерина Іваненко, Invicti Brand Manager
JavaScript – потужна і широко розповсюджена мова програмування для створення вебзастосунків. Проте в ній можуть робити типові помилки безпеки, що здатні підвищити ризик успішних кібератак.
Відсутність Content Security Policy (CSP)
Content Security Policy (CSP) – це HTTP-заголовок, який дозволяє власнику вебсайту чітко задати джерела, з яких дозволено завантаження контенту, такого як скрипти, стилі, зображення та інші ресурси.
Він захищає від атак типу XSS (міжсайтовий скриптинг) та деяких ін’єкцій, тому його присутність є значущою.
Щоб запобігти цій помилці, слід завжди впроваджувати жорсткі CSP-заголовки, наприклад: default-src ‘self’; script-src ‘self’; object-src ‘none’.
Небезпечне зберігання даних у LocalStorage/SessionStorage
Зберігання конфіденційних даних (наприклад, токенів) у незашифрованому вигляді в LocalStorage/SessionStorage доступне через JavaScript.
До прикладу, це може призводити до крадіжки токенів, XSS та несанкціонованого доступу до облікового запису.
Краще зберігати чутливі дані в HTTP-only cookies з атрибутами Secure і SameSite. Вони не доступні для JavaScript, а отже не вразливі до, наприклад, XSS.
Відсутність перевірки вхідних даних користувача
Важливо перевіряти вхідні дані користувача як на стороні клієнта, так і на стороні сервера, про що деякі забувають, адже валідацію лише на стороні клієнта можна легко обійти.
Це може призвести до критичних вразливостей, таких як SQL-ін’єкції, ін’єкції системних команд, XSS-атаки, а також несанкціоноване створення чи модифікація даних.
Потрібно обов’язково реалізовувати валідацію вхідних даних та розглядати будь-які дані, отримані від користувача, як потенційно небезпечні.
Зберігання CSRF-токенів у cookie
Якщо автентифікація користувачів у застосунку базується на cookie, зловмисник може отримати доступ до cookie сесії й діяти від його імені. Такі CSRF-атаки є одними з найпоширеніших вразливостей JavaScript.
Цієї проблеми можна уникнути, передаючи додатковий токен із кожним HTTP-запитом. Оскільки CSRF-токени не зберігаються у cookie, зловмисник не може їх перехопити. Такі токени можна вставляти у форми, AJAX-запити, HTTP-заголовки, приховані поля та інші елементи.
Нижче наведено приклад CSRF-токена з проєкту OWASP, який можна вставити у форму як приховане поле:
**
<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZMGYwMGEwOA==">
[...]
</form>
**Небезпечна передача cookie
Щоб додатково підвищити безпеку cookie, варто переконатися, що вони передаються лише через захищений протокол, такий як HTTPS, що шифрує дані між клієнтом і сервером. Можна примусово вимагати використання захищеного протоколу, додаючи прапорець ;secure до властивості Document.cookie, яка надає доступ до cookie документа.
Його можна використовувати разом із прапорцем ;samesite, який дозволяє контролювати передачу cookie при міжсайтових запитах. Наприклад, застосування значення lax дає можливість передавати cookie при всіх запитах у межах одного сайту та при навігації верхнього рівня методом GET. Це дозволяє здійснювати відстеження користувача, але водночас запобігає значній частині CSRF-атак.
Використання застарілих або вразливих бібліотек
Застосування сторонніх бібліотек без належного контролю версій і оновлень створює ризики для безпеки, адже вони можуть бути вразливими до ряду кібератак.
Можливі наслідки включають довільне виконання коду (Remote Code Execution), міжсайтовий скриптинг (XSS), підробку міжсайтових запитів (CSRF) та інші атаки.
Доцільно використовувати інструменти аналізу програмних компонентів (Software Composition Analysis, SCA), такі як Mend.io, щоб своєчасно виявляти вразливі бібліотеки.
Додаткова рекомендація
Для перевірки безпеки своїх вебсайтів важливо використовувати вебсканери DAST, як-от Invicti. Рішення ефективно знаходить усі вразливості та підтверджує існування ключових з них.
Щоб переконатися в цьому на практиці, ви можете безкоштовно протестувати Invicti – просто зверніться до нас у зручний для вас спосіб.
