Що таке OWASP Top-10?

При керуванні сайтом важливо знати найбільш значущі вразливості та загрози безпеці. Рейтинг OWASP Top-10 — відмінна відправна точка для ознайомлення з найсерйознішими загрозами для веб-застосунків, що існують на даний момент. OWASP (розшифровується як Open Web Application Security Project) — це онлайн-спільнота, яка випускає статті на тему безпеки веб-застосунків, а також документацію, різні інструменти та технології.

Що таке OWASP Top-10?

OWASP Top-10 – це список з десяти найпоширеніших наразі вразливостей веб-додатків. Завдяки цьому списку користувачі будуть обізнані про найбільш критичні ризики та загрози, їх наслідки та заходи протидії. Оновлюється список OWASP кожні три-чотири роки. Давайте познайомимося з ним ближче.

10 основних вразливостей OWASP:

Ін’єкційна атака

При ін’єкційній атаці зловмисник впроваджує неприпустимі дані у веб-додаток із наміром змусити його зробити щось, для чого програма не була розроблена/запрограмована.

Можливо, найпоширенішим різновидом цієї вразливості системи безпеки є впровадження коду через SQL-запит, який використовує ненадійні дані. Один із прикладів від OWASP Top-10 ви можете побачити нижче:

String query = “SELECT * FROM accounts WHERE custID = ‘” + request.getParameter(“id”) + “‘”;

Цей запит можна використовувати, викликавши веб-сторінку з URL http://example.com/app/accountView?id=’’ або 1’=’1, що призводить до повернення всіх рядків, що зберігаються в таблиці бази даних.

Головною причиною вразливості, пов’язаної з впровадженням коду, є відсутність перевірки та очищення даних, що використовуються веб-програмою. Це означає, що подібна вразливість може бути практично в будь-якому типі технологій.

Все, що приймає параметри в якості вхідних даних, потенційно може бути вразливим для атаки шляхом впровадження коду.

Ось ще один приклад SQL-впровадження, що торкнулося понад півмільйона сайтів, на яких було встановлено плагін YITH WooCommerce Wishlist для WordPress:

Наведене вище SQL-використання може призвести до серйозного витоку конфіденційних даних.

Як запобігти впровадженню коду?

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

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

Ось технічні рекомендації OWASP Top-10 щодо запобігання загрозі SQLi:

  • Для запобігання SQL-впровадженню дані потрібно зберігати окремо від команд та запитів.
  • Переважним варіантом є використання безпечного API, який повністю уникає застосування інтерпретатора або надає інтерфейс. Допускається також перехід використання інструментів об’єктно-реляційного відображення (ORM). Примітка: навіть при параметризації процедури, що зберігаються, все одно допускають SQL-впровадження, якщо PL/SQL або T-SQL об’єднують запити і дані.
  • Використовуйте позитивну перевірку (білий список) вхідних даних на стороні сервера. Це не дає вам повного захисту, оскільки багатьма програмами потрібні спеціальні символи.
  • Для будь-яких залишкових динамічних запитів екрануйте спеціальні символи, використовуючи синтаксис екранування цього інтерпретатора. Примітка: структури SQL (імена таблиць, імена стовпців тощо) не можуть бути екрановані, тому імена структур, що задаються користувачем, небезпечні. Це поширена проблема програмного забезпечення для написання звітів.
  • Використовуйте LIMIT та інші елементи керування SQL у запитах, щоб запобігти масовому розкриттю записів у разі SQL-впровадження.

З цих рекомендацій можна зробити два висновки:

  • Домагайтеся відокремлення даних від логіки веб-додатку.
  • Вводьте обмеження, щоб мінімізувати доступ до даних у разі успішних атак шляхом впровадження коду.

Ін’єкційні атаки є серйозним ризиком для власників сайтів, оскільки використовують лазівки в системі безпеки для крадіжки конфіденційної інформації.

Порушена автентифікація

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

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

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

  • /administrator у Joomla!,
  • /wp-admin/ у WordPress,
  • /index.php/admin в Magento,
  • /user/login у Drupal.

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

Типи некоректної автентифікації

Згідно з OWASP Top-10, подібна вразливість може виявлятися у багатьох формах. Веб-додаток містить несправну автентифікацію, якщо вона:

  • допускає автоматизовані атаки, такі як підбір чи автоматизоване заповнення облікових даних;
  • дозволяє використання стандартних, слабких чи добре відомих паролів, таких як Password1 чи admin/admin;
  • використовує слабкі чи неефективні процеси відновлення облікових даних та забутих паролів, у тому числі «відповіді на основі знань»;
  • не використовує багатофакторну автентифікацію;
  • надає ідентифікатори сеансу в URL;
  • не змінює ідентифікатори сеансу після успішного входу до системи;
  • не робить недійсними ідентифікатори сеансу. Сеанси користувачів або токени автентифікації (зокрема, токи єдиного входу (SSO)) не анулюються належним чином при виході з системи або в період бездіяльності.

Написання небезпечного програмного забезпечення, що містить подібні вразливості, можна пояснити багатьма факторами, наприклад, відсутністю досвіду у розробників, відсутністю вимог до безпеки або поспіху з випуском програмного забезпечення.

Як звести до мінімуму вразливість із порушеною автентифікацією?

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

Технічні рекомендації OWASP Top-10 полягають у наступному:

  • По можливості впроваджуйте багатофакторну автентифікацію, щоб запобігти автоматизованим атакам зловмисників.
  • Не використовуйте облікові дані за умовчанням, особливо це стосується облікових даних адміністраторів.
  • Введіть перевірку надійності паролів, включаючи тестування нових або змінених паролів за списком з 10 000 найгірших паролів.
  • Погодьте політику довжини, складності та ротації паролів із рекомендаціями NIST800-63 B або іншими сучасними політиками безпеки паролів.
  • Переконайтеся, що шляхи реєстрації та відновлення облікових даних захищені від атак перерахування облікових записів.
  • Обмежуйте або затримуйте невдалі спроби входу в систему. Реєструйте всі збої та попередьте адміністраторів при виявленні вкидання облікових даних, їх перебору або інших атак.
  • Використовуйте безпечний вбудований диспетчер сеансів, який після входу в систему генерує новий випадковий ідентифікатор високої ентропії. Ідентифікатори сеансу не повинні бути вказані в URL-адресі. Ідентифікатори також повинні бути надійно збережені та анульовані після виходу із системи або простою.

Незахищеність критичних даних

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

Приклади конфіденційних даних

Деякі конфіденційні дані, які потребують захисту:

  • номери кредитних карт,
  • медична інформація,
  • інформація, що дозволяє ідентифікувати особу (PII),
  • інша особиста інформація.

Для будь-якої організації життєво важливо розуміти важливість захисту інформації та конфіденційності користувачів. Усі компанії повинні дотримуватися місцевих законів про конфіденційність.

Відповідальне ставлення до збору та обробки конфіденційних даних стало більш помітним після появи загального регламенту захисту даних (GDPR). Цей новий закон про конфіденційність даних, який набув чинності у 2018 році, визначає, як компанії мають збирати, змінювати, обробляти, зберігати та видаляти персональні дані.

Існує два типи даних:

  • збережені дані – дані в стані спокою;
  • передані дані — дані, які передаються між серверами або веб-браузерами.

Обидва типи даних мають бути надійно захищені.

Захист даних, що передаються

Один із способів захистити передані дані на сайті – це наявність SSL сертифіката.

SSL – це абревіатура від Secure Sockets Layer. Це стандартна технологія безпеки для встановлення зашифрованого з’єднання між сервером та браузером. Сертифікати SSL допомагають захистити цілісність даних, що передаються між хостом (сервером або брандмауером) та клієнтом (браузером).

Які ризики розкриття конфіденційних даних

Ось кілька прикладів того, що може статися під час розкриття конфіденційних даних:

  • Сценарій №1. Програма автоматично шифрує номери кредитних карток у базі даних. Однак при отриманні ці дані автоматично розшифровуються, що дозволяє вразливості SQL-впровадження отримувати номери кредитних карток у вигляді відкритого тексту.
  • Сценарій №2. Сайт не використовує TLS для всіх сторінок або підтримує слабке шифрування. Зловмисник відстежує мережевий трафік (наприклад, у незахищеній бездротовій мережі), знижує рівень з’єднання з HTTPS до HTTP, перехоплює запити та краде файли cookie сеансу користувача. Потім зловмисник повторно відтворює ці файли cookie та перехоплює сеанс користувача (вже автентифікований), отримуючи доступ до особистих даних користувача.
  • Сценарій №3. База даних паролів використовує “несолоні” або прості хеші для зберігання паролів усіх користувачів. Помилка завантаження файлу дозволяє зловмиснику заволодіти базою даних паролів. Такі хеші можуть бути розкриті за допомогою райдужної таблиці попередньо розрахованих хешів. Хеші, згенеровані простими чи швидкими хеш-функціями, можуть бути зламані графічними процесорами, навіть якщо вони були «солоними».

Чому розкриття конфіденційних даних таке поширене?

За останні кілька років розкриття конфіденційних даних стало однією з найпоширеніших проблем у всьому світі. Ось деякі приклади витоків, які призвели до розкриття конфіденційних даних:

  • Кібератака на бразильську мережу магазинів модного одягу C&A, що відбулася у серпні 2018 року;
  • Злом Uber у 2016 році, в результаті якого було розкрито особисту інформацію 57 мільйонів користувачів Uber, а також 600 000 водіїв;
  • Витік даних зі сховища Target, внаслідок чого було розкрито інформацію про кредитні/дебетові картки та контактну інформацію близько 110 мільйонів осіб.

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

  • процесу генерації ключів;
  • процесу управління ключами;
  • використовуваного алгоритму;
  • протоколу, що використовується;
  • використовуваних шифрів;
  • методів зберігання паролів.

Цією вразливістю зазвичай дуже складно скористатися, проте наслідки успішної атаки жахливі.

Як запобігти розкриттю даних?

Запобігти розкриттю даних, згідно з OWASP Top-10, можна, дотримуючись наступних правил:

  • Класифікуйте дані, що обробляються, зберігаються або передаються програмою.
  • Визначте, які дані є конфіденційними відповідно до законів про конфіденційність, нормативних вимог чи бізнес-потреб.
  • Застосовуйте елементи керування відповідно до класифікації.
  • Не зберігайте конфіденційні дані без потреби. Дані, які не зберігаються, не можуть бути вкрадені.
  • Обов’язково шифруйте всі конфіденційні дані, які перебувають у стані спокою.
  • Забезпечте наявність сучасних та надійних стандартних алгоритмів, протоколів та ключів; використовуйте належне керування ключами.
  • Шифруйте всі передані дані за допомогою безпечних протоколів, таких як TLS, із безпечними параметрами та пріоритизацією шифрування сервером.
  • Вимкніть кешування для відповідей, які містять конфіденційні дані.
  • Зберігайте паролі, використовуючи потужні адаптивні та «солоні» функції хешування, наприклад Argon2, scrypt, bcrypt або PBKDF2.
  • Забезпечте незалежну перевірку ефективності конфігурації та налаштувань.

Зовнішні об’єкти XML (XXE)

Як написано у Вікіпедії, атака зовнішнього об’єкта XML – це тип атаки на програму за допомогою аналізу введення XML. Ця атака відбувається, коли введення XML, що містить посилання на зовнішній об’єкт, обробляється погано налаштованим синтаксичним аналізатором XML.

Більшість синтаксичних аналізаторів XML за умовчанням уразливі для XXE-атак. Відповідальність за те, щоб програма не містила цієї вразливості, лежить в основному на розробнику.

Які вектори атак на зовнішні об’єкти XML?

Згідно з OWASP Top-10, основні напрямки атаки зовнішніх об’єктів XML (XXE) включають використання:

  • вразливих XML-процесорів (зловмисники можуть завантажувати XML або включати шкідливий вміст у XML-документ);
  • вразливого коду;
  • вразливих залежностей;
  • вразливих інтеграцій.

Як запобігти атакам зовнішніх об’єктів XML

Для цього OWASP Top-10 рекомендує:

  • По можливості використовувати менш складні формати даних, такі як JSON, та уникати серіалізації конфіденційних даних.
  • Виправити або оновити всі процесори та бібліотеки XML, які використовуються програмою або базовою операційною системою.
  • Використовувати засоби перевірки залежностей (оновити SOAP до SOAP 1.2 або вище).
  • Вимкнути зовнішні об’єкти XML та обробку DTD у всіх синтаксичних аналізаторах XML у додатку відповідно до пам’ятки OWASP «Запобігання XXE».
  • Реалізувати позитивну перевірку («білий список») вхідних даних на стороні сервера та фільтрацію для запобігання використанню шкідливих даних у XML-документах, заголовках чи вузлах.
  • Переконайтеся, що функція завантаження XML або XSL-файлів перевіряє вхідний XML за допомогою XSD або аналогічного засобу.
  • Використовувати інструменти SAST, що може допомогти виявити XXE у вихідному коді (хоча ручна перевірка коду – найкраща альтернатива у великих та складних програмах з безліччю інтеграцій).

Якщо ці методи контролю з якихось причин нереалізовані, розгляньте можливість використання:

  • Віртуальних патчів.
  • Шлюзів безпеки API.
  • Міжмережевих екранів веб-додатків (WAFs), що дозволяють виявляти та блокувати XXE-атаки.

Порушення контролю доступу

У сфері безпеки сайтів контроль доступу – це обмеження доступу відвідувачів до окремих розділів або сторінок.

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

У наші дні це проблема багатьох основних систем управління вмістом (CMS). За замовчуванням доступ до сторінки входу адміністратора надається всім. Найчастіше не використовується навіть метод двофакторної аутентифікації (2FA).

Вищевикладене має змусити вас добре задуматися про безпеку програмного забезпечення, що розробляється вами.

Приклади порушеного контролю доступу

Ось кілька прикладів того, що ми включаємо в поняття «доступ»:

  • Доступ до панелі керування хостингом/адміністративної панелі.
  • Доступ до сервера через FTP/SFTP/SSH.
  • Доступ до адміністративної панелі сайту.
  • Доступ до інших програм на вашому сервері.
  • Доступ до бази даних.

Зловмисники можуть використати недоліки авторизації в таких цілях:

  • Доступ до неавторизованих функцій та/або даних.
  • Перегляд конфіденційних файлів.
  • Зміна прав доступу.

Якими є ризики порушення контролю доступу?

Ось кілька прикладів того, що, згідно OWASP Top-10, може статися при порушенні контролю доступу:

  • Сценарій №1. Програма використовує неперевірені дані у виклику SQL, який звертається до інформації про обліковий запис:

pstmt.setString(1,request.getParameter(“acct”)); ResultSetresults =pstmt.executeQuery( );

Зловмисник просто змінює параметр acct у браузері, щоб відправити будь-який номер облікового запису, який він хоче. У разі відсутності належної перевірки зловмисник може отримати доступ до облікового запису будь-якого користувача:

http://example.com/app/accountInfo?acct=notmyacct

  • Сценарій №2. Зловмисник просто переглядає цільові URL-адреси. Для доступу до сторінки адміністратора необхідні права адміністратора.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

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

Зниження ризиків порушення контролю доступу

Щоб знизити ризики, пов’язані з порушенням контролю доступу, ви можете зробити таке:

  • Використовуйте найменш привілейовані концепції – застосовуйте роль, відповідну задачі, і лише на час, необхідний для виконання зазначеного завдання, і не більше.
  • Позбавтеся облікових записів, які вам не потрібні. Ліквідуйте облікові записи користувачів, якщо останні більше не потребують їх.
  • Регулярно перевіряйте свої сервери та сайти – хто і що робив, коли і навіщо.
  • Якщо можливо, застосуйте багатофакторну автентифікацію до всіх точок доступу.
  • Відключіть точки доступу, поки вони не знадобляться, щоб просто зменшити їх кількість.
  • Видаліть непотрібні служби з сервера.
  • Порівняйте програми, доступні ззовні, із програмами, прив’язаними до вашої мережі.
  • Якщо ви розробляєте сайт, майте на увазі, що робоча версія не має бути місцем для тестування.

Запобігання порушенням контролю доступу

Щоб уникнути порушення контролю доступу, необхідно керуватися принципами безпеки при розробці та налаштуванні програмного забезпечення. Ось чому важливо контактувати з розробником і переконуватись у дотриманні ним вимог безпеки.

Технічні рекомендації OWASP Top-10 щодо запобігання порушенням контролю доступу:

  • Заборона має бути за замовчуванням, за винятком загальнодоступних ресурсів.
  • Впроваджуйте механізми керування доступом та використовуйте їх на всіх етапах роботи програми. Мінімізуйте використання CORS.
  • Елементи керування доступом мають забезпечувати право власності на записи. Не слід допускати того, щоб користувач міг створювати, читати, оновлювати чи видаляти будь-який запис. Наприклад, якщо користувач входить до системи як Джон, він може створювати, читати, оновлювати або видаляти тільки записи, пов’язані з ідентифікатором Джон, але не записи інших користувачів.
  • Вимкніть список каталогів веб-сервера та переконайтеся, що метадані файлів (наприклад, .git) та файли резервних копій відсутні в кореневому каталозі веб-сервера.
  • Реєструйте збої контролю доступу, за необхідності (наприклад, при збоях, що повторюються) попереджайте адміністраторів. Примітка: ми рекомендуємо для цього безкоштовний плагін для сайтів WordPress, який ви можете завантажити прямо з офіційного репозиторію WordPress.
  • Обмежте частоту запитів до API для мінімізації збитків від автоматизованих атак.
  • Токени JWT повинні бути анульовані на сервері після виходу із системи.
  • Розробники та тестувальники програмного забезпечення повинні включати функціональні блоки керування доступом та інтеграційні тести.

Небезпечна конфігурація

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

  • невиправлені недоліки;
  • конфігурації за замовчуванням;
  • наявність сторінок, що не використовуються;
  • незахищені файли та каталоги;
  • непотрібні служби.

Однією з найпоширеніших помилок веб-майстрів є збереження параметрів CMS за замовчуванням.

Сучасні програми CMS, будучи простими у використанні, можуть бути небезпечними для кінцевих користувачів. Більшість атак хакерів, безумовно, повністю автоматизовані, і зловмисники покладаються на те, що у користувачів виставлені налаштування за замовчуванням. Це означає, що велику кількість атак можна запобігти, змінивши при установці CMS налаштування за замовчуванням.

Права доступу до файлів — ще один приклад стандартного налаштування, який можна і потрібно посилити.

Де зустрічаються небезпечні конфігурації?

Невірні, з точки зору безпеки, конфігурації можуть бути на будь-якому рівні стека програми, включаючи:

  • Мережеві послуги.
  • Платформу.
  • Веб-сервер.
  • Сервер програм.
  • Базу даних.
  • Фреймворки.
  • Користувальницький код.
  • Попередньо встановлені віртуальні машини.
  • Контейнери.
  • Сховища.

Один з останніх прикладів неправильної конфігурації додатків – це сервери memcached, які використовуються для DDoS-атак на великі послуги в технологічній промисловості.

Приклади сценаріїв атак, які стали можливими через небезпечну конфігурацію

  • Сценарій №1. Сервер додатків поставляється із зразками додатків, які мають відомі недоліки безпеки. Зловмисники можуть використовувати їх для злому сервера. Якщо одним із цих додатків є консоль адміністратора (при цьому облікові записи за замовчуванням не були змінені), зловмисник входить до системи з паролями за замовчуванням та бере на себе керування.
  • Сценарій №2. Список каталогів на сервері не було вимкнено. Зловмисник виявляє, що може просто перерахувати каталоги. Він завантажує скомпільовані класи Java, які декомпілює та реконструює для перегляду коду.
  • Сценарій №3. Конфігурація сервера програм дозволяє повертати користувачам докладні повідомлення про помилки. Це потенційно розкриває конфіденційну інформацію, як-от версії компонентів.
  • Сценарій №4. Постачальник хмарних послуг має за замовчуванням дозволи на спільне використання. Це дозволяє зловмисникам отримати доступ до конфіденційних даних у хмарному сховищі.

Як отримати безпечні налаштування

Щоб запобігти атакам, пов’язаним з неправильними налаштуваннями безпеки, потрібно:

  • Повторюваний процес зміцнення, що дозволяє швидко і легко розгорнути нове безпечне середовище. Середовища розробки, контролю якості та робочого процесу повинні бути налаштовані однаково, але з використанням різних облікових записів. Автоматизуйте цей процес, щоб звести до мінімуму зусилля, необхідні для створення нового безпечного середовища.
  • Мінімальна платформа без будь-яких непотрібних функцій, компонентів, документації та зразків. Видаліть або не встановлюйте функції та кадри, які не використовуються.
  • Регулярні перевірки та оновлення конфігурацій відповідно до всіх вимог безпеки. Зокрема, перегляньте дозволи для хмарного сховища.
  • Сегментована архітектура програми, що забезпечує ефективний та безпечний поділ між компонентами або клієнтами.
  • Надсилання клієнтам директив безпеки.
  • Автоматизований процес перевірки ефективності конфігурацій та налаштувань у всіх середовищах.

Міжсайтовий скриптинг (XSS)

Міжсайтовий скриптинг (XSS) – широко поширена вразливість, яка стосується багатьох веб-додатків. XSS-атаки складаються з впровадження шкідливих клієнтських скриптів на сайт з подальшим використанням сайту як розповсюджувач.

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

Вразливість XSS присутня приблизно у двох третинах усіх програм.

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

Приклади вразливостей XSS

Уявіть, що ви, перебуваючи на панелі адміністратора WordPress, додаєте новий пост. Якщо ви використовуєте плагін із збереженою вразливістю XSS, хакер зможе змусити ваш браузер створити нового користувача адміністратора, поки ви знаходитесь в панелі wp-admin. Крім того, він може редагувати ваше повідомлення та виконувати інші подібні дії.

Вразливість XSS дає зловмисникові майже повний контроль над найважливішим наразі програмним забезпеченням комп’ютерів – браузерами.

Типи XSS

Згідно з OWASP Top-10, існує три типи міжсайтового скриптингу:

  • Відбиті XSS: додаток або API включає неперевірений і неекранований користувацький ввід як частину виведення HTML. Успішна атака дозволить зловмиснику завантажити довільний HTML та виконати JavaScript у браузері жертви. Як правило, користувачеві необхідно взаємодіяти з будь-яким шкідливим посиланням, яке вказує на сторінку, контрольовану зловмисником.
  • Збережений XSS: програма або API зберігає неочищене введення користувача, яке пізніше переглядається іншим користувачем або адміністратором. Збережений XSS-код часто вважається високим або критичним ризиком.
  • DOM XSS: JavaScript-фреймворки, односторінкові програми та API, які динамічно включають дані, контрольовані зловмисником, вразливі для DOM XSS.

Зниження ризиків XSS

Типові XSS-атаки включають крадіжку сеансу, захоплення облікового запису, обхід MFA, заміну DOM-вузла, атаки на браузер користувача, включаючи завантаження шкідливого програмного забезпечення, кейлоггінг та інші атаки на стороні клієнта.

Як запобігти проблемам, викликаним XSS-вразливістю

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

  • Використовуйте фреймворки, які завдяки своїй «конструкції» автоматично уникають XSS. До таких фреймворків відноситься, наприклад, остання версія Ruby on Rails. Вивчіть обмеження XSS-захисту кожного фреймворку та вживіть відповідних заходів.
  • Екранування ненадійних даних HTTP-запиту на основі контексту у вихідних даних HTML (тіло, атрибут, JavaScript, CSS або URL) дозволить усунути відбиті та збережені вразливості XSS. Посібник OWASP щодо запобігання XSS містить докладні відомості про способи екранування даних.
  • Застосування контекстно-залежного кодування при зміні документа браузера за клієнта діє проти DOM XSS. Коли цього не можна уникнути, до API-інтерфейсів браузера можна застосувати контекстно-залежні методи екранування, аналогічні тим, що описані в посібнику OWASP щодо запобігання XSS на основі DOM.
  • Включення політики безпеки вмісту (CSP) – це комплексний захист, що знижує ризик XSS-атак. Вона ефективна, якщо не існує інших вразливостей, які б дозволили розмістити шкідливий код через локальні файли.

Небезпечна десеріалізація

У OWASP Top-10 наголошується, що ця вразливість була додана до списку на підставі результатів галузевого опитування, а не на підставі дослідження даних, що піддаються кількісній оцінці.

Кожному веб-розробнику слід змиритися з тим, що зловмисники намагатимуться «грати» з усім, що взаємодіє з його додатком, — від URL-адрес до серіалізованих об’єктів.

Щоб спростити розуміння деяких ключових понять, познайомимо вас із прийнятою термінологією:

  • В інформатиці об’єкт – це структура даних, а точніше спосіб структурування даних.
  • Процес серіалізації – це перетворення об’єктів у байтові рядки.
  • Процес десеріалізації – це перетворення байтових рядків на об’єкти.

Приклади сценаріїв десеріалізаційної атаки

  • Сценарій №1. Програма React викликає набір мікросервісів Spring Boot. Як функціональні програмісти, розробники намагалися забезпечити незмінність свого коду. Рішення, яке вони вигадали, — це серіалізація стану користувача та його передача туди та назад з кожним запитом. Зловмисник помічає сигнатуру об’єкта «R00» та використовує інструмент Java Serial Killer для віддаленого виконання коду на сервері програм.
  • Сценарій №2. PHP-форум використовує серіалізацію об’єкта PHP для збереження “супер” cookie, що містить ідентифікатор користувача, його роль, хеш пароля та інші стани:

a:4:{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”;

i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}

Зловмисник змінює серіалізований об’єкт, щоб отримати права адміністратора:

a:4:{i:0;i:1;i:1;s:5:”Alice”;i:2;s:5:”admin”;

i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88bc960″;}

Одним із векторів атаки, як ви бачите, є суперфайл cookie, що містить серіалізовану інформацію про користувача, що увійшов до системи. Цей файл cookie містить роль користувача.

Якщо зловмисник успішно десеріалізує даний об’єкт, він потім змінить права користувача, надавши собі роль адміністратора, і знову серіалізує об’єкт. Цей набір дій може поставити під загрозу всю веб-програму.

Як запобігти небезпечній десеріалізації

Найкращий спосіб захистити вашу веб-програму від ризику такого типу – не приймати серіалізовані об’єкти з ненадійних джерел.

Якщо ви не можете цього зробити, OWASP Security надає додаткові технічні рекомендації, які можна спробувати реалізувати:

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

Використання компонентів з відомими вразливостями

У наші дні навіть прості сайти, такі як особисті блоги, мають багато залежностей.

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

Наприклад, у 2019 році 56% усіх програм CMS на момент їх зараження були застарілими.

Чому ми не оновлюємо наше програмне забезпечення вчасно? Чому сьогодні це все ще така величезна проблема?

Є кілька варіантів відповіді на це запитання, наприклад:

  • Веб-майстри/розробники не встигають за оновленнями (врешті-решт, правильне оновлення потребує часу).
  • Застарілий код не працюватиме з новішими версіями своїх залежностей.
  • Веб-майстри бояться, що їхній сайт перестане правильно функціонувати.
  • У веб-майстрів немає досвіду, щоб правильно встановити оновлення.

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

Якою б не була причина використання застарілого програмного забезпечення у вашій веб-програмі, ви не можете залишити його незахищеним. І Sucuri, і OWASP Top-10 рекомендують віртуальні патчі у випадках, коли внесення виправлень неможливе.

Віртуальні патчі дозволяють захистити застарілі (або відомі вразливості) сайти від атак, запобігаючи використанню цих вразливостей на льоту. Зазвичай це робиться за допомогою брандмауера та системи виявлення вторгнень.

Вразливі програми

Відповідно до рекомендацій OWASP Top-10 програми можна вважати потенційно вразливими, якщо:

  • Програмне забезпечення не підтримується чи застаріло. Під програмним забезпеченням у цьому випадку слід розуміти ОС, веб-сервер/сервер додатків, систему керування базами даних (DBMS), програми, API, а також усі компоненти, середовища та бібліотеки.
  • Ви не знаєте версії всіх компонентів, що використовуються (як на стороні сервера, так і на стороні клієнта). Йдеться про компоненти, які ви використовуєте безпосередньо, а також про вкладені залежності.
  • Ви не оновлюєте своєчасно базову платформу, фреймворки та залежності. Це зазвичай відбувається у середовищах, де встановлення виправлень виконується щомісяця чи щокварталу, що залишає організацію вразливою багато днів і навіть місяці.
  • Розробники програмного забезпечення не перевіряють сумісність оновлених чи виправлених бібліотек.
  • Ви не забезпечуєте безпеку конфігурацій компонентів.

Як уникнути використання компонентів з відомими вразливостями

Ось деякі із способів уникнути використання вразливих компонентів:

  • Видаліть усі непотрібні залежності.
  • Проведіть інвентаризацію всіх ваших компонентів як на стороні сервера, так і на стороні клієнта.
  • Слідкуйте за такими джерелами, як Common Vulnerabilities and Disclosures (CVE) та National Vulnerability Database (NVD), для знайомства з новими вразливими компонентами.
  • Купуйте компоненти лише з офіційних джерел.
  • Позбавтеся компонентів, які активно не використовуються.
  • Використовуйте віртуальні патчі.

Неефективний моніторинг

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

Відсутність ефективного моніторингу може призвести до збільшення збитків від злому сайту.

Приклади атак, які стали можливими через неефективний моніторинг

Ось кілька прикладів сценаріїв атак, причиною яких можна вважати недостатній моніторинг:

  • Сценарій №1. Форум з відкритим кодом, керований невеликою командою, був зламаний з використанням вразливості в його програмному забезпеченні. Зловмисникам вдалося знищити внутрішній репозиторій із усім вмістом форуму. Вміст можна відновити, але відсутність моніторингу призвела до значно серйозніших наслідків. У результаті форум проекту не активний.
  • Сценарій №2. Зловмисник шукає користувачів із спільним паролем. Він може отримати доступ до всіх облікових записів із цим паролем. Для всіх інших користувачів це сканування залишає лише один хибний вхід до системи. Через кілька днів він може повторити те саме з іншим паролем.
  • Сценарій №3. Великий американський рітейлер мав внутрішню «пісочницю» для аналізу вкладень з метою пошуку шкідливого програмного забезпечення. «Програма-пісочниця» виявила потенційно небажане програмне забезпечення, але ніхто не відреагував на це. Протягом деякого часу “пісочниця” видавала попередження. Продовжувалося це доти, доки не було виявлено шахрайських транзакцій картами зовнішнього банку.

Як забезпечити ефективний моніторинг сайту

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

Залиште свої дані. Вам надійде лист з посиланням для входу.



    Натискаючи на кнопку, я погоджуюсь з умовами політики конфіденційності.

    Веб-сайт використовує файли cookies. Мета — маркетинг і аналіз трафіку. Тут можете дізнатися більше.
    Детально Приймаю