サード パーティの Web サイトからの着信 HTTP_REQUEST 呼び出しが、定義したドメインのリストから発信されているかどうかを確認したいと考えています。
HTTP_REFERER を使用してサードパーティのドメインがどこにあるかを確認できることは知っていますが、十分に安全ではありません。人々はそれを偽装したり、Telnet を使用して偽造したりできます。
では、HTTP_ORIGIN はどうでしょうか。すべてのブラウザから送信されますか? 安全ですか？
また、HTTP_REQUEST 呼び出しで REMOTE_ADDR を偽造できますか?
HTTP_ORIGINCSRF (クロス サイト リクエスト フォージェリ) リクエストから保護する方法です。現在、Chrome のみで実装されています (2011 年 11 月現在)。Firefox と Opera をテストしましたが、失敗しました。
リクエスト ヘッダーでの名前は ですOrigin。私のPHPスクリプトのサーバーではHTTP_ORIGIN、$_SERVER配列のように見えます。このヘッダーは、CSRF に対する保護が必要な場合にのみ送信されます (POST だけで十分です)。設定されているかどうかに関係なく、すべてのリクエストのリストを次に示します。
https://wiki.mozilla.org/Security/Origin
残念ながら、OriginヘッダーはChromeでのみ実装されています。2010 年 1 月に Google Chrome のブログで最初に発表されました。
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
Origin ヘッダーによる CSRF 保護
Origin ヘッダーは、クロスサイト リクエスト フォージェリ (CSRF) 攻撃からサイトを防御するのに役立つ新しい HTML5 機能です。CSRF 攻撃では、attacker.com などの悪意のある Web サイトがユーザーのブラウザーに、example.com などのターゲット サーバーに HTTP 要求を送信するように指示し、example.com サーバーを混乱させて何らかのアクションを実行させます。たとえば、example.com が Web メール プロバイダーである場合、CSRF 攻撃は example.com をだまして電子メール メッセージを攻撃者に転送させる可能性があります。
Origin ヘッダーは、どの Web サイトが要求を生成したかを識別することにより、CSRF 攻撃からサイトを防御するのに役立ちます。上記の例では、example.com は、Origin ヘッダーに値http://attacker.comが含まれているため、悪意のある Web サイトからの要求であることがわかります。Origin ヘッダーを CSRF 防御として使用するには、サイトは、(1) Origin ヘッダーがないか、(2) ホワイトリストに登録された値を持つ Origin ヘッダーを持つ要求に応答してのみ状態を変更する必要があります。
私は PHP スクリプトに CSRF 保護を実装しているだけです。私は個人的に Chrome を使用しているので、それで十分です。他のブラウザーがすぐに Chrome に追いつくことを願っています。
おもしろいのは、Mozilla がそのセキュリティ機能を発明したことです。Web サイトでそのヘッダーのドキュメントをたくさん読むことができますOriginが、まだ実装する時間がありませんでした ;-)
HTTP_ORIGIN「http://www.example.com」 - 「http://www.example.com/myform/」からフォームを送信した場合でも、最後にスラッシュなしでprotocolandのみが含まれているようです。domain
PHP スクリプトでの CSRF に対する簡単な保護:
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
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 以外の PORT (80 以外の場合は Origin にポートが含まれます)、HTTPS 接続、および異なるサブドメインからのフォームの送信 (例: sub.example.com => www.exampleへのリクエストの投稿) をサポートするようにアップグレードできます。 .com）。
HTTP_ORIGINすべてのブラウザーで送信されるわけではなく、安全でもありません。
ブラウザから送信されたものは、安全と見なすことはできません。
ここの人々はこれについてすべて間違っていると考えています.「CORS」標準は、サーバーがハッキングされるのを防ぐためのものではありません。目的は、「THE BROWSER」が同じ発信元ポリシーに反するリクエストを緩和する方法を持つことを可能にすることです。クライアントとサーバーが同じページにある場合、「CLIENT」はリクエストを許可するかどうかを決定できます。
明らかに、サーバーを決定に参加させることで、セキュリティ プロセスに役立ちます。
ただし、サーバーを不正アクセスから保護することはできません。それがパスワードと Cookie の目的です。
クライアントは(誰かが言ったように) telnet ツールである可能性があり、作成されたものはすべて偽物です。
しかし、Chrome や FF などのセールス ポイントの 1 つは、Javascript が同じオリジン サンドボックスの外に出ることを許可しないようにすることで役立つということです。攻撃者自身の Web サイト。または、安全でないと判断した他のサイト。
CORS は、ユーザーが使用しているこの他のサイトで、javascript から私のおしゃれなサービスを利用できるようにしたいということを可能にするテクノロジーです。だから私はこのサイトを例外に追加します。つまり、許可されたユーザーがその特定のサイトのブラウザー セキュリティに穴を開けるのを手助けしていることになります。これは、ハッカーが悪用できる穴を意味します。したがって、サービスをセットアップするときの注意ですよね?
これは、CORS が設定されていないサイトは、デフォルトで準拠ブラウザからのクロス サイト スクリプティングから保護されていることを意味します (もちろん、バグやハッキングを除きます)。ブラウザは、このサービスがオリジン サイトの JavaScript に参加するかどうかを尋ねます。クロス サイトが「このいまいましいサイトについて何も知らない」と言う場合、ブラウザの JavaScript エンジンは接続を閉じてデータをダンプします。
要約すると、CORS は物事を安全にするのに役立ちません。ブラウザの機能に穴を開けて、ユーザーをより安全にするのに役立ちます. しかし、うまくいけば、管理された方法で..そして特定のサイトのみ..
HTTP はプレーンテキスト プロトコルです。リクエストのヘッダー/ボディ構造全体を偽造して、あなたが望むことを何でも言うことができます。
HTTP 要求のすべてが偽造される可能性があります。
アップグレード:
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);
}
例：