2.2 Testing for Bypassing Authorization Schema
Суть вразливості:
Цей вид тесту спрямований на перевірку того, як схема авторизації була реалізована для кожної ролі або привілеї, щоб надалі давати доступ до функцій та сторінок сайту. Для кожної конкретної ролі, яку перевіряє тестувальник, і для кожної функції та запиту, які виконуються додатком на етапі постаутентифікації, необхідно перевірити: - Чи можна отримати доступ до цього ресурсу, навіть якщо користувач не автентифікований? - Чи можна отримати доступ до цього ресурсу після виходу із системи? - Чи можливо отримати доступ до функцій та ресурсів, які мають бути доступні користувачеві з іншою роллю чи привілеями?
Спробуйте увійти в програму як користувач з правами адміністратора та відстежте всі адміністративні функції. А потім перевірте такі кейси: - Чи можливий доступ до адміністративних функцій звичайного користувача зі стандартними привілеями? - Чи можна використовувати ці адміністративні функції в інших користувачів з іншою роллю?
Як протестувати
Тестування доступу до адміністративних функцій
Наприклад, припустимо, що функція AddUser.jsp є частиною адміністративного меню програми, і до неї можна отримати доступ, запитавши наступний
URL: https://www.example.com/admin/addUser.jsp
Потім під час виклику функції AddUser створюється наступний HTTP-запит:
POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
[other HTTP headers]
userID=fakeuser&role=3&group=grp001
Що станеться, якщо користувач без прав адміністратора спробує виконати цей запит? Чи буде створено користувач? Якщо так, то у вас дірка у безпеці)))) Ну хоч щось у безпеці)))
Тестування доступу до ресурсів, двох різних ролей
Наприклад, проаналізуйте програму, яка використовує спільний каталог для зберігання тимчасових PDF-файлів для різних користувачів. Припустимо, що documentABC.pdf має бути доступним лише користувачеві test1 з роллю A. Переконайтеся, що користувач test2 з роллю B не може отримати доступ до цього ресурсу.
Тестування обробки заголовка спеціального запиту
Деякі програми підтримують нестандартні заголовки, такі як X-Original-URL або X-Rewrite-URL, щоб дозволити перевизначення цільової URL-адреси. Таку поведінку можна спостерігати в ситуації, коли програма знаходиться за компонентом, який визначає чи є доступ для роботи з цим запитом у користувача чи ні.
Таким обмеженням керування доступу може бути, наприклад, блокування доступу з Інтернету до консолі адміністрування сайту, доступне за лінкою /admin. Щоб визначити підтримку заголовка X-Original-URL або X-Rewrite-URL, можна виконати такі дії.
1. Надсилання запиту без назви Any X-Original-Url або X-Rewrite-Url
GET/HTTP/1.1
Host: www.example.com
[other standard HTTP headers]
2. Надсилання запиту з назвою X-Original-Url та вказівкою на неіснуючий урл
GET/HTTP/1.1
Host: www.example.com
X-Original-URL: /donotexist1
[other standard HTTP headers]
3. Надсилання запиту із назвою X-Rewrite-Url та вказівкою на неіснуючий урл
GET/HTTP/1.1
Host: www.example.com
X-Rewrite-URL: /donotexist2
[other standard HTTP headers]
Якщо відповідь на будь-який запит містить позначки про те, що ресурс не знайдено, це означає, що програма підтримує спеціальні заголовки у запитах. Ці маркери можуть включати код стану відповіді HTTP 404 або «ресурс не знайдений» у тілі відповіді.
Як тільки підтримка заголовка X-Original-URL або X-Rewrite-URL була підтверджена, тоді попередній обхід проти обмеження контролю доступу можна використовувати, відправивши очікуваний запит до програми, але вказавши URL-адресу, «дозволену» інтерфейсним компонентам, вказавши реальну цільову URL -адреса в назві X-Original-URL або X-Rewrite-URL в залежності від підтримуваного. Якщо обидва підтримуються, спробуйте один за одним, щоб перевірити, для якого заголовка діє обхід.