Приблизно рік тому ми в DataLine запустили для пошуку та аналізу уразливостей в ІТ-додатках. В основі сервісу – хмарне рішення Qualys, про роботу якого . За рік роботи з рішенням ми провели 291 сканування для різних сайтів і накопичили статистику щодо поширених уразливостей у веб-додатках.
У статті нижче я покажу, які саме дірки у безпеці сайтів ховаються за різними рівнями критичності. Подивимося, які вразливості сканер знаходив особливо часто, чому можуть виникати і як захиститися.
Всі вразливості веб-застосунків Qualys ділить на три рівні критичності: низький, середній і високий. Якщо дивитися на розподіл за «вагою», здається, що все не так погано. Вразливостей з високим рівнем критичності мало, переважно всі некритичні:
Але некритичні – значить невинні. Вони також можуть завдати серйозної шкоди.
Топ «некритичних» уразливостей
- Уразливості, пов'язані зі змішаним вмістом.
Стандартом безпеки сайтів вважається передача даних між клієнтом та сервером за протоколом HTTPS, який підтримує шифрування та захищає інформацію від перехоплення.
Деякі сайти використовують змішаний вміст: передають частину даних через незахищений протокол HTTP. Найчастіше так передають пасивний вміст – інформацію, яка впливає лише на відображення сайту: картинки, css-стилі. Але іноді так передається і активний вміст: скрипти, які управляють поведінкою сайту У цьому випадку за допомогою спеціального ПЗ можна аналізувати інформацію, що надходить від сервера з активним вмістом, модифікувати на льоту свої відповіді і змушувати машину працювати так, як не було задумано її творцями.
Браузери нових версій попереджають користувачів, що сайти зі змішаним вмістом небезпечні та блокують контент. Розробники сайтів також одержують попередження від браузера в консолі. Наприклад, так це виглядає в :
Чим небезпечно: Зловмисники використовують незахищений протокол для перехоплення інформації про користувача, заміни скриптів та надсилання запитів на сайт від його імені. Навіть якщо відвідувач сайту не вводив даних, це не захищає його від фішингу - Вивужування конфіденційної інформації шахрайськими методами. Наприклад, за допомогою скрипта можна перенаправити користувача на небезпечний сайт, який маскується під знайомий користувачеві. В окремих випадках зловмисний сайт виглядає навіть краще за оригінал, і користувач може сам заповнити форму і передати конфіденційні дані.Що варто пам'ятати веб-розробнику: Навіть якщо адміністратор сайту встановив та налаштував SSL/TLS-сертифікат, вразливість може виникнути через людський фактор. Наприклад, якщо на якійсь із сторінок поставили не відносне посилання, а абсолютне з http, до того ж не налаштували редиректи з http на https.
Виявити змішаний контент на сайті можна за допомогою браузера: пошукати за вихідним кодом сторінки, почитати повідомлення консолі розробника. Однак розробнику доведеться довго і нудно копирсатися в коді. Прискорити процес можна з автоматизованими засобами аналізу, наприклад: , вільне програмне забезпечення Lighthouse або платний софт Screaming Frog SEO Spider.
Також уразливість може виникнути через проблеми з legacy-code – кодом, який дістався у спадок. Наприклад, якщо частина сторінок генерується за старим шаблоном, де враховується перехід сайтів на https.
- Куки без прапорів HTTPOnly і secure.
Атрибут «HTTPOnly» захищає файли cookie від обробки скриптами, які зловмисники використовують для крадіжки даних. Прапор «secure» не дозволяє передачу cookie у відкритому вигляді. Обмін даними буде дозволено, лише якщо для надсилання куки використовується захищений протокол HTTPS.
Обидва атрибути прописуються у властивостях куки:
Set-Cookie: Secure; HttpOnlyЧим небезпечно: Якщо розробник сайту не вказав ці атрибути, зловмисник може перехопити інформацію користувача з cookie та скористатися нею. Якщо куки використовуються для автентифікації та авторизації, він зможе викрасти сесію користувача та зробити дії на сайті від його імені.
Що варто пам'ятати веб-розробнику: Як правило, у популярних фреймворках ці атрибути задаються автоматично. Але все одно перевірте конфігурацію веб-сервера та поставте прапорець: Set-Cookie HttpOnly; Secure.
При цьому атрибут HTTPOnly зробить куки невидимими і для вашого власного JavaScript.
- Path-Based Vulnerabilities («шляхові» вразливості).
Сканер повідомляє про таку вразливість, якщо знаходить публічно доступний файл або директорію сайту з потенційно конфіденційною інформацією. Наприклад, виявляє окремі файли з конфігурацією системи або доступ до файлової системи. Така ситуація можлива, якщо на сайті неправильно вказані права доступу.
Чим небезпечно: Якщо файлова система стирчить назовні, зловмисник може провалитися в інтерфейс операційної системи і спробувати знайти папки з паролями, якщо вони зберігаються у відкритому вигляді (не треба так!). Або можна вкрасти хеш паролів і перебором підібрати пароль, а також спробувати підняти привілеї в системі і просуватися вглиб інфраструктури.
Що варто пам'ятати веб-розробнику: Не забувайте про права доступу та конфігуруйте платформу, веб-сервер, веб-додаток, щоб не можна було «втекти» з веб-директорії.
- Форми для введення конфіденційних даних із увімкненою функцією автозаповнення.
Якщо користувач часто заповнює форми на сайтах, браузер зберігає цю інформацію за допомогою функції автозаповнення.
Форми сайтів можуть включати поля з конфіденційною інформацією, наприклад, паролі або номери кредитних карток. Для таких полів варто на самому сайті вимкнути функцію автозаповнення форм.
Чим небезпечно: Якщо браузер користувача збереже конфіденційну інформацію, зловмисник може перехопити її пізніше, наприклад, за допомогою фішингу. По суті веб-розробник, який забув про цей нюанс, підставляє своїх користувачів.
Що варто пам'ятати веб-розробнику: У цьому випадку у нас класичний конфлікт: зручність vs безпека Якщо веб-розробник думає про комфорт користувача, він може вибрати автозаповнення. Наприклад, якщо важливо слідувати – рекомендації щодо доступності контенту для користувачів з обмеженими можливостями.
Для більшості браузерів відключити автозаповнення можна атрибутом autocompete=«off», наприклад:
<body> <form action="/uk/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Але для Chrome він не спрацює. Це обходять за допомогою JavaScript, варіант рецепту можна знайти .
- У коді сайту не встановлено заголовок X-Frame-Options.
Цей заголовок впливає на теги frame, iframe, embed чи object. З його допомогою можна повністю заборонити вбудовувати свій сайт усередину кадру. Для цього необхідно вказати значення X-Frame-Options: deny. Або можна вказати X-Frame-Options: sameorigin, тоді вбудовування в iframe буде доступне лише на вашому домені.
Чим небезпечно: Відсутність такого заголовка можна використовувати на шкідливих сайтах для клікджекінгу. Для такої атаки зловмисник створює прозорий кадр поверх кнопок і обманює користувача. Наприклад: шахраї ставлять у кадр на сайті сторінки соціальних мереж. Користувач думає, що натискає кнопку на цьому сайті. Натомість клік перехоплюється і надсилає запит користувача до соціальної мережі, де є активна сесія. Так зловмисники розсилають спам від імені користувача або накручують передплатників та лайки.
Якщо не заборонити таку можливість, зловмисник може поставити кнопку вашої програми на шкідливий сайт. Він може бути зацікавлений у вашій реферальній програмі або у ваших користувачах.
Що варто пам'ятати веб-розробнику: Вразливість може з'явитися, якщо X-Frame-Options з конфліктуючим значенням встановлено на веб-сервері або балансувальнику навантаження. У цьому випадку сервер і балансувальник просто перезапишуть заголовок, оскільки мають більш високий пріоритет у порівнянні з кодом бекенд-частини.
Значення deny і sameorigin заголовка X-Frame-Options заважатимуть роботі веб-візора Яндекса. Щоб дозволити використовувати iframe для веб-візора, потрібно написати в налаштуваннях окреме правило. Наприклад, для nginx можна налаштувати так:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Вразливості PRSSI (Path-relative stylesheet import).
Це вразливість у стилях сайту. Вона виникає, якщо для звернення до файлів стилів використовуються відносні посилання типу href="/uk/somefolder/styles.css/". Зловмисник скористається, якщо знайде спосіб перевести користувача на шкідливу сторінку. Сторінка підставить відносне посилання на свій url і імітує звернення до стилів. Вийде запит на кшталт badsite.ru/…/somefolder/styles.css/, який під виглядом стилю може робити шкідливі дії.
Чим небезпечно: Шахрай зможе скористатися цією вразливістю, якщо знайде ще одну дірку в безпеці В результаті так можна вкрасти дані користувача з куки або токени.
Що варто пам'ятати веб-розробнику: Введіть заголовок X-Content-Type-Options: nosniff. У цьому випадку браузер перевірить тип контенту для стилів. Якщо тип відрізняється від text/css, браузер заблокує запит.
Критичні вразливості
- Сторінка з полем для пароля передається з сервера незахищеним каналом (HTML form containing password field(s) is served over HTTP).
Відповідь від сервера по нешифрованому каналу вразлива для атак типу Man in the middle. Зловмисник може перехопити трафік і вклинитися між клієнтом та сервером, коли сторінка йде від сервера до клієнта.
Чим небезпечно: Шахрай зможе підмінити сторінку та надіслати користувачеві форму для конфіденційних даних, які підуть на сервер зловмисника.
Що варто пам'ятати веб-розробнику: Деякі сайти замість пароля надсилають користувачам одноразовий код на пошту/телефон. В цьому випадку вразливість не така критична, але механізм ускладнить життя користувачів.
- Надсилання форми з логіном і паролем незахищеним каналом (Login Form Is Not Submitted Via HTTPS).
У цьому випадку від користувача на сервер нешифрованим каналом відправляється форма з логіном і паролем.
Чим небезпечно: На відміну від попереднього випадку, це вже критична вразливість Перехопити конфіденційні дані простіше, оскільки не потрібно писати для цього код.
- Використання бібліотек JavaScript з відомими вразливістю.
За час сканування бібліотекою, що найбільш використовувалася, став jQuery з великим скопом версій. У кожній із версій є хоча б одна, а то й більше відомих уразливостей. Вплив може бути різним – залежить від природи вразливості.
Чим небезпечно: Для відомих уразливостей є експлойти, наприклад такі:
Що варто пам'ятати веб-розробнику: Регулярно повертайтеся до циклу: пошук відомих уразливостей – усунення – перевірка Якщо ви використовуєте застарілі бібліотеки свідомо, наприклад для підтримки старих браузерів або економії бюджету, шукайте можливість усунути відому вразливість. - Міжсайтові скрипти (XSS).
Cross-Site Scripting (XSS), або міжсайтові скрипти, - це атаки на веб-додаток, коли в результаті в базі даних з'являється шкідливість. Якщо Qualys знаходить таку вразливість, то потенційний зловмисник може впровадити або вже впровадив у код сайту свій js-скрипт для виконання шкідливих дій.Зберігають XSS (Stored XSS) більш небезпечні, оскільки скрипт впроваджується на сервері і виконується щоразу під час відкриття браузері атакованої сторінки.
Відображені XSS (Reflected XSS) простіше проводити, оскільки зловмисний скрипт можна впровадити в HTTP-запит. Додаток отримає HTTP-запит, не перевірить дані, запакує їх та негайно надішле. Якщо атакуючий перехопить трафік і вставить скрипт виду
<script>/*+что+то+плохое+*/</script>то від імені клієнта піде шкідливий запит.
Яскравий приклад XSS: js-сніфери, які імітують сторінки для введення CVC, терміну дії карти тощо.
Що варто пам'ятати веб-розробнику: У заголовку Content-Security-Policy використовуйте атрибут script-src, щоб браузер клієнта завантажував та виконував лише код із довіреного джерела. Наприклад, script-src 'self' вносить до білого списку всі скрипти тільки з нашого сайту.
Найкращою практикою вважається Inline code: дозвольте лише inline javascript за допомогою unsafe-inline. Таке значення дозволяє використовувати inline js/css, але не забороняє підключати js-файли. У комбінації із script-src 'self' ми забороняємо виконувати зовнішні сценарії.Обов'язково логіруйте все за допомогою report-uri та дивіться на спроби впровадження у сайт.
- SQL-ін'єкції.
Вразливість говорить про можливість впровадження на сайт коду SQL, який звертається безпосередньо до бази даних сайту. SQL-ін'єкція можлива, якщо дані від користувача не екрануються: не перевіряються на правильність і використовуються в запиті. Наприклад, так відбувається, якщо форма на сайті не перевіряє відповідність введення типу даних.Чим небезпечно: Якщо зловмисник введе в таку форму SQL-запит, може упустити базу даних або видати конфіденційну інформацію.
Що варто пам'ятати веб-розробнику: Не довіряйте тому, що надходить від браузера Захищатись потрібно і на стороні клієнта, і на стороні сервера.
На стороні клієнта напишіть перевірку полів за допомогою JavaScript.
Вбудовані функції в популярних кадрах також допомагають екранувати підозрілі символи на сервері. Також на сервері рекомендується використовувати параметризовані запити до баз даних.
Визначте, де саме відбувається взаємодія з базою даних на веб-додатку.
Взаємодія виникає, коли ми отримуємо будь-яку інформацію: запит із id (зміна id), створення нового користувача, новий коментар – нові записи в базі. Тут можуть виникати SQL-ін'єкції. Навіть якщо видаляємо запис з бази, можлива ін'єкція sql.
загальні рекомендації
Не вигадуйте велосипед – використовуйте перевірені фреймворки. Як правило, популярні фреймворки безпечніші. Для .NET – це ASP.NET MVC та ASP.NET Core, для Python – Django або Flask, для Ruby – Ruby on Rails, для PHP – Symfony, Laravel, Yii, для JavaScript – Node.JS- Express.js, для Java – Spring MVC.
Слідкуйте за оновленнями вендора та оновлюйте регулярно. Вразливість знайдуть, потім напишуть експлойт, викладуть у публічний доступ, і все повториться по-новому. Підпишіться на оновлення до стабільних версій від вендора.
Перевіряйте права доступу. З боку сервера завжди ставтеся до вашого коду так, ніби він весь, від першої до останньої літери, написаний вашим ненависним ворогом, що бажає зламати ваш сайт, порушити цілісність ваших даних. Тим більше, що іноді це справді так.
Використовуйте клони, тестові майданчики, а потім уже лийте на прод. Це допоможе, по-перше, уникнути ляпів і косяків на продуктивному середовищі: продуктивне середовище приносить гроші, простий продуктивного середовища критичний. При додаванні, виправленні або закритті будь-якої проблеми варто проводити роботи в тестовому оточенні, потім перевіряти функціональність і знайдені вразливості, а потім планувати роботи з продуктивним середовищем.
Захищайте веб-додаток за допомогою та інтегруйте з ним звіти від сканера вразливостей. Наприклад, в DataLine як зв'язки сервісів використовуються Qualys і FortiWeb.
Джерело: habr.com