Open Web Application Security Project (OWASP) - це відкритий проект забезпечення безпеки веб-додатків. Спільнота OWASP включає в себе корпорації, освітні організації і приватних осіб з усього світу. Спільнота працює над створенням статей, навчальних посібників, документації, інструментів і технологій, які перебувають у вільному доступі.
Список OWASP Топ-10 заснований на восьми базах даних від семи компаній, включаючи чотири консалтингові фірми і трьох вендорів SaaS. Загальна база містить понад 500 000 вразливостей в сотнях організацій та тисячах додатків.
A1 Впровадження коду
A2 Некоректна аутентифікація і управління сесією
A3 Міжсайтовий скриптинг (XSS)
A4 Небезпечні прямі посилання на об'єкти
A5 Небезпечна конфігурація
A6 Витік чутливих даних
A7 Відсутність контролю доступу до функціонального рівня
A8 Підробка міжсайтових запитів (CSRF)
A9 Використання компонентів з відомими уразливими
A10 Невалідірованние редіректи
Всі дані, як правило, зберігаються в спеціальних базах, звернення до яких будуються у вигляді запитів, найчастіше написаних на спеціальній мові запитів SQL (Structured Query Language - структурована мова запитів).
Додатки використовують SQL-запити для того, щоб отримувати, додавати, змінювати або видаляти дані, наприклад при редагуванні користувачем своїх особистих даних або заповненні анкети на сайті. При недостатній перевірці даних від користувача, зловмисник може впровадити в форму Web-інтерфейсу додатку спеціальний код, що містить шматок SQL-запиту.
Наприклад, змінити разом з ім'ям і прізвищем баланс свого рахунку, подивитися баланс чужого рахунку, або ж, викрасти конфіденційні особисті дані.
Ця вразливість є наслідком недостатньої перевірки даних, що надходять від користувача. Це дозволяє зловмисникові #xAB; підсунути # xBB ;, наприклад, в веб-форми, спеціально підготовлені запити, які #xAB; обдурять # xBB; додаток і дозволять прочитати або записати нелегітимні дані.
В цілому цей різновид атак має загальну назву #xAB; Помилки валідації # xBB ;, до неї відносяться далеко не тільки SQL-ін'єкції і ми будемо згадувати цей вектор ще не раз.
Недоліки системи аутентифікації і зберігання сесій (Broken Authentication and Session Management)
Міжсайтовий скриптинг - XSS (Cross Site Scripting)
По-перше, зловмисник може вкрасти вашу сесійний cookie, наслідки чого були описані в другому пункті, буквально парою абзаців вище. Потрібно відзначити, що далеко не всі сервери додатків уразливі до даного типу атак, про це ми окремо поговоримо в пункті під номером 5.
По-друге, можуть бути вкрадені дані, що вводяться у форми на зараженій сторінці. А це можуть бути конфіденційні персональні дані, або, що ще гірше, дані кредитної картки разом з CVC-кодом.
Небезпечні прямі посилання на об'єкти (Insecure Direct Object References)
Небезпечна конфігурація (Security Misconfiguration)
Крім того, програмне забезпечення повинно бути в актуальному стані: уразливості знаходять кожен день в самих різних програмних компонентах - операційній системі, web-серверах, серверах баз даних, поштових серверах і т.д. І навіть якщо ваш додаток правильно написано і ретельно перевіряє всі вхідні дані, і взагалі, добре захищене, це не означає що в один прекрасний момент не знайдеться вразливість у вашій ОС або Web-сервері.
Незахищеність критичних даних (Sensitive Data Exposure)
Багато веб-додатки не захищають конфіденційні дані, такі як кредитні карти і облікові дані для аутентифікації. Зловмисники можуть вкрасти або модифікувати такі слабо захищені дані для використання в своїх корисливих цілях.
Найпростіший приклад - передача даних по протоколу HTTP. Справа в тому, що дані передаються по протоколу HTTP ніяк не зашифровано, а при проходженні даних від комп'ютера користувача до Web-сервера, дані пройдуть досить багато різних вузлів: маршрутизатор офісу або домашній роутер, маршрутизатор провайдера, маршрутизатор на каналі, маршрутизатор в дата- центрі хостинг-провайдера сервера і так далі. На кожному з цих вузлів може зачаїтися зловредів, так званий сниффер, програма, яка зчитує весь трафік і передає зловмисникові. А останній переглядає отримані дані на предмет персональних даних та даних кредитних карт.
Ще одне завдання SSL-сертифіката (а саме так називається спеціальний ключ, за допомогою якого здійснюється перевірка справжності та шифрування в HTTPS) - підтвердити, що він виданий саме для даного сайту. У разі, якщо сертифікат прострочений або підроблений, Ви побачите наступну картину:
Інший приклад - відсутність шифрування критичних даних, таких як паролі або номери кредитних карт. У разі, якщо дані зашифровані, то навіть у разі отримання несанкціонованого доступу на сервер, зловмисник не зможе вкрасти критичні дані. До паролів, зокрема, повинна застосовуватися необоротна хеш-функція - розшифрувати шифрограму при цьому не можливо і перевірка пароля відбувається шляхом формування шифрограми введеного пароля і порівняння її з наявною в базі.
Відсутність функцій контролю доступу (Missing Function Level Access Control)
Суть уразливості, як випливає з назви, полягає у відсутності перевірки наявності належного доступу до запитуваного об'єкту.
Більшість веб-додатків перевіряють права доступу, перш ніж відобразити дані в інтерфейсі. Проте, додатки повинні виконувати ті ж перевірки контролю доступу на сервері при запиті будь-якої функції. Адже є ще безліч допоміжних прохання про надання послуг, які, найчастіше відправляються в фоновому режимі асинхронно, за допомогою технології AJAX.
Якщо параметри запиту не досить ретельно перевіряються, зловмисники зможуть підробити запит для доступу до даних без належного дозволу.
Приватний, і мабуть, найпоширеніший випадок даної уразливості ми вже розглянули в 4 пункті нашої статті - відсутність перевірки користувача в особистих повідомленнях.
Міжсайтовий підробка запиту (Cross-Site Request Forgery, CSRF / XSRF)
Вектор атаки CSRF, також відомий як XSRF, дозволяє зловмиснику виконувати від імені жертви дії на сервері, де не реалізовані додаткові перевірки.
Якщо жертва заходить на сайт, створений зловмисником, від її особи таємно відправляється запит на вищевказану сторінку платіжної системи. Як результат - гроші підуть на рахунок зловмисника, після чого, ймовірно, будуть оперативно обміняні на Bitcoin або переведені в іншу безповоротну платіжну систему, і отримати їх назад вже не вийде.
Передбачається, що жертва повинна була попередньо пройти аутентифікацію в платіжній системі і повинна бути відкрита активна сесія (скажімо, сторінка платіжної системи відкрита в іншій вкладці браузера).
Вирішується проблема досить просто і про це ми розповімо в окремій статті, присвяченій CSRF.
Використання компонентів з відомими уразливими (Using Components with Known Vulnerabilities)
Найчастіше web-додатки написані з використанням спеціальних бібліотек або #xAB; фреймворків # xBB; (Англ - framework), які поставляються сторонніми компаніями. У більшості випадків ці компоненти мають відкритий вихідний код, а це означає, що вони є не тільки у вас, але і у мільйонів людей у всьому світі, які студіюють їх вихідний код, в тому числі, і на предмет вразливостей. І потрібно відзначити, що роблять вони це аж ніяк не безуспішно.
Також уразливості шукають (і знаходять) в більш низькорівневих компонентах системи, таких як сервер бази даних, web-сервер, і нарешті, компоненти операційної системи аж до її ядра.
Дуже важливо використовувати останні версії компонентів і стежити за з'являються відомими уразливими на сайтах типу securityfocus.com.
Цей вид вразливостей, також як і багато інших перераховані вище, є різновидом помилок перевірки вхідних даних (input validation).