職場では、他のアプリケーションに基本的なSSO機能を提供する中央ポータルを使用します。送信されたSSOデータの検証に加えて、既存の社内アプリケーション(パブリックで使用)もすべて、リファラーヘッダーをチェックして、ユーザーが実際に中央ポータルから来ていることを確認します。ただし、セントラルポータルでのJavaScriptコードの変更により、Internet Explorerがリファラーヘッダーの転送を停止し、そのヘッダーをチェックするすべてのアプリがダウンするという問題が発生しました。
私の質問は、リファラーヘッダーを確認することで、基本的なSSO情報(Cookieに含まれる暗号化されたユーザーID)を確認するだけで実際のセキュリティが向上するかどうかです。そうでない場合は、ドキュメント/研究/などがありますか。これを経営者に証明するために使用できますか?
残念ながら、セントラルポータルはサードパーティ製のアプリであり、あまり制御できません。そのため、暗号化されたCookieの形式の基本的なSSO情報とリファラーヘッダー情報だけで、セキュリティを確保できます。
短い答え:no。
長い答え:それは依存します。
リファラーは、クライアントによって送信および制御されるヘッダーです。クライアントからチェックされていないデータは信頼できません。他の人が指摘したように、簡単に操作できます。攻撃者が望むものを何でも含むことができるので、それに依存しないでください。
URLに暗号トークン(http://site.com/x.php?op=1&token=-random-data-
)が含まれている場合、それはわずかに役立ちます。ヘッダーが改ざんされていないかどうかを判断するには、セッション変数を使用してトークンを確認する必要があります。
ただし、トークンを使用した場合でも、プライバシー上の理由から、新しいブラウザ/プラグイン/拡張機能/プロキシがリファラーヘッダーの削除を開始するまで、リファラーチェックは機能しません。
可能であれば、ブラウザーのフィンガープリントヘッダー(User-Agent
、Accept
、Accept-Language
)に関連付けられたクライアントのIPアドレスを使用して、セキュリティの層を増やすことができます。これらのヘッダーをセッション変数に保持することで、誰かがユーザーの資格情報を盗んだかどうか、誰かが認証をバイパスしようとしたかどうか、およびその他の攻撃を検出できます。
ぶら下がっている果物を拾いますが、一般的に、ヘッダーを偽装することは難しくありません。それが過去に問題を引き起こしていたとしても、ビジネスアプリにとってリスクに値するものではないでしょう。
おそらく、最善の方法は、このセキュリティ対策をいかに簡単に回避できるかを経営陣に示すことでしょう。
たとえば、Burpプロキシ( http://portswigger.net/burp/download.html )を使用して、リファラーヘッダーをインターセプトおよび変更/追加できます。
他の人がすでに説明したように、リファラーは簡単に偽装される可能性があります。また、HTTP標準によれば、これらは完全にオプションです。一部のブラウザーには、常にリファラーを抑制するプライバシー設定とアドオンがあり、悪意のあるものは何もありません。
そのため、どのリファラーも正しいリファラーとは見なさず、制御できないWebサイトをリファラーが明示的にポイントしている場合にのみリクエストを拒否することをお勧めします。