Дослідження вразливостей web-ресурсів

Головною особливістю виробничих вразливостей є їх прихильність до певних версій програмного забезпечення. Справа в тому, що «дірки» часто зустрічаються не у всій лінійці веб-серверів, а тільки в деяких їх релізах. А ще варто відзначити, що чим популярніше те чи інше програмне забезпечення, тим частіше для нього знаходять нові уразливості. І це залежить не від якості написання софта. Просто його вивчають більше фахівців, так що і вірогідність виявлення «дір» відносно велика. Захиститися від оглянутого типу вразливостей ПЗ можна тільки одним способом - своєчасною установкою всіх розроблених виробниками патчів. Справа в тому, що розробники софта регулярно викладають на офіційних сайтах оновлення для своїх продуктів. При виявленні критичною для безпеки «дірки» патч випускається швидко (якщо, звичайно, компанія дійсно піклується про своїх клієнтів). Якщо ж знову знайдені вразливості несуть швидше теоретичну, ніж реальну загрозу, то в міру їх накопичення випускаються кумулятивні патчі.

 

2. Вразливості конфігурації

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

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

Від некоректного налаштування не може допомогти установка патчів. І дійсно, при оновленні програмного забезпечення його конфігурація не змінюється. А це означає, що уразливість в системі захисту після інсталяції патча швидше за все залишиться. Таким чином, головною небезпекою розглянутого типу «дірок» є складність їх виявлення [5].

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

3.   Вразливості програмного забезпечення користувачів

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

 Виявити «дірки» в  скриптах можна за допомогою  сканерів безпеки. Так що кожен  власник веб-сервера, дійсно піклується  про безпеку свого сайту, повинен  періодично перевіряти його. Причому  слово «періодично» в попередньому  реченні з'явилося зовсім не  випадково. Справа в тому, що хакери  постійно вигадують нові способи  віддалених атак. Крім того, постійно  виявляються нові «дірки» в  оригінальному ПЗ, які можуть  у поєднанні зі скриптами, які  раніше вважалися безпечними, являти  собою реальну загрозу.

Таким чином, класифікацію вразливостей web-серверів можна представити у вигляді, наведеному на рисунку 1.1

Рисунок 1.1 - Класифікація вразливостей web-серверів

 

Оскільки є вразливості, то зловмисники можуть їх використовувати. Тому слід розглянути класифікацію можливих атак на web-сервери. 
 2 КЛАСИФІКАЦІЯ АТАК НА WEB-САЙТИ

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

За останні кілька років індустрія безпеки web-додатків адаптувала кілька десятків плутаних і езотеричних термінів, що описують уразливості. Такі назви вразливостей, як «міжсайтового виконання сценаріїв» (Cross-site Scripting), «підробка параметрів» (Parameter Tampering), і «отруєння печива» (Cookie Poisoning) не точно визначають суть проблеми і можливі наслідки атак [6].

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

Розглянемо детальніше різні класи атак на елементи захисту Web-серверів (рис. 2).

  2.1 Атаки на автентифікацію (Authentication)

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

Автентифікація використовує як мінімум один з трьох механізмів (факторів): "щось, що ми маємо", "щось, що ми знаємо" або "щось, що ми є". У цьому розділі описуються атаки, спрямовані на обхід або експлуатацію вразливостей в механізмах реалізації автентифікації Web-серверів.

 

 

 

Рисунок 2.1 – Класифікація атак web-сайти

 

2.1.1 Підбір (Brute Force)

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

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

2.1.2 Недостатня автентифікація (Insufficient Authentication)

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

2.1.3  Небезпечне відновлення паролів (Weak Password Recovery Validation)

Ця уразливість виникає, коли Web-сервер дозволяє атакуючому несанкціоновано отримувати, модифіковані або відновлювати паролі інших користувачів. Часто автентифікація на Web-сервер вимагає від користувача запам'ятовування пароля або парольної фрази. З часом пароль забувається. Таким чином, функція відновлення пароля є важливою складовою що надається Web-серверами сервісу. Прикладом реалізації подібної функції є використання "секретного питання", відповідь на яке вказується в процесі реєстрації. Питання або вибирається зі списку або вводиться самим користувачем. Ще один механізм дозволяє користувачу вказати "підказку", яка допоможе йому згадати пароль.

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

2.2 Атаки на авторизацію (Authorization)

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

2.2.1  Передбачуване значення ідентифікатора сесії

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

Дизайн багатьох серверів припускає автентифікацію користувача при першому зверненні та подальше відстеження його сесій. Для цього користувач вказує комбінацію імені та пароля. Замість повторної передачі ім'я користувача та пароль при кожній транзакції, Web-сервер генерує унікальний ідентифікатор, який присвоюється сесії користувача [6]. Наступні запити користувача до сервера містять ідентифікатор сесії як доказ того, що автентифікація успішно пройдено. Якщо атакуючий може передбачити або вгадати значення ідентифікатора іншого користувача, це може бути використано для проведення атаки.

2.2.2 Недостатня авторизація (Insufficient Authorization)

Недостатня авторизація виникає, коли Web-сервер дозволяє атакуючому

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

2.2.3 Відсутність таймауту сесії (Insufficient Session Expiration)

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

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

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

2.2.4 Фіксація сесії (Session Fixation)

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

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

2.3 Атаки на  клієнтів (Client-side Attacks)

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

2.3.1 Підміна вмісту (Content Spoofing)

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

<frame src=" http://foo.example/file.html">

може передаватися у параметрі URL:

http://foo.example/page?frame_src=http://foo.example/file.html

Атакуючий може замінити значення параметра "frame_src" на

"frame_src = http://attacker.example/spoof.html".

Коли буде відображатися результуюча сторінка, у рядку адреси браузера користувача відображатиметься адреса сервера (foo.example), але так само на сторінці буде присутній вміст із зовнішнього джерела, завантажене з сервера атакуючого (attacker.example), замасковане під легальний контент.

2.3.2 Міжсайтове виконання сценаріїв (Cross-site Scripting, XSS)

Наявність уразливості Cross-site Scripting дозволяє атакуючому передати серверу код, який буде виконуватися перенаправлено браузеру користувача. Цей код зазвичай створюється на мовах HTML/JavaScript, але можуть бути використані інші мови, які підтримує браузер.

У результаті ретельно спланованої атаки зловмисник може використовувати браузер жертви для перегляду сторінок сайту від імені атакованого користувача. Код може передаватися зловмисником в URL, в заголовках HTTP запиту (cookie, user-agent, refferer), значеннях полів форм і т.д.

Існує два типи атак, що приводять до міжсайтового виконання сценаріїв: постійні (збережені) і непостійні (відображені). Основною відмінністю між ними є те, що у другому варіанті передача коду сервером та повернення його клієнту здійснюється в рамках одного HTTP-запиту, а в першому - в різних. Здійснення непостійної атаки вимагає, щоб користувач перейшов за посиланням, згенерованому зловмисником (посилання може бути передана за email, ICQ тощо). У процесі завантаження сайту код, впроваджений в URL або заголовки запиту буде переданий клієнту і виконаний у його браузері.