1.4 Testing for Bypassing Authentication Schema
Суть тестування:
Аутентифікація – це спроба перевірити цифрову особу. Типовим прикладом такого процесу є процес входу до системи. Тестування схеми аутентифікації означає розуміння того, як працює процес аутентифікації, щоб потім використовувати цю інформацію для обходу тієї ж автентифікації.
Хоча більшість додатків потрібна автентифікація для отримання доступу до приватної інформації або виконання завдань, але не всі автентифікації можуть забезпечити адекватну безпеку. Недбалість, незнання або просте зменшення загрози безпеці часто призводять до поганих схем аутентифікації, які можна обійти, просто пропустивши сторінку входу або зробити виклик сторінки безпосередньо через браузер, доступ до якої передбачається тільки після виконання аутентифікації.
Крім того, можна обійти заходи автентифікації через запити і обманюючи додаток, що користувач вже автентифікований. Цього можна досягти або шляхом зміни цього URL, маніпулюючи формою або підробляючи сеанси.
Проблеми, пов'язані зі схемою аутентифікації, можуть бути виявлені різних етапах життєвого циклу розробки програмного забезпечення. (SDLC):
- На етапі проектування, помилки можуть включати неправильне визначення розділів програми, що захищаються, вибір ненадійних протоколів шифрування для захисту передачі облікових даних і багато іншого.
- Помилки на етапі розробки можуть включати неправильну реалізацію функції перевірки введення або не дотримуючись рекомендацій з безпеки для конкретної мови програмування.
- На етапі розгортання програми можуть виникнути проблеми під час налаштування програми (установки та дії з налаштування) через відсутність необхідних технічних навичок або відсутність хорошої документації.
Як протестувати
Існує кілька методів обходу аутентифікації, що використовується веб-додатком:
- Direct page request (Прямий запит сторінки)
- Parameter modification (Модифікація параметра)
- Session ID prediction (Визначення ідентифікатора сеансу)
- SQL-ін'єкція
Direct page request
Якщо веб-програма реалізує контроль доступу лише на сторінці входу до системи, то можна автентифікацію обійти. Наприклад, якщо користувач безпосередньо запитує іншу сторінку, через примусовий перегляд у браузері, ця сторінка може перевіряти облікові дані користувача, перед тим, щоб надати доступ. Спробуйте отримати прямий доступ до захищеної сторінки через адресний рядок у браузері, щоб протестувати цю справу.
Parameter modification
Інша проблема, пов'язана з дизайном аутентифікації – це коли програма перевіряє успішний вхід до системи на основі параметра з фіксованим значенням. Користувач може змінити ці параметри, щоб отримати доступ до захищених функціоналів без надання дійсних облікових даних. У наведеному нижче прикладі параметр “authenticated” змінено на значення “yes”, що дозволяє користувачеві отримати доступ до всього. У цьому прикладі параметр знаходиться в URL-адресі, але проксі також можна використовувати для зміни параметра, особливо коли параметри відправляються як елементи форми в запиті POST або коли параметри зберігаються у файлі cookie.
http://www.site.com/page.asp?authenticated=no
raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0
HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1
«!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
«HTML»«HEAD»
«/HEAD»«BODY»
«H1»You Are Authenticated«/H1»
«/BODY»«/HTML»
Session ID Prediction
Багато веб-програм керують автентифікацією, використовуючи ідентифікатори сеансу. Отже, якщо ідентифікатор сеансу передбачуваний, зловмисник може знайти дійсний ідентифікатор сеансу та отримати неавторизований доступ до програми, видаючи себе автентифікованого користувача. На наступному малюнку значення всередині файлів cookie лінійно збільшуються, тому зловмисник може легко вгадати дійсний ідентифікатор сесії.
На наступному малюнку, наведеному нижче, значення знаходяться всередині файлів cookie і змінюються лише частково, тому тут можна застосувати атаку bruteforce на певні поля.
SQL Injection (HTML Form Authentication)
SQL-ін'єкція – широко відомий метод атаки. У цьому розділі я не докладно описуватиму цю техніку, тому що там кілька розділів цього посібника, але можете перейти на мою статтю з ін'єкцій.
На наступному малюнку показано, що за допомогою простої атаки SQL-ін'єкції можна обійти автентифікацію, якщо є така вразливість у програми.
Тестирование серого ящика
Если злоумышленник смог получить исходный код приложения, воспользовавшись ранее обнаруженной уязвимостью или вытянув из репозитория, то после изучения кода, он может выполнить точечные атаки на процессы аутентификации. В следующем примере (PHPBB 2.0.13 - уязвимость обхода аутентификации) в 5 строке есть функция unserialize (), она анализирует предоставленный пользователем файл cookie и устанавливает значения внутри массива $ row. В строке 10 хранится хэш пароля MD5. А внутри серверной базы данных сравнивается с поставляемой.
1. if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||2.
{
3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . '_data'] ) ?
4. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
5. $sessionmethod = SESSION_METHOD_COOKIE;
6. }
7. if( md5($password) == $row['user_password'] && $row['user_active'] )
8. {
9. $autologin = ( isset($HTTP_POST_VARS['autologin']) ) ? TRUE : 0;14.
10.}
У PHP відбувається порівняння строкового значення та логічного значення (1 - «yes») завжди має значення «yes», тому, задаючи наступне значення «b:1» у функцію unserialize(), ми обійдемо контроль аутентифікації:
a:2:{s:11: “ autologinid ” ;b:1;s:6: “ userid ” ;s:1: “ 2 ” ;}