Сова для IIS ідентифікує SQLs якраз перед тим, в даний час виконуються під час виконання. Тобто за рахунок впровадження модуля (RASP) час виконання додатка Self-Protection.
Ваш веб-додаток отримує введення за допомогою запитів і поштових параметрів. Вхід може призвести міжсайтовий скриптинг, SQL-ін'єкції і інші порушення правил безпеки. До теперішнього часу ми знаємо, WAF, має обмеження, оскільки він не працює в процесі, але в мережі: 1. Деякі з них можуть бути в залежності від ключів SSL, коли трафік в зашифрованому вигляді. Ті, хто не може обробити випадок DH 2. Воно не може бути впевнений, який користувач несе відповідальність за які оператори SQL, так як процес може використовувати іншого користувача для запуску SQLs 3. Складне URL підробці може обдурити WAF 4. Налаштування лазівку в додатку Developer (активується додатковий параметр запиту, щоб, нарешті, запустити спеціальний шкідливий код). Як WAF може зрозуміти це?
Розглянемо наступний приклад: користувач браузер відправляє цей запит HTTP, щоб отримати список користувачів у відділі HTTP :? //applicationHost/getData.aspx Код = derpatment. Але користувач може також змінити вручну в інше значення коду, як HTTP :? //applicationHost/getData.aspx Код = компанії. На додаток до цього дозволяє сказати, що SQLs в даний час виконуються за допомогою пулу потоків, що з перевіркою достовірності за допомогою деяких родове користувача. 1. Інструмент бази даних не може сказати, хто виник запит. 2. WAF повинні бути складними, щоб з'ясувати щось не так з URL.
Єдиний варіант, ви повинні співвіднести дані користувача (ім'я та IP) з точним твердженням SQL, що додаток виконує, будучи в точці, де додаток відправляє оператор SQL з процесу. Це і є справжній SQL після додатки завершення обробки введення. Ні евристика, ні помилкових спрацьовувань. Сова для IIS прагне розкрити всі SQL-оператори
Що нового в цьому випуску :.
Версія 1.3:
- файл аудиту тепер включають ім'я користувача
- Інтеграція з IBM Guardium передати ім'я користувача програми
Коментар не знайдено