Що таке OWASP TOP 10?

OWASP TOP 10 2021: аналіз вразливостей

OWASP TOP 10 — це список найпоширеніших загроз та вразливостей веб-додатків, який оновлюється кожні 3-4 роки. Перша редакція була опублікована у 2010 році. Друга — у 2013-му році. Третя — 2017-го. І остання, на даний час, четверта редакція вийшла у 2021 році.

Порівняння списку OWASP 10 2021 року з 2017-м

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

A1: Broken Access Control

Безпека контролю доступу до даних системи. Це історія про те, коли в системі некоректно налаштовані рівні та права доступу, чим можуть скористатися зловмисники. В захищеній системі чітко розмежовані привілеї адміністраторів, користувачів і відвідувачів. Детально регламентовані користувацькі ролі.

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

• In Role-Based Access Control (RBAC) — керування доступом на основі ролей. Формування ролей покликане визначити чіткі та зрозумілі для користувачів комп’ютерної системи правила розмежування;
• Discretionary Access Control (DAC) — вибіркове (контрольоване) управління доступом. Формується на основі списку (ACL), який визначає, хто або що може отримувати доступ до того чи іншого об’єкта (файлу, програми, процесу), і які саме операції можна або заборонено виконувати суб’єкту (користувачу, групі користувачів);
• Mandatory Access Control (MAC) — управління доступом на основі виданих дозволів (допуску, мандата). Наприклад, така система дозволяє заборонити або навпаки дозволити тому чи іншому користувачу системи доступ до відповідної інформації, процесів, пристроїв більш захищеного рівня, яким володіють адміністратори.

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

1. Administrator
2. Editor
3. Author
4. Contributor
5. Subscriber

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

A2: Cryptographic Failures

Безпека і шифрування даних. Це пов’язано з ризиками, які виникають при зберіганні конфіденційних, персональних, чутливих даних. У попередній редакції ця частина мала назву — Sensitive Data Exposure. Тобто те, що призводить до витоків даних.

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

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

Під шифруванням мається на увазі і протоколи HTTPS, SSL, TLS. І алгоритми SHA/AES. І ключі шифрування повідомлень: PKI/PGP, OTR, OMEMO та ін. Хешування паролей MD5 (md5.salt). Усюди, де зберігаються і передаються дані — має бути закладено криптографічне перетворення даних, що захистить їх навіть після перехвату.

Зрештою, усі ці принципи детально описані в регуляторських стандартах, таких як GDPR та PCI-DSS.

A3: Injection

Йдеться про ін’єкції коду — один із найнебезпечніших та розповсюджених типів кібер-атак. Зловмисник, скориставшись вразливістю системи, пробує “підживити” вірусний код у тіло, структуру сайту, додатку, електронного ресурсу.

Існують декілька видів ін’єкцій коду:

• SQL ін’єкція — це ін’єкція в базу даних SQL (MySQL, MariaDB, PostgreSQL тощо);
• PHP ін’єкція — це ін’єкція в PHP-код, використовується вразливість у веб-застосунку, написаному мовою програмування PHP. Зловмисник використовує вразливість різних старих версій PHP та недостатню захищеність веб-сервера;
• XML ін’єкція (XXE) — це ін’єкція в XML-код, використовуючи вразливості XML-розмітки та XML-документів;
• XSS ін’єкція (Cross Site Scripting) — це ще один популярний вид ін’єкції, який полягає у використанні JavaScript-коду, спроби формувати з його допомогою HTTP/GET запити, викликаючи навантаження, збій сервера. Спроби подавати JS-код на текстові форми і поля вводу, вбудовувати їх в тіло, DOM-структуру веб-сторінки, документа.

Захиститись від подібних ін’єкцій допоможуть вищевикладені способи шифрування (захищені протоколи HTTPS/SSL/TLS), так і відповідне налаштування сервера, як от перевірка і фільтрація усіх вхідних символів/запитів. Блокування аномальних, підозрілих дій, ботів, User-Agent’ів. Впровадження усіх необхідних HTTP-заголовків безпеки, включаючи HSTS (Strict Transport Security)— унеможливлює доступ до сайту по незахищеному HTTP-протоколу.

A4: Insecure Design

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

Існує близько 20-ти методологій, де розписані деталі і принципи Secure Design (Архітектури Безпеки). Кожна частина вашого продукту, її фундамент і каркас має бути спроєктована з дотриманням безпеки. Також архітектура має бути гнучкою і постійно оновлюватись, не впливаючи на продуктивність. Усе це, цеглина за цеглиною, має закладатися на самих початках, щоби не довелося потім переробляти “з нуля”.

Власне, вразливість Insecure Design виникає тоді, коли Фронтенд і Бекенд недостатньо захищені, містять помилки і баги. Коли алгоритми, логіка нечітко продумані, а QA-тестери недостатньо якісно протестувати усі можливі сценарії й випадки. Буває й коли продукт пишеться різними програмістами, де різні часточки коду не схожі за стилем та рівнем, можуть бути несумісними і породжувати баги, якими потім користаються хакери. І не завжди варто сподіватись тільки на баг-хантерів, які добровільно баг знайдуть і повідомлять про це. Часто-густо проходить кілька місяців, а то й років, перш ніж баг офіційно десь оприлюднять і розробники випустять патч.

A5: Security Misconfiguration

Порівняно з 2017-м, цей пункт піднявся на одну сходинку. Security Misconfiguration — це некоректно, хибно налаштована конфігурація, а саме:

• Конфігурація сервера, наприклад файл .htacess (Apache) або vhost (NGINX);
• Помилки в конфігурації PHP (файл php.ini) — відсутність оновлення, необхідних модулів безпеки, несумнісність з іншими модулями/компонентами системи;
• Некоректно налаштована і не захищена SQL-база даних;
• Некоректно налаштовані або не оновлена бекенд-частина: операційна система, сервіси, утиліти, програми, фреймворки, плагіни, компоненти, модулі, бібліотеки і так далі. Усе це може містити критичні вразливості й створювати баги безпеки;
• Не захищені належним чином мережеві TCP/UDP порти і інтерфейси (особливо це стосується, SSH/FTP/RDP/SQL), відкритий доступ до конфіденційних файлів, журналів, адмінок, мережевих і хмарних сховищ (частково це описується в A1: Access Broken Control);
• Некоректні або відсутні HTTP-заголовки безпеки в електронного ресурсу (прочитати можна в проєкті OWASP Security Headers);
• Некоректно налаштована DNS-зона, помилки в записах та налаштуванні субдоменів, відсутність SPF, DMARC, DKIM підписів безпеки сервера тощо.

Щоби запобігти Security Misconfiguration необхідно регулярно адмініструвати, оновлювати, здійснювати технічний супровід і обслуговування сервера, проводити регулярний аудит з кібербезпеки. Варіант створив сайт і забув — не пройде. Необхідно регулярно слідкувати за системними журналами помилок, зокрема access.log і error.log, недопускати PHP-помилок, виправляти їх, моніторити відвідуваність/трафік з допомогою таких централізованих систем як Zabbix, Graffana, Goaccess. Усе це клопітка, щоденна праця, яка повністю виправдовує себе з точки зору безпеки.

A6: Vulnerable and Outdated Components

Вразливі та застарілі компоненти. Фактично, про цю вразливість сказано у попередній частині. Суть зводиться до того, що не можна нехтувати регулярними оновленнями компонентів, плагінів, які випускають розробники. А ті компоненти, які не оновлюються, тобто застарілі версії — краще замінити іншими. Як показує статистика, більшість WordPress-сайтів зламуються там, де є старі версії і вразливі компоненти. Їх можна виявити з допомогою популярного сканера вразливостей — WPscan.

A7: Identification and Authentification Failures

Безпека ідентифікації і аутентифікації користувачів. Іншими словами, безпека входу на сайт.

Ідентифікація — це процедура розпізнавання користувача по заявленому ним ідентифікатору.

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

Аутентифікацію не варто плутати з Авторизацією — процедурою надання суб’єкту певних прав, тобто кінцевим допуском.

Вразливість “Identification and Authentification Failures” виникає там, де неналежним чином забезпечена безпека всіх процедур – Ідентифікації, Аутентифікації і Авторизації. Недоліки аутентифікації дозволяють зловмисникам уникнути перевірки облікових даних, підробити їх та проникнути в систему. Тому механізм аутентифікації має бути чітко та грамотно спроєктований (A4: Insecure Design).

Приклади відповідних заходів безпеки:

• Недопускати, щоби користувачі використовували слабкі паролі;
• Недопускати повторної реєстрації на облікові дані, які вже існують в системі, тобто повторна реєстрація (одного разу зі мною таке трапилося);
• Заборонити реєстрацію з використанням деяких невидимих або спеціальних символів (які можуть використовуватися для ін’єкцій, A3: Injection), пустих пробілів і таке подібне;
• Заборонити реєстрацію облікових записів зі службовими іменами: root, admin, administrator та ін.;
• Забезпечити, щоби усі користувацькі дані в системі надійно шифрувалися;
• Додати обов’язкову підтримку двоетапної авторизації (2FA) або мультифакторної авторизації (MFA), або OTP (One Time Password).
• Підключити систему reCaptcha, яка буде відстежувати і блокувати ботів та будь-які спроби несанкціонованого доступу (Limit Login Attempts, Обмеження невдалих спроб входу);
• Застосовувати унікальні CSRF-токени для аутентифікації будь-яких дій;
• Запобігти брутфорс-атакам (перебор символів) та заборонити енумерацію користувачів;
• Чітко регламентувати Політику видалення/відновлення облікових записів, Зберігання даних користувачів, Політику відновлення забутого паролю (дуже важливо). Як часто можна змінювати пароль, його мінімальна і максимальна довжина.

A8: Software and Data Integrity Failures

Новий пункт, який з’вився в редакції 2021-го року. Пов’язаний у першу чергу з так-званими CI/CD процесами — Continous Integration and Continous Delivery, що означає Безперервну інтеграцію і відправку. Усе разом — Коцепція безперервного розгортання. Те, що так полюбляють DevOps. На цій концепції побудовано більшість веб-сервісів і додатків. З приходом кібербезпеки ця коцепція названа — DevSecOps.

Основне завдання — запобігти вразливості коду на будь-яких стадіях продукту. Забезпечити статичне сканування коду (SAST) на наявність вірусів — malware/ransomware. Вчасно і безпечно виправляти будь-які недоліки, щоб це жодним чином не вплинуло на якість продукту. Здійснювати автоматичну перевірку усіх репозиторіїв.

Загалом, це стандартна площина DevOps з сильним ухилом в кібербезпеку.

A9: Security Logging and Monitoring Failures

Моніторинг і логування системи, реагування на інциденти. Це знову ж таки було частково описано в A5: Security Misconfiguration. Хоча, у даному випадку йдеться саме про журналювання всіх процесів, які відбуваються в системі й активне спостереження за ними.

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

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

У потужних корпоративних системах використовуються для цього спеціальні SIEM-системи — Security Information and Event Manangement, які забезпечують аналіз усіх подій в реальному часі.

A10: Server Side Request Forgery (SSRF)

Порівняно новий пункт. Перекдається як Міжсерверна підробка запитів. Зловмисник від імені вразливого сервера може виконувати різні шкідливі операції — як всередині мережі (Remote Code Execution, Віддалене виконання коду), так й по відношенню до інших серверів/ресурсів (DDOS-атаки через бот-нет).

Доступ до вразливого сервера відбувається з різноманітних причин: відкриті порти і неправильна конфігурація (A5: Security Misconfiguration), застарілі компоненти (A6: Vulnerable and Outdated Components), помилки в правах доступу (A1: Broken Access Control), відсутність систем захисту (WAF/NGFW). З допомогою енумерації, брутфорсу та експлойтів хакер пробирається на сервер і повністю або частково ним заволодіває.

Щоби запобігти цьому, рекомендується повністю виконати усі рекомендації попередніх пунктів, надійно приховати адміністративну частину, а також встановити обов’язкові модулі та улиліти безпеки, такі як ModSecurity, IPtables, Fail2ban, CSF Firewall та інші. Вони будуть автоматично реагувати на будь-які спроби несанкціонованого доступу, згідно виставлених вами правил, й блокувати порушників.

Висновки

Таким чином, беручи до уваги усі пункти, викладені в OWASP TOP 10, сумлінно виконуючи рекомендації, ви з успіхом зможете захистити власні сайти, сервери, додатки та інші електронні ресурси від хакерів й зловмисників, яких сьогодні розвелось чимало.

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