Как я обеспечиваю больше безопасности для проверки источника запроса
Я разрабатываю одно веб-приложение PHP, я хочу предоставить больше безопасности приложению так, чтобы никто не мог легко повредить функциональность.
Краткое объяснение о моей проблеме: В одном модуле существует один этап, где я проверяю источник запроса (от того, куда этот запрос прибывает из),
В настоящее время я использую HTTP_REFERRER переменная (доступный в php). Я проверяю это значение переменной с одним определенным URL (например, http://www.example.com/test.php). Если точное совпадение существует затем, только я называю дальнейшие действия.
Я - бит, перепутанный с вышеупомянутым подходом, должен ли я использовать HTTP_REFERRER или сверяться с IP-адресом (допустимый запрос, если он прибывает из какого-либо определенного IP-адреса)?
Я также хочу знать лучшие подходы для обеспечения безопасности.
Кто-либо, имеет идею, затем совместно используйте?
Заранее спасибо
3 ответа
Урок №1 по веб-безопасности: НИКОГДА не доверяйте вводу пользователя. И когда я говорю «никогда», я имею в виду никогда. ;) Включение переменной HTTP_REFER в PHP, которую легко взломать с помощью заголовка http (источник: http://www.mustap.com/phpzone_post_62_how-to-bypass-the-referer-se )
Возможным решением при проверке источника является использование токена формы (защита csrf): http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/ но это тоже не так безопасно и возможно только с вашим собственным источником.
Простой пример защиты CSRF (межсайтовый запрос подделки): (Отсюда и простое. Для более безопасного / надежного решения см. Ответ Ладьи)
1) На странице формы создайте какой-нибудь токена и поместите его в сеанс и в скрытое поле формы:
<?php
session_start();
$csrfToken = md5(uniqid(mt_rand(),true)); // Token generation updated, as suggested by The Rook. Thanks!
$_SESSION['csrfToken'] = $token;
?>
<form action="formHandler.php">
<input type="hidden" name="csrfKey" value="<?php echo $csrfToken ?>" />
</form>
2) В обработчике формы проверьте, действителен ли токен.
<?php
session_start();
if($_POST['csrfKey'] != $_SESSION['csrfKey']) {
die("Unauthorized source!");
}
?>
Проверка HTTP_REFERRER на наличие CSRF является допустимой формой защиты. Хотя подделать этот HTTP-заголовок на вашем СОБСТВЕННОМ БРАУЗЕРЕ тривиально, подделать его на другом браузере с помощью CSRF невозможно, потому что он нарушает правила .
По данным Министерства внутренней безопасности, я обнаружил наиболее опасную уязвимость CSRF из когда-либо обнаруженных и входит в 1000 самых опасных уязвимостей всех времен. Компания Motorola исправила этот недостаток с помощью референтной проверки, и этот метод защиты часто встречается на встроенном сетевом оборудовании из-за нехватки памяти.
Более распространенным и более безопасным методом является сохранение криптографического одноразового номера внутри переменной $ _ SESSION и проверка этого для каждого конфиденциального запроса. Простой подход - использовать POST для всех конфиденциальных запросов (например, изменение пароля) и убедиться, что этот криптографический одноразовый номер действителен для всех сообщений в файле заголовка php, если он недействителен, то unset ($ _ POST); . Этот метод работает, потому что, хотя злоумышленник может заставить ваш браузер ОТПРАВИТЬ запросы GET / POST, он не может просмотреть ОТВЕТ и не может прочитать этот токен, необходимый для подделки запроса.Этот токен можно получить с помощью XSS, поэтому убедитесь, что вы протестировали свой сайт на xss .
Хороший метод создания токена csrf - md5 (uniqid (mt_rand (), true)); Этой энтропии должно хватить для остановки CSRF. md5 () используется, чтобы скрыть, как образуется соль. Имейте в виду, что текущее время не секрет, злоумышленник точно знает, в какое время создается запрос CSRF, и может сузить его при создании сеанса. Вы должны предположить, что злоумышленник может сделать много предположений, и на практике это легко сделать, написав на странице несколько окон iframe.
Треур все правильно понял, но я все же хочу прояснить несколько моментов и предоставить вам некоторые источники справочного материала. Как сказал Треур, НИКОГДА не доверяйте вводимым пользователем данным, включая все заголовки, посылаемые браузером.
То, что вы описываете, является типичной атакой подделки межсайтового запроса. Проверка заголовка referrer не является надежной защитой от CSRF-атак, поскольку, согласно RFC2616 (Hyper Text Transfer Protocol 1.1), заголовок referrer является необязательным и может быть опущен браузером в любой момент. Если вы используете SSL, то заголовок referer всегда опускается браузером. Во-вторых, это значение определяется пользователем, и поэтому ему не следует доверять.
Рекомендуемая защита от CSRF-атак - использование синхронизированного шаблона маркера. Это означает, что вы должны создать секретный токен, который встраивается в форму как скрытое поле. Когда форма публикуется, вы проверяете, что секретный маркер присутствует и что он действителен. Существует несколько стратегий создания секретных маркеров. Я опишу один способ создания маркеров:
Для каждого действия в вашем приложении создайте уникальное имя действия. Например, "delete_user", "add_user" или "save_user_profile". Допустим, описанная вами форма имеет имя действия "foobar". Соедините имя действия с идентификатором сессии пользователя и секретным значением.
$stringValue = "foobar" . "секретное значение" . session_id();
Чтобы создать токен безопасности, создайте хэш конкатенированной строки, для создания хэша можно использовать sha1. Чтобы снизить риск атак методом перебора, используйте в хэше ключ большего размера, например, sha 512.
$secretToken = hash("sha5125", $stringValue);
Установите этот токен в скрытом поле вашей формы. Когда форма будет отправлена, создайте токен заново и проверьте, совпадает ли он с тем, который был отправлен в форме. Этот токен действителен для одной сессии пользователя. Кто-то может возразить, что у злоумышленника есть возможность повторно использовать маркер, поскольку он не регенерируется при каждом запросе. Однако при правильной стратегии управления сеансами это не должно вызывать беспокойства.
Как я уже сказал, правильное управление сеансами необходимо. Это означает, что вы не должны держать сессии живыми слишком долго. Особенно уязвимости с фиксацией сеанса сведут на нет все меры защиты от CSRF, поскольку злоумышленник получает контроль над сеансом пользователя и, следовательно, может "предсказать" секретные токены.
Вот несколько ссылок, которые я рекомендую вам прочесть: