Вплив
Підробка міжсайтового запиту (CSRF) дозволяє зловмиснику змусити браузер жертви виконати небажані дії на іншому веб-сайті, де жертва наразі автентифікована. Оскільки браузери автоматично включають зовнішні облікові дані, такі як файли cookie, у запити, зловмисник може підробити операції зміни стану, такі як зміна паролів, видалення даних або ініціювання транзакцій, без відома користувача.
Основна причина
Основною причиною CSRF є поведінка веб-переглядача за замовчуванням щодо надсилання файлів cookie, пов’язаних із доменом, щоразу, коли до цього домену надсилається запит, незалежно від джерела запиту [S1]. Без спеціальної перевірки того, що запит було навмисно ініційовано з власного інтерфейсу користувача програми, сервер не зможе відрізнити законну дію користувача від підробленої.
Механізми захисту Django CSRF
Django надає вбудовану систему захисту для пом’якшення цих ризиків за допомогою проміжного програмного забезпечення та інтеграції шаблонів [S2].
Активація проміжного ПЗ
django.middleware.csrf.CsrfViewMiddleware відповідає за захист CSRF і зазвичай увімкнено за замовчуванням [S2]. Його потрібно розташувати перед будь-яким проміжним програмним забезпеченням перегляду, яке передбачає, що атаки CSRF уже оброблено [S2].
Реалізація шаблону
Для будь-яких внутрішніх форм POST розробники повинні включити тег {% csrf_token %} в елемент <form> [S2]. Це гарантує, що унікальний секретний маркер буде включено в запит, який потім сервер перевіряє на сеанс користувача.
Ризики витоку токенів
Важливою деталлю впровадження є те, що {% csrf_token %} ніколи не слід включати у форми, націлені на зовнішні URL-адреси [S2]. Це призведе до витоку секретного токена CSRF третій стороні, потенційно загрожуючи безпеці сеансу користувача [S2].
Захист на рівні браузера: файли cookie SameSite
Сучасні браузери представили атрибут SameSite для заголовка Set-Cookie, щоб забезпечити рівень поглибленого захисту [S1].
- Строго: файли cookie надсилаються лише в контексті першої сторони, тобто сайт у рядку URL-адреси відповідає домену файлу cookie [S1].
- Lax: Файли cookie не надсилаються на міжсайтові підзапити (наприклад, зображення чи фрейми), а надсилаються, коли користувач переходить на вихідний сайт, наприклад, переходячи за стандартним посиланням [S1].
Як FixVibe перевіряє це
FixVibe тепер включає захист CSRF як закриту активну перевірку. Після перевірки домену active.csrf-protection перевіряє виявлені форми, що змінюють стан, перевіряє вхідні дані у формі маркерів CSRF і сигнали файлів cookie SameSite, а потім намагається надіслати підроблене джерело з низьким впливом і звітує лише тоді, коли сервер приймає це. Перевірки файлів cookie також позначають слабкі атрибути SameSite, які знижують рівень захисту CSRF.