gоrdey @ ptsеcurity com
Ліричний відступ
Перш за все, хотілося б зупинитися на основних помилках пов'язаних з CSRF:
1. Підробка HTTP-запитів - новий тип вразливостей.
2. CSRF - це варіант міжсайтовий виконання сценаріїв (XSS).
3. Уразливість CSRF мало поширена і досить складна у використанні.
Дані, отримані компанією Positive Technologies в ході робіт з тестування на проникнення і оцінки захищеності Web-додатків показують, що цю уразливість піддана більша частина Web-додатків. На відміну від інших вразливостей CSRF виникає не в результаті помилок програмування, а є нормальною поведінкою Web-сервера і браузера. Тобто більшість сайтів, які використовують стандартну архітектуру уразливі «за замовчуванням».
приклад використання
Мал. 1. Відправлення повідомлення
Мал. 2. Атака CSRF
Мал. 3. Логіка роботи CSRF
Для експлуатації CSRF зловмисникові зовсім не обов'язково мати свій Web-сервер. Сторінка, яка ініціює запит може бути передана по електронній пошті або іншим способом.
Сподіваюся, що зараз читачеві вже зрозуміло основна відмінність CSRF від XSS. У випадку з XSS зловмисник отримує можливість доступу до DOM (Document Object Model) вразливою сторінки, як на читання, так і на запис. При виконанні CSRF атакущій має можливість передати запит серверу за допомогою браузера користувача, але отримати і проаналізувати відповідь сервера, а тим більше його заголовок (наприклад, Cookie) вже не зможе. Відповідно, «Підробка HTTP-запитів» дозволяє працювати з додатком в режимі «тільки на запис», чого втім, цілком достатньо для виконання реальних атак.
Основними цілями CSRF-атак є різні інтерактивні Web-додатки, наприклад системи електронної пошти, форуми, CMS, інтерфейси віддаленого управління мережевим обладнанням. Наприклад, зловмисник може відправляти повідомлення від імені інших користувачів, додавати нові облікові записи, або змінювати налаштування маршрутизатора через Web-інтерфейс.
Мал. 4. Приклад експлуатації CSRF в форумі
пробиваємо периметр
- визначення типу Web-додатки (fingerprint);
- підбір пароля і аутентифікація за допомогою CSRF;
- зміна налаштувань вузла за допомогою атаки CSRF.
Після визначення типу пристрою зловмисник може спробувати змусити браузер користувача відразу послати запит на зміну налаштувань. Але такий запит буде успішним тільки в разі, якщо браузер користувача уже має активну аутентифицироваться сесію з пристрою. Мати під рукою відкриту сторінку управління маршрутизатором - погана звичка багатьох «просунутих» користувачів.
Але інші брузери, наприклад Firefox дають можливість вказати ім'я користувача і пароль в URL, і можуть бути використані для аутентифікації на будь-якому сервері, причому це можна зробити без генерації повідомлення про помилку в разі вибору неправильного пароля.
Приклад сценарію для «тихої» аутентифікації за методом Basic, з блогу Stefan Esser наведено нижче.
Firefox HTTP Auth BruteforcingМал. 5. Аутентификация Basic в Firefox
У корпоративному середовищі, де часто використовуються механізми SSO, наприклад, на базі домену Active Directory і протоколів Kerberos і NTLM експлуатація CSRF не вимагає додаткових зусиль. Браузер автоматично пройде аутентифікацію в контексті безпеки поточного користувача.
методи захисту
Однак цей механізм має ряд недоліків. По-перше - перед розробником постає питання про обробку запитів, що не мають заголовка Referer як такого. Багато з персональних міжмережевих екранів і анонімізуючих proxy-серверів вирізують Referer, як потенційно небезпечний заголовок. Відповідно, якщо сервер буде ігнорувати подібні запити, група найбільш «параноїдально» налаштованих громадян не зможуть з ним працювати.
Подальшим розвитком цього підходу є збереження ідентифікатора сесії не в Cookie, а в якості прихованого параметра форми (наприклад, VIEWSTATE).
В якості методу протидії CSRF можуть використовуватися різні варіанти тестів Тьюрінга, наприклад, добре відомі всім зображення - CAPTCHA. Іншим популярним варіантом є необхідність введення пароля користувача при зміні критичних налаштувань.
Мал. 7. Захист від CSRF в mail.ru
Таким чином, Cross-Site Request Forgery є атакою, спрямованої на клієнта Web-додатки і використовує недостатню перевірку джерела HTTP-запиту. Для захисту від подібних атак може використовуватися додатковий контроль джерела запиту на основі заголовка Referer або додаткового «випадкового» параметра.
