Testing for Privilege Escalation
Суть вразливості:
У цьому розділі описується проблема проекту привілеїв з одного етапу на інший. На цьому етапі тестувальник повинен переконатися, що користувач не може змінювати свої привілеї або ролі всередині програми, що може призвести до атак на підвищення привілеїв.
Підвищення привілеїв відбувається, коли користувач отримує доступ до більшої кількості ресурсів або функцій, ніж зазвичай дозволено, і таке підвищення чи зміни мало бути запобігання застосунку. Зазвичай це викликано дефектом у самому застосуванні. Зловмисник, який отримав привілей суперкористувача без будь-якої аутентифікації, представляє велику проблему для вашої програми. Існує вертикальна ескалація, коли можна отримати доступ до ресурсів, наданих більш привілейованим обліковим записам. Наприклад, отримання адміністративних привілеїв для застосування. І є горизонтальна ескалація, коли є можливість доступу до ресурсів облікового запису з аналогічною конфігурацією прав. Наприклад, у додатку онлайн-банкінгу доступ до інформації одного користувача доступний іншому користувачеві.
Як протестувати
Тестування на маніпулювання ролями/привілеями
У кожній частині програми, де користувач може створювати інформацію в базі даних (наприклад, здійснювати платіж, додавати контакт або надіславши повідомлення), може отримувати інформацію (витяг з рахунку, деталі замовлення тощо) або видаляти інформацію (перетягування користувачів, повідомлення і т.д.). Тестувальник повинен спробувати отримати доступ до таких функцій іншого користувача, щоб перевірити, чи можна отримати доступ до функції, яка не повинна бути дозволена користувачеві з цією роллю/привілеєм.
Маніпулювання групою користувачів Наприклад: наступний HTTP POST дозволяє користувачеві, що належить до групи grp001, отримати доступ до замовлення № 0001: POST /user/viewOrder.jsp HTTP/1.1 Host: www.example.com ... groupID=grp001&orderID=0001 Переконайтеся, що користувач, що не належить до групи grp001, не може змінити значення параметрів groupID та orderID, щоб отримати доступ до цих привілейованих даних.
Маніпулювання профілем користувача
Наприклад: у наступній відповіді сервера показано приховане поле в HTML-коді, що повертається користувачеві після успішної автентифікації. HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close
<form name="autoriz" method="POST" action = "visual.jsp"»
«input type="hidden" name="profile" value="SysAdmin"»
«body onload="document.forms.autoriz.submit()"»
«/td»
«/tr»
Що, якщо тестувальник змінить значення змінної profile на SysAdmin? Чи можна стати адміністратором у цьому випадку?
Маніпулювання значенням умови
Наприклад: у середовищі, де сервер надсилає повідомлення про помилку, міститься параметр:
@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command
Manager`0`0`0` StateToolsBar`0`0`0`
StateExecToolBar`0`0`0`FlagsToolBar`0
Сервер дає користувачеві явну довіру. Він вважає, що користувач просто закриє сеанс і піде гуляти надвір. У цьому випадку варто переконатись, що неможливо підвищити привілеї шляхом зміни значень параметрів. Наприклад, змінивши значення PVValid з "-1" на "0" (без помилок, звичайно ж змінити), і подивитися можна пройти автентифікацію як адміністратор до сервера.
Маніпулювання IP-адресою
Деякі веб-сайти обмежують доступ або підраховують кількість невдалих спроб входу до системи на основі IP-адреси. Наприклад:
X-Forwarded-For: 8.1.1.1
У цьому випадку, якщо веб-сайт використовує значення X-forwarded-For як IP-адресу клієнта, то тестер може змінити значення IP-адреси в заголовку HTTP X-forwarded-For для обходу ідентифікації IP-джерела.
Обхід URL
пробуйте пройтись по сайту і перевірити, чи деякі сторінки не пройшли перевірку авторизації. Наприклад:
/../.././userInfo.html