Я хочу узнать, поступает ли входящий HTTP_REQUEST-вызов с стороннего веб-сайта из списка доменов, которые я определил.
Я знаю, что HTTP_REFERER может использоваться, чтобы узнать, где находится домен третьей стороны, но он недостаточно безопасен. Люди могут обманывать его или использовать Telnet для подделки.
Итак, как насчет HTTP_ORIGIN? Это отправлено из всех браузеров? Это безопасно?
Кроме того, могут ли люди подделывать REMOTE_ADDR в вызове HTTP_REQUEST?
HTTP_ORIGIN – это способ защиты от запросов CSRF (запросов на перекрестный запрос). В настоящее время он реализуется только Chrome (по состоянию на ноябрь 2011 года). Я тестировал Firefox и Opera, но они не сработали. Его имя в заголовке запроса – «Происхождение». На стороне сервера в моем php-скрипте я вижу его как «HTTP_ORIGIN» в переменной $ _SERVER. Этот заголовок отправляется только в некоторых случаях, когда требуется защита от CSRF (достаточно только POST). Вот список всех запросов, независимо от того, установлен он или нет:
https://wiki.mozilla.org/Security/Origin
Якорная метка – НЕТ
Навигация по окнам – НЕТ
IMG – НЕТ
iframe, embed, applet – YES
Форма (GET и POST) – ДА
SCRIPT – ДА
таблицы стилей – НЕТ
зависимые нагрузки от таблиц стилей – НЕТ
Перенаправления – ДА
XHR – ДА
К сожалению, заголовок Origin реализован только в Chrome. Это было объявлено в январе 2010 года в блоге Google Chrome:
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
Защита CSRF через заголовок Origin
Заголовок Origin – это новая функция HTML5, которая помогает защитить ваш сайт от атак с помощью подделок (CSRF). В атаке CSRF вредоносный веб-сайт, скажем, атакующий сайт, указывает браузеру пользователя на отправку HTTP-запроса на целевой сервер, например example.com, который смущает сервер example.com для выполнения некоторых действий. Например, если example.com является поставщиком веб-почты, атака CSRF может обмануть example.com в перенаправлении сообщения электронной почты злоумышленнику.
Заголовок Origin помогает сайтам защищаться от атак CSRF, определяя, какой веб-сайт генерировал запрос. В приведенном выше примере example.com может видеть, что запрос пришел с вредоносного веб-сайта, потому что заголовок Origin содержит значение http://attacker.com . Чтобы использовать заголовок Origin в качестве защиты CSRF, сайт должен изменять состояние только в ответ на запросы, которые либо (1) не имеют заголовка Origin, либо (2) имеют заголовок Origin со значением, указанным в белом списке.
Я просто внедряю CSRF-защиту в своем php-скрипте, я лично использую Chrome, чтобы этого было достаточно для меня, надеюсь, что другие браузеры скоро поймают хром.
Что смешно, так это то, что Mozilla придумала эту функцию безопасности, так как вы можете прочитать много документации этого заголовка Origin на своем веб-сайте, но они все еще не успели ее реализовать 😉
HTTP_ORIGIN, кажется, содержит только «протокол» и «домен», без косой черты в конце: « http://www.example.com » – даже если вы отправили форму с « http://www.example.com/myform / ".
Простая защита от CSRF в скрипте PHP:
if ("POST" == $_SERVER["REQUEST_METHOD"]) { if (isset($_SERVER["HTTP_ORIGIN"])) { $address = "http://".$_SERVER["SERVER_NAME"]; if (strpos($address, $_SERVER["HTTP_ORIGIN"]) !== 0) { exit("CSRF protection in POST request: detected invalid Origin header: ".$_SERVER["HTTP_ORIGIN"]); } } } Этот сценарий все еще может быть обновлен для поддержки PORT, отличного от 80 (Origin содержит порт, когда он отличается от 80), HTTPS-соединений и отправки форм из разных поддоменов (например, sub.example.com => запрос на отправку на http://www.example .com).
HTTP_ORIGIN не отправляется всеми браузерами и не HTTP_ORIGIN .
Ничто, отправленное браузером, никогда не может считаться безопасным.
HTTP – это протокол открытого текста. ВСЮ ПРОСМОТР заголовка / структуры тела можно подделать, чтобы сказать что угодно.
Люди здесь думают об этом все неправильно – стандарт «CORS» не так, что сервер не взломан, даже если это помогает в дополнение к тому, что он делает. Цель состоит в том, чтобы позволить «БРАУЗЕРУ» иметь способ облегчить запросы, направленные против одной и той же политики происхождения. Если клиент и сервер находятся на одной странице, тогда «КЛИЕНТ» может решить, разрешать или не разрешать запрос.
Очевидно, что при участии сервера в решении вы помогаете в процессе безопасности.
Но он не защитит сервер от несанкционированного доступа – для этого нужны пароли и файлы cookie.
Клиент может (как кто-то упоминал) использовать telnet-инструмент, где каждая вещь, созданная, является поддельной.
Но одно из преимуществ Chrome, FF и т. Д. Заключается в том, что они помогут вам, не позволяя Javascript выйти за пределы изолированной изолированной среды, что означает, что единственное, что по умолчанию может быть скомпрометировано, – это материал, нападавших. Или другие сайты, которые решили не быть в безопасности.
CORS – это технология, которая позволяет вам сказать: эй, я хочу, чтобы пользователи могли потреблять мое увлекательное обслуживание из javascript на этом другом сайте, который они используют. Поэтому я собираюсь добавить этот сайт к своим исключениям. Это означает, что вы помогаете своим авторизованным пользователям вытолкнуть дыру в своей безопасности браузера для этого конкретного сайта. Это означает дыру, которую может использовать хакер. Таким образом, забота, с которой вы настроили службу, не так ли?
Это означает, что любой сайт, который не имеет настройки CORS, по умолчанию защищен от Cross Site Scripting от совместимого браузера (конечно, запрет на ошибки и хаки). Браузер спросит, хочет ли эта служба участвовать в javascript исходного сайта, и если в кросс-сайте говорится: «Я ничего не знаю об этом проклятом сайте», тогда механизм javascript браузера закроет соединение и сбросит данные.
Итак, просто подведем итоги – CORS не поможет вам сделать вещи безопасными. Это помогает вам сделать дыру в ваших браузерах, чтобы сделать пользователя более безопасным. Но, надеюсь, управляемым образом .. и только для определенных сайтов ..
Модернизированный:
function isOriginAllowed($incomingOrigin, $allowOrigin) { $pattern = '/^http:\/\/([\w_-]+\.)*' . $allowOrigin . '$/'; $allow = preg_match($pattern, $incomingOrigin); if ($allow) { return true; } else { return false; } } $incomingOrigin = array_key_exists('HTTP_ORIGIN', $_SERVER) ? $_SERVER['HTTP_ORIGIN'] : NULL; $allowOrigin = $_SERVER['HTTP_HOST']; if ($incomingOrigin !== null && isOriginAllowed($incomingOrigin, $allowOrigin)) { exit("CSRF protection in POST request: detected invalid Origin header: " . $incomingOrigin); }
Пример:
Все в HTTP-запросе можно подделать.