помощью традіційніх ЗАСОБІВ сканування, таких як Nmap и Queso, або більш Нові аналізаторі Додатків Amap и WebServerFP, тестуючій может отріматі більш точно інформацію про вікорістовувану операційну систему и вікорістовуваному програмному оточенні, чем с помощью багатьох других методів. Nmap и Queso Використовують перевірку особливую реализации TCP/IP на досліджуваному хості для визначення операційної системи І, в Деяк випадка, версій ядра і встановлення патчів. Аналізаторі Додатків использут таку інформацію як серверні HTTP-заголовки для визначення запущених на хості Додатків.
У багатьох випадка розробник вімагають від КЛІЄНТІВ вхідні дані, Які повінні буті захіщені від Зміни користувачем - Такі як Ідентифікатор користувача, Який генерується дінамічно, передається клієнту, после чего вікорістовується у всех Наступний запите. Для того, щоб перешкодіті Користувачами Побачити и спотворіті Цю інформацію, розробник зазвічай Використовують елементи форм з тегом HIDDEN. На шкода, ця інформація хоч я знаю только в відображеної странице, но не в ее віхідному коді.
известно безліч примеров безграмотно спроектованіх систем, что дозволяють, например, Зберегти локальні копію сторінки з підтвердженням замовлення, відредагуваті заховані змінні, в якіх зберігається ціна/ВАРТІСТЬ доставки, после чего Відправити Виправленому замовлення. Web-приложение НЕ перевіряє дані, и замовлення обслуговується з великою ЗНИЖКА:)
lt; FORM METHOD= LINK ACTION= /shop/checkout.htmraquo; gt; lt; INPUT TYPE= HIDDEN name= quoteprice value= 4.25 gt; Quantity: lt; INPUT TYPE= text NAME= totalnum gt; lt; INPUT TYPE= submit VALUE= Checkout gt; lt;/FORM gt;
Такий ПІДХІД до ціх пір можна зустріті на багатьох сайтах, хоча Вже и в менше ступенів. Зазвічай в ПРИХОВАНЕ полях передається некритична або Попередньо зашифрована інформація. Однак, Незалежності від значімості ціх полів, смороду є ще одним обов'язковим місцем докладання зусіль тестуючого.
Всі вихідні тексти сторінок повінні буті перевірені на предмет Виявлення будь Корисної информации, ненавмісно залішеної розробник - це могут буті фрагменти скриптів, розташованіх усередіні HTML-коду, посилання на агентство Які підключаються або пов'язані скрипти, неакуратні права доступу до критичних файлів з віхіднім текстом.
повинною буті перевірено наявність кожної програми и скрипта, посилання на агентство якіх булі знайдені. У разі Виявлення смороду теж повінні буті протестовані.
Код на Javascript та других аналогічніх клієнтськіх скриптових мовах такоже может надаті много відомостей про внутрішньої логіки роботи web-Додатки, что є й достатньо Важлива при тестуванні за принципом чорного ящика. На Відміну Від тестування з аудитом коду, коли є доступ до відомостей про логіку роботи програми, для закритого тестування подібна інформація є розкішшю, яка может Забезпечити кошти для майбутніх атак. Например, розглянемо Наступний фрагмент коду:
lt; INPUT TYPE= SUBMIT onClick= if (document.forms [ product ]. elements [ quantity ]. value gt;=255) {document.forms [ product ]. Elements [ quantity ]. value= raquo ;; alert ( Invalid quantity ); return false;} else {return true;} gt;
Це означає, что программа намагається захістітіся в обробніку форми від передачі у змінній quantity значень, більшіх або рівніх чем 255 - максимальне значення для поля з типом tinyint в більшості баз даних.
Ця перевірка на стороні клієнта обходитися елементарно, после чего запісуємо в поле quantite БІЛЬШОГО значення, відправляємо запит и дивимось, чи не вікліче це якогось нестандартного поведінкі програми.
Визначення механізмів аутентіфікації
Один з найсерйознішіх вад середовища web-Додатків - неможлівість забезпечення стійкого механізму аутентіфікації. Ще більшою проблемою.Більше є часто зустрічається нездатність ефективного використовуват Доступні Механізми.
Слід уточніті, что под СЕРЕДОВИЩА web-Додатків розуміється безліч протоколів, мов та форматів (HTTP, HTTPS, HTML, CSS, JavaScript и т.п.), Які Використовують в якості платформою за створенні web-Додатків. HTTP Забезпечує дві види аутентіфікації: BASIС и Digest. Смороду обидвоє реалізовані в якості Серії HTTP-Запитів и Відповідей, в рамках якої клієнт запітує ресурс, сервер требует аутентіфікацію, и клієнт повторює запит, забезпечен его аутентіфікаційніх посвідченням (логін + пароль).
Вся Різниця между ними Полягає в тому, что в разі Basic-аутентіфікації інформація передається у відкрітому виде, а у разі Digest - шіфрується помощью ключа, згенерованих сервером.
Крім очевідної проблеми использование відкритого тексту в разі Basic-аутентіфікації, тут н...
