Перевірка надійності Web додатків

Ця стаття одна з трьох публікацій, присвячених перевірці надійності Web додатків. У першій частині описується перевірка надійності і аналіз Web додатків, способи організації їх роботи, взаємодії з користувачами, а також стандартні помилки розробників, здатні дати доступ до даних і системі. TECKLORD

, За матеріалами SecurityFocus.

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

Прімічаніе: передбачається, що читач знайомий з архітектурою HTTP протоколу, HTTP Get і Post запитами, і значеннями полів заголовків. Цю інформацію можна отримати з RFC2616 .

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

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

Майже всі середовища розробки Web додатків (включаючи ASP і PHP, які будуть використовуватися для прикладів) надають використання даних розробнику таким чином, що неможливо визначити спосіб їх перехоплення, і внаслідок, який вид підтвердження і перевірки повинен бути використаний. Оскільки середовища розробок різні, і складаються з багатьох видів програмованого змісту, підтвердження введення і логічний контроль є ключем до вирішення проблем з безпекою Web додатків. Це стосується і ідентифікації, і забезпечення вірного домену для кожного певного користувачем елемента даних, так само, як і повне розуміння джерела всіх елементів даних для позначення потенційних даних, визначених користувачем.

Головне завдання: підтвердити введення

Завдання підтвердження введення можуть викликати складності при розташуванні їх в об'ємній базі з великою кількістю взаємодій користувачів між собою, що, власне, і є головною причиною, що примушує розробників використовувати методологію перевірки безпеки для вирішення цих проблем. Web додатки все ж не мають імунітету до звичайних форм атак. Непрофесійні методи аутентифікації, логічні прорахунки, не передбачене виявлення прихованої інформації, звичайні бінарні помилки додатків (переповнення буфера) зустрічаються дуже часто. Аналізуючи Web додатки на предмет наявності вразливостей, все вищесказане має враховуватися; повинні також застосовуватися методичний процес перевірки введення / виведення (метод «чорного ящика»), по можливості, разом з аудитом коду (методом «білого ящика»).

Що ж насправді являє собою Web додаток?

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

Як це виглядає для користувача?

Web додатки часто взаємодіють з користувачами використовуючи елементи ФОРМИ і змінні GET або POST (навіть кнопка «Натисни тут» зазвичай є підтвердженням форми). При використанні змінних GET дані з форми можуть бути видні в самому URL запиті, в той час, як POST запити вимагають вивчення коду сторінки форми або перехоплення і розшифровки запиту для отримання даних, введених користувачем.

Приклад HTTP запиту для звичайного Web додатки

GET /sample.php?var=value&var2=value2 HTTP / 1.1

| HTTP-METHOD REQUEST-URI PROTOCOL / VERSION

Session-ID: 361873127da673c

| Session-ID Header

Host: www.webserver.com

| Host Header

| Two carriage return line feeds

Кожен елемент даного запиту може бути використаний Web додатком, що обробляє цей запит. REQUEST-URI вказує одиницю коду, яка буде приведена в дію рядком запиту: перелік розділених пар & variable = value позначають параметри введення. Це основна форма введення даних для Web додатків. Тема Session-ID є позначенням установки сесії з клієнтом як первинна форма аутентифікації. Host Header зазвичай використовується для розрізнення віртуальних хостів, що належать одному IP адресою і зазвичай фільтрується Web сервером, але знаходиться, відповідно до теорії, всередині домену Web додатки.

Для перевірки надійності потрібно використовувати всі можливі методи введення, щоб викликати критичні умови для додатка. Не слід покладатися на обмежені можливості, які дають броузер або різні інструменти. Дуже просто створювати HTTP запити використовуючи такі утиліти, як curl , Або консольні скрипти користуючись netcat . Процес тестування Web додатки, використовуючи метод чорного ящика, дає можливість виявити кожен елемент даних, визначаючи очікується введення, взаємодіючи з ним і пошкоджуючи його, а також аналізуючи висновок додатки на предмет наявності нестандартної поведінки.

Фаза збору інформації

відбитки

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

1. Дослідження відповіді на HTTP запити - HEAD і OPTIONS

Тема і будь-яка сторінка отримана в результаті запиту HEAD або OPTIONS містить зазвичай рядок SERVER: або детальний опис версії програмного забезпечення Web сервера, і, можливо, опис скриптів або операційної системи.

OPTIONS / HTTP / 1.0
HTTP / 1.1 200 OK
Server: Microsoft-IIS / 5.0
Date: Wed, 04 Jun 2003 11:02:45 GMT
MS-Author-Via: DAV
Content-Length: 0
Accept-Ranges: none
DASL:
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, COPY, PROPFIND, SEARCH, LOCK, UNLOCK
Cache-Control: private

2. Дослідження формату і написів на сторінках, які повідомляють про помилки (404 / та інші)

Деякі додатки (такі як ColdFusion) мають стандартні, а значить, легко впізнавані сторінки повідомляють про помилки і видають версію програмного забезпечення та мова скриптів. Дослідник повинен уважно вивчити одержувані сторінки і використовувати отриману інформацію від різних запитів (POST / PUT / і т.д.) для збору інформації про сервер.

Нижче наведено приклад сторінки, що повідомляє про 404 помилку додатки ColdFusion:

3. Тест на розпізнавання типів фалів / розширень / директорій

Багато Web сервіси (наприклад Microsoft IIS) будуть вести себе по різному на запит до відомого і підтримуваного файловому вирішенню і до невідомого. Перевіряючий повинен спробувати запросити файли зі звичайними дозволами (ASP, .HTM, .PHP, .EXE) і простежити за незвичайними відповідями або кодами помилок.

GET /blah.idq HTTP / 1.0 HTTP / 1.1 200 OK Server: Microsoft-IIS / 5.0 Date: Wed, 04 Jun 2003 11:12:24 GMT Content-Type: text / html <HTML> The IDQ file blah.idq could not be found.

4. Дослідження вихідних кодів доступних сторінок.

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

<Title> Home Page </ title> <meta content = "Microsoft Visual Studio 7.0" name = "GENERATOR"> <meta content = "C #" name = "CODE_LANGUAGE"> <meta content = "JavaScript" name = "vs_defaultClientScript" >

У даній ситуації розробник, схоже, використовує MS Visual Studio 7. Середовищем може бути, в даному випадку, Microsoft IIS 5.0 з .NET framework.

5. Управління введенням для пошуку помилок в скриптах.

В даному прикладі очевидна змінна (ItemID) була змінена для спостереження за Web додатком:

1. Відбитки сервісу і TCP / ICMP

Використовуючи звичайні засоби для зняття відбитків - Nmap і Queso - або більш популярні Amap і WebServerFP , Перевіряючий може отримати більш точні дані про операційну систему і Web додатку по відношенню до інших методів. NMAP і Queso досліджують спосіб реалізації TCP / IP даного хоста для визначення відомостей про операційну систему, в деяких випадках, про версії ядра і патчах. Такі додатки покладаються на дані, отримані від HTTP заголовків сервера для визначення ПО.

Приховані елементи форми і аналіз коду

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

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

<FORM METHOD = "LINK" ACTION = "/ shop / checkout.htm"> <INPUT TYPE = "HIDDEN" name = "quoteprice" value = "4.25"> Quantity: <INPUT TYPE = "text" NAME = "totalnum" > <INPUT TYPE = "submit" VALUE = "Checkout"> </ FORM>

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

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

Javascript і інші клієнтські програми можуть також дати багато інформації про внутрішній устрій Web додатки. Таку інформацію можна отримати користуючись методом чорного ящика. Також за допомогою методу білого ящика (або аудиту коду) можна отримати доступ до логічної побудови програми. Для методу чорного ящика ця інформація є розкішшю, якої слід скористатися для атак:

<INPUT TYPE = "SUBMIT" onClick = "if (document.forms [ 'product']. Elements [ 'quantity']. Value> = 255) {document.forms [ 'product']. Elements [ 'quantity']. value = ''; alert ( 'Invalid quantity'); return false;} else {return true;} ">

Передбачається, що додаток намагається обмежити значення кількості до 255 - максимального значення поля tinyint в більшості СУБД. Було б логічно обійти клієнтську сторону перевірки і вставити довге числове значення в змінну quantity запиту GET / POST, а потім простежити за дією програми.

Визначення механізму аутентифікації

Один з великих недоліків Web додатків - відсутність стійкого механізму аутентифікації. Найчастішою помилкою розробників є визначення ефективності механізму аутентифікації. Слід зауважити, що умови проведення аутентифікації залежать від протоколів, мов та форматів - HTTP, HTTPS, HTML, CSS, JavaScript, і т.д - використовуваних додатками і залежних від платформи, на якій працює додаток і від його архітектури. НТТР забезпечує два методи аутентифікації Basic і Digest. Обидва є серією НТТР запитів і відповідей, в якій клієнт запитує ресурс, сервер вимагає аутентифікацію, і клієнт повторює запит згідно з вимогами аутентифікації. Різниця між двома методами аутентифікації складається в ном, що при методі Basic посилається сервера простий текст, а при Digest, хешировать, який використовується сервером як криптографічний ключ.

У природі проблеми передачі даних відкритим текстом при використання методу Basic при НТТР аутентифікації немає нічого неправильного, і ця проблема може бути вирішена використанням HTTPS. Проблема насправді полягає в двох речах.

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

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

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

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

http://www.server.com/showdoc.asp?docid=10

Також, для доступу до меню потрібно аутентифікація, скрипт showdoc.asp сам по собі не вимагає аутентифікації і надає будь-якій потрібний документ. Це може дозволити атакуючому просто вказати id документа і в GET запиті і отримати бажану сторінку. Як елементарно це не звучить, але ця помилка найчастіша.

висновок

У цій статті ми описали методи перевірки надійності і в цілому розглянули структуру Web додатків, а також методи контролю введення даних з боку користувачів. Ми також показали важливість використання відбитків для цільової середовища і розуміння прихованої частини Web додатків. Озброївшись цією інформацією, перевіряючий зможе провести ряд тесів для пошуку і використання вразливостей. Наступні статті цього циклу опишуть способи атак за допомогою зміни коду і змісту, таких, як PHP / ASP code injection, SQL injection, Server-Side Includes і міжсайтовий скриптинг ..