Насколько безопасен HTTP_ORIGIN?

Question

Я хочу узнать, поступает ли входящий вызов HTTP_REQUEST со стороннего веб-сайта из списка доменов, которые я определил.

Я знаю, что HTTP_REFERER можно использовать, чтобы узнать, где находится сторонний домен, но он недостаточно безопасен. Люди могут подделать его или использовать Telnet для фальсификации.

Итак, как насчет HTTP_ORIGIN? Это отправлено со всех браузеров? Это безопасно?

Кроме того, могут ли люди подделать REMOTE_ADDR в вызове HTTP_REQUEST?

Answer 1

HTTP_ORIGIN - это способ защиты от CSRF-запросов.В настоящее время он реализован только Chrome (по состоянию на ноябрь 2011 года).Я тестировал Firefox и Opera - но они провалились.Его имя в заголовке запроса - «Происхождение».На стороне сервера в моем php-скрипте я вижу его как «HTTP_ORIGIN» в переменной $ _SERVER.Этот заголовок отправляется только в некоторых случаях, когда требуется защита от CSRF (достаточно только POST).Вот список всех запросов, установлен ли он или нет:

https://wiki.mozilla.org/Security/Origin

Якорный тег - NO

Окно навигации - NO

IMG -НЕТ

iframe, embed, applet - ДА

Форма (GET и POST) - ДА

СКРИПТ - ДА

таблицы стилей - НЕТ

зависимые загрузки из таблиц стилей - НЕТ

Перенаправления - ДА

XHR - ДА

Исходный заголовок реализован только в Chrome, к сожалению.Впервые об этом было объявлено в январе 2010 года в блоге Google Chrome:

http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html

Защита CSRF с помощью заголовка Origin

Заголовок Origin - это новая функция HTML5, котораяпомогает защитить ваш сайт от атак подделки межсайтовых запросов (CSRF).В CSRF-атаке вредоносный веб-сайт, например attacker.com, инструктирует браузер пользователя отправлять 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так что мне этого достаточно, я надеюсь, что другие браузеры скоро поймают 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"]);
        }
    }
}

Этот сценарий еще можно обновить для поддержкиПОРТ, отличный от 80 (Источник содержит порт, отличный от 80), HTTPS-соединения и отправка форм из разных поддоменов (например,sub.example.com => отправка запроса на www.example.com).

Answer 2

HTTP_ORIGIN отправляется не всеми браузерами и не является безопасным.

Ничто, отправленное браузером, не может считаться безопасным.

Answer 3

HTTP - это текстовый протокол.Структура заголовка / тела запроса ENTIRE может быть подделана, чтобы сказать что угодно.

Answer 4

Люди здесь думают об этом все неправильно - стандарт «CORS» не так, что сервер не будет взломан, даже если это помогает в дополнение к тому, что он делает.Цель состоит в том, чтобы позволить «БРАУЗЕРУ» иметь возможность облегчить запросы, которые противоречат той же политике происхождения.Если клиент и сервер находятся на одной и той же странице, «КЛИЕНТ» может решить, разрешить или нет запрос.

Очевидно, если сервер участвует в решении, которое вы помогаете в процессе обеспечения безопасности.

Но это не защитит сервер от несанкционированного доступа - вот для чего нужны пароли и куки.

клиент может быть (как кто-то упоминал) телнетоминструмент, в котором каждая созданная вещь является фальшивкой.

Но один из преимуществ Chrome, FF и т. д. заключается в том, что они помогут вам, не позволяя Javascript выходить за пределы той же самой песочницы происхождения, что означаетпо умолчанию единственное, что может быть скомпрометировано, - это то, что находится на собственном веб-сайте «злоумышленников».Или другие сайты, которые решили не быть безопасными.

CORS - это технология, которая позволяет вам сказать - эй, я хочу, чтобы пользователи могли использовать мой шикарный сервис из javascript на этом другом сайте, который они используют.Так что я собираюсь добавить этот сайт в мои исключения.Это означает, что вы помогаете своим авторизованным пользователям пробить брешь в их безопасности браузера для этого конкретного сайта.Что означает дыру, которую может использовать хакер.Таким образом, забота, с которой вы настраиваете службу, верно?

Это означает, что любой сайт, на котором не настроен CORS, по умолчанию защищен от межсайтовых сценариев из совместимого браузера (за исключением ошибок и взломовкурс).Браузер спросит, хочет ли эта служба принять участие в javascript исходного сайта, и если на перекрестном сайте будет написано «Я ничего не знаю об этом проклятом сайте», то механизм javascript браузера закроет соединение и сбросит данные.

Итак, подведем итог - CORS не поможет вам обеспечить безопасность.Это поможет вам сделать дыру в ваших браузерах способной сделать пользователя более безопасным.Но, надеюсь, управляемым способом ... и только для определенных сайтов ..

Answer 5

Модернизировано:

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: // media.mydomain.com TRUE
• http: // offline.mydomain.com TRUE
• http: // domen1.mydomain.com TRUE
• http: // domen_1.mydomain.com TRUE
• http: // domen-1.mydomain.com TRUE
• http: // ololomydomain.com FALSE
• http: // mydomain.com TRUE
• http: // pro.mydomain.com TRUE
• http: // super.pro.mydomain.com TRUE
• http: // super.pro.fakemydomain.com FALSE
• http: // pro.fakemydomain.com FALSE

Answer 6

Все в HTTP-запросе может быть подделано.