サードパーティのWebサイトからの着信HTTP_REQUEST呼び出しが、定義したドメインのリストからのものかどうかを確認したいと思います。
HTTP_REFERERを使用してサードパーティドメインの場所を見つけることができることは知っていますが、十分に安全ではありません。人々はそれを偽装したり、Telnetを使用して偽造したりできます。
では、HTTP_ORIGINはどうですか?すべてのブラウザーから送信されますか?安全ですか?
また、HTTP_REQUEST呼び出しでREMOTE_ADDRを偽造できますか?
HTTP_Originは、CSRF(Cross Site Request Forgery)リクエストから保護する方法です。現在、これはChrome(2011年11月現在)でのみ実装されています。FirefoxとOpera-をテストしましたが、失敗しました。リクエストヘッダーの名前は "Origin 「。PHPスクリプトのサーバー側では、$ _ SERVER変数で「HTTP_Origin」と表示されます。このヘッダーは、CSRFに対する保護が必要な場合にのみ送信されます(POST設定済みかどうかに関係なく、すべてのリクエストのリストを次に示します。
https://wiki.mozilla.org/Security/Origin
アンカータグ-いいえ
ウィンドウナビゲーション-いいえ
IMG-いいえ
iframe、embed、applet-はい
フォーム(GETおよびPOST)-はい
スクリプト-はい
スタイルシート-いいえ
スタイルシートからの依存ロード-NO
リダイレクト-はい
XHR-はい
残念ながら、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攻撃では、悪意のあるWebサイト(attacker.comなど)が、ユーザーのブラウザーにHTTP要求をexample.comなどのターゲットサーバーに送信するように指示し、example.comサーバーを混乱させて何らかのアクションを実行させます。たとえば、example.comがWebメールプロバイダーである場合、CSRF攻撃はexample.comをだまして電子メールメッセージを攻撃者に転送する可能性があります。
Originヘッダーは、どのWebサイトがリクエストを生成したかを識別することにより、サイトがCSRF攻撃を防御するのに役立ちます。上記の例では、example.comは、Originヘッダーに値 http://attacker.com が含まれているため、リクエストが悪意のあるWebサイトから送信されたことを確認できます。 OriginヘッダーをCSRF防御として使用するには、サイトは、(1)Originヘッダーがないか、(2)White-listed値を持つOriginヘッダーがある要求に応じてのみ状態を変更する必要があります。
私は自分のPHPスクリプトにCSRF保護を実装していますが、個人的にChromeを使用していますので、これで十分です。他のブラウザがすぐにchrome.
おもしろいのは、Mozillaがそのセキュリティ機能を発明したということです。WebサイトでそのOriginヘッダーに関する多くのドキュメントを読むことができますが、まだ実装する時間がありませんでした;-)
HTTP_Originには「protocol」と「domain」のみが含まれ、末尾にスラッシュは含まれていないようです:「 http://www.example.com "-" http://www.example.com/myform/ "。
PHPスクリプトのCSRFに対する単純な保護:
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(Originには80以外のポートが含まれる)以外のPORT、HTTPS接続、および異なるサブドメインからフォームを送信するようにアップグレードできます(例:sub.example.com => www.exampleへの要求の投稿.com)。
HTTP_Origin
は、すべてのブラウザから送信されるわけでも、安全でもありません。
ブラウザから送信されたものは安全とは見なされません。
HTTPはプレーンテキストプロトコルです。 [〜#〜] entire [〜#〜]リクエストヘッダー/ボディ構造を偽造して、必要なものを言うことができます。
ここの人々はこれをすべて間違っていると考えています-「CORS」規格は、サーバーがハッキングされないようにするものではありません。その目的は、「THE BROWSER」が同じオリジンポリシーに反するリクエストを緩和する方法を持つことを許可することです。クライアントとサーバーが同じページにある場合、「CLIENT」はリクエストを許可するかどうかを決定できます。
サーバーがセキュリティプロセスに役立つ決定に参加することは明らかです。
しかし、それは不正アクセスからサーバーを保護しません-それがパスワードとクッキーの目的です。
clientは(誰かが言ったように)telnetツールである可能性があります。
ただし、ChromeやFFなどのセールスポイントの1つは、Javascriptが同じOriginサンドボックスの外に出ることを許可しないことで役立ちます。つまり、デフォルトで侵害される可能性があるのは、攻撃者自身のウェブサイト。または、安全でないと判断した他のサイト。
CORSは、言うことを可能にするテクノロジーです-ちょっと、私はユーザーが使用するこの他のサイトのjavascriptから私のおしゃれなサービスを利用できるようにしたいです。したがって、このサイトを例外に追加します。つまり、許可されたユーザーが特定のサイトのブラウザーセキュリティに穴を開けるのを支援しているということです。これは、ハッカーが悪用できる穴を意味します。したがって、サービスをセットアップする際の注意は正しいですか?
つまり、CORSが設定されていないサイトは、既定では、準拠ブラウザーからのクロスサイトスクリプティングから安全です(もちろん、バグやハッキングは禁止されています)。ブラウザは、このサービスがOriginサイトの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);
}
例:
Everything HTTPリクエストで偽装できます。