OWASP або Open Web Security Project - це некомерційна благодійна організація, орієнтована на підвищення безпеки програмного забезпечення та веб-додатків.
Організація публікує список найпопулярніших вразливих місць веб-безпеки на основі даних різних захисних організацій.
Вразливості веб-безпеки отримують пріоритети залежно від можливості використання, виявлення та впливу на програмне забезпечення.
- Експлуатаційність -
Що потрібно для використання вразливості системи безпеки? Найвища експлуатаційність, коли для атаки потрібен лише веб-браузер, а найнижча - це вдосконалене програмування та інструменти.
- Виявленість -
Наскільки легко виявити загрозу? Найвища - інформація, що відображається в URL-адресі, формі або повідомленні про помилку, а найнижча - вихідний код.
- Вплив або збиток -
Скільки шкоди буде завдано, якщо вразливість системи безпеки буде виявлена або атакована? Найвищий - повний збій системи, а найнижчий - взагалі нічого.
Основною метою OWASP Top 10 є навчання розробників, дизайнерів, менеджерів, архітекторів та організацій про найважливіші вразливі місця безпеки.
Топ-10 вразливих місць безпеки згідно з OWASP Top 10:
- Ін'єкція SQL
- Міжсайтові сценарії
- Порушена аутентифікація та управління сесіями
- Небезпечні прямі посилання на об’єкти
- Підроблення запиту між сайтами
- Неправильна конфігурація безпеки
- Небезпечне криптографічне сховище
- Неможливість обмежити доступ до URL-адреси
- Недостатній захист транспортного шару
- Неперевірені перенаправлення та переадресація
Ін'єкція SQL
Опис
Ін’єкція - це уразливість системи безпеки, яка дозволяє зловмисникові змінювати серверні SQL-оператори, маніпулюючи наданими користувачем даними.
Вприскування відбувається, коли введення даних користувача надсилається інтерпретатору як частина команди або запиту, і обманює інтерпретатор виконувати ненавмисні команди та надає доступ до несанкціонованих даних.
Команда SQL, яка при виконанні веб-додатком може також відкрити внутрішню базу даних.
Наслідування
- Зловмисник може вводити шкідливий вміст у вразливі поля.
- Конфіденційні дані, такі як імена користувачів, паролі тощо, можуть бути прочитані з бази даних.
- Дані бази даних можна змінювати (Вставити / Оновити / Видалити).
- Операції адміністрування можуть виконуватися в базі даних
Вразливі об'єкти
- Поля введення
- URL-адреси, що взаємодіють з базою даних.
Приклади:
- Введення SQL на сторінці входу
Вхід у програму без наявності дійсних облікових даних.
Дійсне ім'я користувача доступне, а пароль недоступний.
Тестова URL-адреса: http://demo.testfire.net/default.aspx
Ім'я користувача: sjones
Пароль: 1 = 1 'або пропуск123
SQL-запит, створений та надісланий Interpreter, як показано нижче
ВИБЕРІТЬ * ВІД користувачів, ДЕ Ім'я користувача = sjones І Пароль = 1 = 1 'або pass123;
Рекомендації
- Білий перелік полів введення
- Не показуйте докладні повідомлення про помилки, корисні зловмиснику.
Міжсайтові сценарії
Опис
Міжсайтові сценарії також скоро називають XSS.
Вразливості XSS цільові сценарії, вбудовані в сторінку, які виконуються на стороні клієнта, тобто браузер користувача, а не на стороні сервера. Ці недоліки можуть виникати, коли програма бере ненадійні дані та надсилає їх у веб-браузер без належної перевірки.
Зловмисники можуть використовувати XSS для запуску шкідливих скриптів для користувачів, у цьому випадку браузерів жертв. Оскільки браузер не може знати, чи сценарій надійний чи ні, сценарій буде виконаний, і зловмисник може викрасти файли cookie сеансу, зіпсувати веб-сайти або перенаправити користувача на небажані та шкідливі веб-сайти.
XSS - це атака, яка дозволяє зловмиснику виконувати сценарії в браузері жертви.
Наслідок:
- Використовуючи цю вразливість системи безпеки, зловмисник може вводити скрипти в додаток, може красти сесійні файли cookie, псувати веб-сайти та запускати шкідливе програмне забезпечення на машинах жертви.
Вразливі об'єкти
- Поля введення
- URL-адреси
Приклади
1. http://www.vulnerablesite.com/home?" < script > alert(" xss") script >
Наведений вище сценарій під час запуску у браузері відображатиметься вікно повідомлення, якщо сайт вразливий до XSS.
Більш серйозну атаку можна зробити, якщо зловмисник хоче відобразити або зберегти сеансовий файл cookie.
2. http://demo.testfire.net/search.aspx?txtSearch
Наведений вище сценарій під час запуску браузер завантажить невидимий кадр, що вказує на http://google.com .
Атаку можна зробити серйозною, запустивши шкідливий скрипт у браузері.
Рекомендації
- Білий список вводу
- Вхідне кодування вихідних даних
Порушена аутентифікація та управління сесіями
Опис
Зазвичай веб-сайти створюють файли cookie сеансу та ідентифікатор сеансу для кожного дійсного сеансу, і ці файли cookie містять конфіденційні дані, такі як ім’я користувача, пароль тощо. Коли сеанс завершується або виходом з системи, або різким закриттям браузера, ці файли cookie повинні бути визнані недійсними, тобто для кожного сеансу має бути нове печиво.
Якщо файли cookie не визнані недійсними, в системі існуватимуть конфіденційні дані. Наприклад, користувач, який використовує загальнодоступний комп’ютер (Cyber Cafe), файли cookie вразливого сайту сидить у системі та піддається зловмиснику. Зловмисник використовує той самий загальнодоступний комп'ютер через деякий час, конфіденційні дані скомпрометовані.
Таким же чином користувач, який використовує загальнодоступний комп'ютер, замість того, щоб вийти з системи, раптово закриває браузер. Зловмисник використовує ту саму систему, коли під час перегляду того самого вразливого сайту відкриється попередній сеанс жертви. Зловмисник може робити все, що хоче, з викрадення даних профілю, даних кредитної картки тощо.
Потрібно перевірити, щоб знайти міцність аутентифікації та управління сеансами. Ключі, маркери сеансів, файли cookie повинні бути впроваджені належним чином, не порушуючи паролі.
Вразливі об'єкти
- Ідентифікатори сеансів, виставлені на URL-адресу, можуть призвести до атаки фіксації сеансу.
- Ідентифікатори сеансу однакові до і після виходу та входу.
- Час очікування сеансу виконано неправильно.
- Програма призначає однаковий ідентифікатор сеансу для кожного нового сеансу.
- Автентифіковані частини програми захищені за допомогою SSL, а паролі зберігаються у хешованому або зашифрованому форматі.
- Мало привілейований користувач може повторно використовувати сеанс.
Наслідування
- Використовуючи цю вразливість, зловмисник може захопити сеанс, отримати несанкціонований доступ до системи, що дозволяє розкривати та модифікувати несанкціоновану інформацію.
- Сеанси можуть бути підняті з використанням вкрадених файлів cookie або сеанси за допомогою XSS.
Приклади
- Програма бронювання авіакомпаній підтримує переписування URL-адрес, введення ідентифікаторів сеансів в URL-адресу:
http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Продаж квитків на Мальдіви)
Аутентифікований користувач сайту хоче повідомити своїх друзів про продаж і надсилає електронне повідомлення. Друзі отримують ідентифікатор сеансу і можуть використовуватися для несанкціонованих модифікацій або неправильного використання збережених даних кредитної картки.
- Додаток вразливий до XSS, за допомогою якого зловмисник може отримати доступ до ідентифікатора сеансу і може бути використаний для викрадення сеансу.
- Час очікування програм встановлено неправильно. Користувач користується загальнодоступним комп’ютером і закриває браузер, а не виходить із системи і йде. Зловмисник використовує той самий браузер через деякий час, і сеанс аутентифікується.
Рекомендації
- Усі вимоги щодо автентифікації та управління сеансами повинні бути визначені відповідно до стандарту перевірки безпеки додатків OWASP.
- Ніколи не виставляйте будь-які дані в URL-адресах або журналах.
- Також слід докласти значних зусиль, щоб уникнути недоліків XSS, які можна використовувати для викрадення ідентифікаторів сеансу.
Небезпечні прямі посилання на об’єкти
Опис
Це відбувається, коли розробник виставляє посилання на внутрішній об'єкт реалізації, такий як файл, каталог або ключ бази даних, як у URL-адресі або як параметр FORM. Зловмисник може використовувати цю інформацію для доступу до інших об'єктів і може створити майбутню атаку для доступу до несанкціонованих даних.
Наслідування
- Використовуючи цю вразливість, зловмисник може отримати доступ до несанкціонованих внутрішніх об’єктів, може змінити дані або зламати програму.
Вразливі об'єкти
- В URL-адресі.
Приклади:
Зміна "ідентифікатора користувача" в наступній URL-адресі може змусити зловмисника переглядати інформацію інших користувачів.
http://www.vulnerablesite.com/userid=123 Змінено на http://www.vulnerablesite.com/userid=124
Зловмисник може переглядати іншу інформацію, змінюючи значення ідентифікатора користувача.
Рекомендації:
- Впровадити перевірки контролю доступу.
- Уникайте виставлення посилань на об’єкти в URL-адресах.
- Перевірте авторизацію для всіх довідкових об’єктів.
Підроблення запиту між сайтами
Опис
Підроблення запиту між сайтами - це підроблений запит, що надійшов із перехресного сайту.
CSRF-атака - це атака, яка відбувається, коли зловмисний веб-сайт, електронна пошта або програма змушує браузер користувача виконувати небажані дії на надійному веб-сайті, для якого користувач справді автентифікується.
Атака CSRF змушує зареєстрований браузер жертви надсилати підроблений HTTP-запит, включаючи файли cookie сеансу жертви та будь-яку іншу автоматично включену інформацію про автентифікацію, до вразливої веб-програми.
Зловмисник посилає посилання жертві, коли користувач натискає URL-адресу, коли входить на оригінальний веб-сайт, дані будуть викрадені з веб-сайту.
Наслідування
- Використання цієї вразливості як зловмисника може змінити інформацію профілю користувача, змінити статус, створити нового користувача від імені адміністратора тощо.
Вразливі об'єкти
- Сторінка профілю користувача
- Форми облікового запису користувача
- Сторінка ділових операцій
Приклади
Потерпілий входить на веб-сайт банку, використовуючи дійсні облікові дані. Він отримує пошту від зловмисника, в якій сказано: "Будь ласка, натисніть тут, щоб пожертвувати $ 1 на це".
Коли жертва натискає на нього, буде створено дійсний запит на пожертвування $ 1 на певний рахунок.
http://www.vulvablebank.com/transfer.do?account=cause&amount=1
Зловмисник захоплює цей запит, створює запит нижче і вбудовує в кнопку із написом "Я підтримую причину".
http://www.vulvablebank.com/transfer.do?account=Attacker&amount=1000
Оскільки сеанс аутентифікований, а запит надходить через веб-сайт банку, сервер перераховує зловмиснику 1000 доларів.
Рекомендація
- Доручення присутності користувача під час виконання делікатних дій.
- Впроваджуйте такі механізми, як CAPTCHA, повторна автентифікація та унікальні маркери запитів.
Неправильна конфігурація безпеки
Опис
Конфігурація безпеки повинна бути визначена та розгорнута для програми, фреймворків, сервера додатків, веб-сервера, сервера баз даних та платформи. Якщо вони правильно налаштовані, зловмисник може мати несанкціонований доступ до конфіденційних даних або функціональних можливостей.
Іноді такі вади призводять до повного компромісу в системі. Оновлення програмного забезпечення також є хорошою безпекою.
Наслідування
- Використовуючи цю вразливість, зловмисник може перерахувати базову інформацію про технологію та інформацію про версію сервера додатків, інформацію про базу даних та отримати інформацію про програму, щоб здійснити ще кілька атак.
Вразливі об'єкти
- URL
- Поля форми
- Поля введення
Приклади
- Консоль адміністратора сервера додатків автоматично встановлюється і не видаляється. Облікові записи за замовчуванням не змінюються. Зловмисник може ввійти з паролями за замовчуванням і отримати несанкціонований доступ.
- Список каталогів не вимкнено на вашому сервері. Зловмисник виявляє та може просто перерахувати каталоги, щоб знайти будь-який файл.
Рекомендації
- Потужна архітектура додатків, що забезпечує хороше розділення та захист між компонентами.
- Змініть імена користувачів та паролі за замовчуванням.
- Вимкніть списки каталогів та впровадьте перевірки контролю доступу.
Небезпечне криптографічне сховище
Опис
Небезпечне криптографічне зберігання - це загальна вразливість, яка існує, коли конфіденційні дані зберігаються не надійно.
Повноваження користувача, інформація про профіль, дані про стан здоров’я, інформація про кредитну картку тощо потрапляють під інформацію конфіденційних даних на веб-сайті.
Ці дані будуть зберігатися в базі даних програми. Якщо ці дані зберігаються неналежним чином, не використовуючи шифрування або хешування *, вони будуть вразливими для зловмисників.
(* Хешування - це перетворення символів рядка в коротші рядки фіксованої довжини або ключ. Для дешифрування рядка повинен бути доступний алгоритм, який використовується для формування ключа)
Наслідування
- Використовуючи цю вразливість, зловмисник може викрасти, змінити такі слабо захищені дані для крадіжки особистих даних, шахрайства з кредитною карткою або інших злочинів.
Вразливі об'єкти
- База даних додатків.
Приклади
В одному з банківських додатків база даних паролів використовує несолені хеші * для зберігання паролів усіх. Недолік ін’єкції SQL дозволяє зловмиснику отримати файл пароля. Всі несолені хеші можуть бути насильно вимушені в найкоротші терміни, тоді як для солених паролів знадобляться тисячі років.
(* Несолений хеш - сіль - це випадкові дані, що додаються до вихідних даних. Сіль додається до пароля перед хешуванням)
Рекомендації
- Забезпечте відповідні надійні стандартні алгоритми. Не створюйте власні криптографічні алгоритми. Використовуйте лише затверджені відкриті алгоритми, такі як AES, криптографія відкритого ключа RSA та SHA-256 тощо.
- Переконайтесь, що резервні копії за межами сайту зашифровані, але клавішами керуються та створюються резервні копії окремо.
Неможливість обмежити доступ до URL-адреси
Опис
Веб-програми перевіряють права доступу до URL-адрес перед тим, як відтворювати захищені посилання та кнопки. Програми повинні виконувати подібні перевірки контролю доступу кожного разу, коли здійснюється доступ до цих сторінок.
У більшості програм привілейовані сторінки, розташування та ресурси не надаються привілейованим користувачам.
За розумною здогадкою зловмисник може отримати доступ до сторінок привілеїв. Зловмисник може отримати доступ до конфіденційних сторінок, викликати функції та переглядати конфіденційну інформацію.
Наслідування
- Використовуючи цей зловмисник, ви можете отримати доступ до несанкціонованих URL-адрес, не входячи до програми та не використовуючи вразливість. Зловмисник може отримати доступ до конфіденційних сторінок, викликати функції та переглядати конфіденційну інформацію.
Вразливі об'єкти:
- URL-адреси
Приклади
- Зловмисник зауважує, що URL-адреса вказує роль як "/ user / getaccounts." Він змінюється як "/ admin / getaccounts".
- Зловмисник може додати роль до URL-адреси.
http://www.vulnerablsite.com можна змінити як http://www.vulnerablesite.com/admin
Рекомендації
- Впровадити надійні перевірки контролю доступу.
- Політика автентифікації та авторизації повинна базуватися на ролях.
- Обмежте доступ до небажаних URL-адрес.
Недостатній захист транспортного шару
Опис
Здійснює обмін інформацією між користувачем (клієнтом) та сервером (додатком). Програми часто передають через мережу конфіденційну інформацію, таку як дані автентифікації, інформацію про кредитну картку та маркери сеансів.
Використовуючи слабкі алгоритми, використовуючи прострочені або недійсні сертифікати, або не використовуючи SSL, можна дозволити комунікації потрапляти до ненадійних користувачів, що може скомпрометувати веб-програму та або викрасти конфіденційну інформацію.
Наслідування
- Використовуючи цю вразливість веб-безпеки, зловмисник може перенюхувати законні облікові дані користувача та отримати доступ до програми.
- Може вкрасти інформацію про кредитну картку.
Вразливі об'єкти
- Дані надсилаються по мережі.
Рекомендації
- Увімкніть захищений HTTP та примусово передайте облікові дані лише через HTTPS.
- Переконайтеся, що ваш сертифікат дійсний і не закінчився.
Приклади:
1. Додаток, який не використовує SSL, зловмисник буде просто відстежувати мережевий трафік і спостерігати за автентифікованим файлом cookie жертви. Зловмисник може викрасти це печиво та здійснити атаку "Людина посередині".
Неперевірені перенаправлення та переадресація
Опис
Веб-програма використовує декілька методів для переспрямування та перенаправлення користувачів на інші сторінки за призначенням.
Якщо під час перенаправлення на інші сторінки немає належної перевірки, зловмисники можуть скористатися цим і можуть перенаправити жертв на фішингові чи шкідливі сайти, або використовувати переадресацію для доступу до несанкціонованих сторінок.
Наслідування
- Зловмисник може надіслати користувачеві URL-адресу, яка містить справжню URL-адресу, додану із зашифрованою шкідливою URL-адресою. Користувач, побачивши справжню частину надісланої зловмисником URL-адреси, може переглядати її і може стати жертвою.
Приклади
1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com
Змінено на
http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com
Рекомендації
- Просто уникайте використання переадресацій та переадресацій у програмі. Якщо використовується, не використовуйте користувацькі параметри при обчисленні пункту призначення.
- Якщо параметрів призначення не вдається уникнути, переконайтеся, що вказане значення є дійсним та дозволеним для користувача.
Ця стаття представлена Прасанті Еаті