10 найпоширеніших вразливостей веб-безпеки

OWASP або Open Web Security Project – це некомерційна благодійна організація, яка займається підвищенням безпеки програмного забезпечення та веб-додатків.

Організація публікує список найпоширеніших вразливостей веб-безпеки на основі даних від різних організацій безпеки.

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

• Можливість експлуатації –Що потрібно для використання вразливості безпеки? Найвища експлуатаційна здатність, коли для атаки потрібен лише веб-браузер, а найнижча – розширене програмування та інструменти.
• Виявленість – Наскільки легко виявити загрозу? Найвищий – це інформація, яка відображається в URL-адресі, формі чи повідомленні про помилку, а найнижчий – вихідний код.
• Удар або пошкодження –Якої шкоди буде завдано, якщо вразливість системи безпеки буде виявлено або атакувано? Найвищий – повний збій системи, а найнижчий – взагалі нічого.

Головна мета OWASP Top 10 – ознайомити розробників, дизайнерів, менеджерів, архітекторів та організації з найважливішими вразливими місцями безпеки.

10 найпоширеніших вразливостей системи безпеки згідно з OWASP Top 10:

SQL-ін'єкція

Опис

Ін’єкція — це вразливість системи безпеки, яка дозволяє зловмиснику змінити серверну частину SQL оператори, маніпулюючи даними, наданими користувачем.

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

Команда SQL, яка під час виконання веб-додатком також може відкрити серверну базу даних.

Наслідки

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

Вразливі об'єкти

• Поля введення
• URL-адреси, що взаємодіють з базою даних.

Приклади:

• SQL injection на сторінці входу

Вхід у програму без дійсних облікових даних.

Дійсне ім'я користувача доступне, а пароль недоступний.

Тестовий URL: http://demo.testfire.net/default.aspx

Ім'я користувача: sjones

Пароль: 1=1′ або pass123

Запит SQL створено та надіслано до Інтерпретатора, як показано нижче

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1=1′ або pass123;

Рекомендації

1. Білий список полів введення
2. Уникайте відображення детальних повідомлень про помилки, корисних для зловмисника.

Перехресний сценарій

Опис

Міжсайтовий сценарій також коротко відомий як 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 <iframe> http://google.com ширина = 500 висота 500>

Під час виконання наведеного вище сценарію браузер завантажить невидимий кадр, що вказує на http://google.com.

Атаку можна зробити серйозною, запустивши шкідливий сценарій у браузері.

Рекомендації

1. Поля введення білого списку
2. Кодування вхідних даних

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

Опис

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

Якщо файли cookie не визнано недійсними, конфіденційні дані існуватимуть у системі. Наприклад, користувач, який користується загальнодоступним комп’ютером (Cyber ​​Cafe), файли cookie вразливого сайту зберігає в системі та піддається нападу. Через деякий час зловмисник використовує той самий публічний комп’ютер, конфіденційні дані скомпрометовані.

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

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

Вразливі об'єкти

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

Наслідки

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

прикладів

1. Програма бронювання авіакомпаній підтримує перезапис URL-адрес, додаючи ідентифікатори сеансу в URL-адресу:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Продаж квитків на Мальдіви) Автентифікований користувач сайту хоче повідомити своїх друзів про розпродаж і надсилає електронний лист. Друзі отримують ідентифікатор сеансу, і їх можна використовувати для неавторизованих змін або неправомірного використання збережених даних кредитної картки.
2. Програма вразлива до XSS, за допомогою якого зловмисник може отримати доступ до ідентифікатора сеансу та може бути використаний для викрадення сеансу.
3. Час очікування програм не встановлено належним чином. Користувач використовує загальнодоступний комп’ютер і закриває браузер замість того, щоб вийти з системи, і йде геть. Через деякий час зловмисник використовує той самий браузер, і сеанс аутентифікується.

Рекомендації

1. Усі вимоги до автентифікації та керування сеансами мають бути визначені відповідно до стандарту перевірки безпеки додатків OWASP.
2. Ніколи не розкривайте облікові дані в URL-адресах або журналах.
3. Слід також докласти значних зусиль, щоб уникнути недоліків XSS, які можуть бути використані для викрадення ідентифікаторів сеансу.

Незахищені прямі посилання на об’єкти

Опис

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

Наслідки

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

Вразливі об'єкти

• В URL.

Приклади:

Зміна «userid» у наведеній нижче URL-адресі може змусити зловмисника переглянути інформацію іншого користувача.

http://www.vulnerablesite.com/userid=123 Змінено на http://www.vulnerablesite.com/userid=124

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

Рекомендації:

1. Впровадити перевірки контролю доступу.
2. Уникайте показу посилань на об’єкти в URL-адресах.
3. Перевірте авторизацію для всіх еталонних об’єктів.

Підробка міжсайтового запиту

Опис

Cross Site Request Forgery – це підроблений запит, який надійшов із міжсайтового сайту.

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

Атака CSRF змушує браузер жертви, яка ввійшла в систему, надіслати підроблений HTTP-запит, включно з файлами cookie сеансу жертви та будь-якою іншою автоматично доданою інформацією автентифікації, до вразливої ​​веб-програми.

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

Наслідки

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

Вразливі об'єкти

• Сторінка профілю користувача
• Форми облікових записів користувачів
• Сторінка ділової операції

прикладів

Жертва входить на веб-сайт банку, використовуючи дійсні облікові дані. Він отримує лист від зловмисника з повідомленням: «Будь ласка, натисніть тут, щоб пожертвувати 1 долар на благо».

Коли жертва натисне на нього, буде створено дійсний запит на пожертвування 1 долара на певний рахунок.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

Зловмисник фіксує цей запит, створює запит і вставляє в нього кнопку з написом «Я підтримую справу».

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Оскільки сеанс автентифікований і запит надходить через веб-сайт банку, сервер переведе зловмиснику 1000 доларів США.

Рекомендація

1. Обов’язкова присутність користувача під час виконання конфіденційних дій.
2. Впровадити такі механізми, як CAPTCHA, повторна автентифікація та маркери унікальних запитів.

Неправильна конфігурація безпеки

Опис

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

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

Наслідки

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

Вразливі об'єкти

• URL
• Поля форми
• Поля введення

прикладів

1. Консоль адміністратора сервера додатків встановлюється автоматично, а не видаляється. Облікові записи за замовчуванням не змінюються. Зловмисник може увійти в систему за допомогою стандартних паролів і отримати несанкціонований доступ.
2. Список каталогів не вимкнено на вашому сервері. Зловмисник виявляє та може просто перерахувати каталоги, щоб знайти будь-який файл.

Рекомендації

1. Надійна архітектура додатків, яка забезпечує гарне розділення та безпеку між компонентами.
2. Змініть імена користувачів і паролі за замовчуванням.
3. Вимкніть списки каталогів і запровадьте перевірки контролю доступу.

Незахищене криптографічне сховище

Опис

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

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

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

(*Хешування — це перетворення символів рядка в коротші рядки фіксованої довжини або ключ. Щоб розшифрувати рядок, має бути доступним алгоритм, використаний для формування ключа)

Наслідки

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

Вразливі об'єкти

• База даних програми.

прикладів

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

(*Несолоні хеші – сіль – це випадкові дані, які додаються до вихідних даних. Сіль додається до пароля перед хешуванням)

Рекомендації

1. Забезпечте відповідні надійні стандартні алгоритми. Не створюйте власні криптографічні алгоритми. Використовуйте лише затверджені загальнодоступні алгоритми, такі як AES, криптографію з відкритим ключем RSA, SHA-256 тощо.
2. Переконайтеся, що зовнішні резервні копії зашифровані, але ключі керуються та резервуються окремо.

Не вдалося обмежити доступ до URL-адреси

Опис

Веб-додатки перевіряють права доступу до URL-адреси перед відтворенням захищених посилань і кнопок. Програми повинні виконувати подібні перевірки контролю доступу кожного разу, коли відкривається доступ до цих сторінок.

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

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

Наслідки

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

Вразливі об'єкти:

• URL-адреси

прикладів

1. Зловмисник помічає, що URL-адреса вказує роль як «/user/getaccounts». Він змінюється як «/admin/getaccounts».
2. Зловмисник може додати роль до URL-адреси.

http://www.vulnerablsite.com можна змінити як http://www.vulnerablesite.com/admin

Рекомендації

1. Впровадити жорсткі перевірки контролю доступу.
2. Політики автентифікації та авторизації мають базуватися на ролях.
3. Обмежте доступ до небажаних URL-адрес.

Недостатній захист транспортного рівня

Опис

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

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

Наслідки

• Використовуючи цю вразливість веб-безпеки, зловмисник може пронюхати облікові дані законного користувача та отримати доступ до програми.
• Може викрасти дані кредитної картки.

Вразливі об'єкти

• Дані, надіслані через мережу.

Рекомендації

1. Увімкніть безпечний HTTP та примусово передавайте облікові дані лише через HTTPS.
2. Переконайтеся, що ваш сертифікат дійсний і не прострочений.

Приклади:

1. У програмі, яка не використовує SSL, зловмисник просто відстежуватиме мережевий трафік і спостерігатиме за автентифікованим файлом cookie сеансу жертви. Зловмисник може викрасти цей файл cookie та здійснити атаку "Людина посередині".

Неперевірені переадресації та переадресації

Опис

Веб-додаток використовує кілька методів для перенаправлення користувачів на інші сторінки з цільовою метою.

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

Наслідки

• Зловмисник може надіслати користувачеві URL-адресу, яка містить справжню URL-адресу, до якої додається закодована шкідлива URL-адреса. Користувач, просто побачивши справжню частину надісланої зловмисником URL-адреси, може переглянути її та стати жертвою.

прикладів

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Змінено на

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Рекомендації

1. Просто уникайте використання переспрямувань і переадресацій у програмі. Якщо використовується, не використовуйте параметри користувача для розрахунку пункту призначення.
2. Якщо параметрів призначення неможливо уникнути, переконайтеся, що надане значення дійсне та авторизоване для користувача.