Требуется аутентификация в GET и Параметры POST, а не только файлы cookie;
Проверка заголовка HTTP Referer;
увидел этот пост в википедии и задавался вопросом, как я могу их применять.
ok... Я использую фреймворк Kohana PHP, и у меня есть возможность определить заголовок referrer, но что именно я проверяю в заголовке referrer? функция framework возвращает URL-адрес реферера
и как я могу проверить параметры GET и POST? против чего? хранящаяся информация? ожидаемый тип?
Чтобы предотвратить CSRF, вы захотите проверить одноразовый токен, POST и связанный с текущим сеансом. Что-то вроде следующего.,.
На странице, где пользователь просит удалить запись:
confirm.php
<?php
session_start();
$token = isset($_SESSION['delete_customer_token']) ? $_SESSION['delete_customer_token'] : "";
if (!$token) {
// generate token and persist for later verification
// - in practice use openssl_random_pseudo_bytes() or similar instead of uniqid()
$token = md5(uniqid());
$_SESSION['delete_customer_token']= $token;
}
session_write_close();
?>
<html>
<body>
<form method="post" action="confirm_save.php">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
Do you really want to delete?
<input type="submit" value=" Yes " />
<input type="button" value=" No " onclick="history.go(-1);" />
</form>
</body>
</html>
Затем, когда дело доходит до фактического удаления записи:
confirm_save.php
<?php
session_start();
// validate token
$token = isset($_SESSION['delete_customer_token']) ? $_SESSION['delete_customer_token'] : "";
if ($token && $_POST['token'] === $token) {
// delete the record
...
// remove token after successful delete
unset($_SESSION['delete_customer_token']);
} else {
// log potential CSRF attack.
}
session_write_close();
?>
Маркер должен быть сложно угадать, уникальным для каждого запроса на удаление, принятым только через $ _POST и срок его действия истекает через несколько минут (срок действия в этом примере не показан).
При проверке рефералов все ваши действия направлены на то, чтобы рефери был на вашем сайте/в системе. Если референт не существует или находится на чужом сайте, проверка реферальных данных терпит неудачу, и вы, возможно, не захотите выполнять какие-либо запросы.
В прошлом проблемы с различными технологиями и браузерами (flash..et al) допускали подделку реферальных заголовков. Его что-то рассмотреть. Существует несколько способов использования javascript для ссылки на ресурсы, в которых данные реферала отсутствуют/переданы в заголовке запроса.
Такое поведение несколько отличается между браузерами. Если вы используете javascript для отправки формы, как правило, хорошо. Если вы используете что-то вроде window.location, скорее всего, вам не следует ожидать, что реферальные данные будут присутствовать.
Популярным методом предотвращения CSRF является не использование файлов cookie и всегда передача состояния между ссылками... Передача токена сеанса во всех ссылках в приложении.
[Примечание:] Структура Kohana устарела, новая вилка для Kohana PHP 7 https://koseven.ga/, и она поддерживает функциональность CSRF - это безопасность класс.
Вы можете использовать Официальную функцию безопасности koseven. Вот ссылка на класс безопасности koseven.