CORSを有効にするのはいつ安全ですか？

Question

私は特に、サードパーティのウェブサイトがAJAXを通じて私のサービスに電話できるようにするためにJSON/RESTウェブAPIを開発しています。

Access-Control-Allow-Origin: * 

サードパーティのサイトはAJAXを通じて自分のサービスを呼び出すことができます：したがって、私のサービスは、有名なCORSヘッダを送信しています。これまでのすべての罰金。

ただし、私のWeb APIのサブセクションは非公開で、認証（OAuthとaccess_tokenクッキーを持つかなり標準的なもの）が必要です。私のサイトのこの部分でCORSを有効にしても安全ですか？

第三者のWebサイトにも、このサービスの部分とやりとりするajaxクライアントがある場合は、面白いでしょう。しかし、最初に同じ発信元ポリシーが存在する理由は、これが危険である可能性があるということです。後で訪問するウェブサイトがあなたのプライベートコンテンツにアクセスできるようにする必要はありません。

私が恐れているシナリオは、ユーザーがWeb APIまたは信頼できるWebサイトからログオンすることを忘れていることです。これにより、彼は後で彼のプライベートコンテンツにアクセスするために既存のセッションを使用して他のすべてのWebサイトを許可するのだろうか？

だから、私の質問：それは非パブリックコンテンツのCORSを有効にするために、これまで安全

• ですか？
• CORS対応サーバーがcookieを使用してsession_tokenを設定する場合、このCookieはCORSサーバーまたはメインWebページサーバーのドメインに保存されますか？

Answer 1

2番目の質問に答えて（CORS対応サーバーがcookieを使用してsession_tokenを設定すると...？）、そのCookieはCORSサーバーのドメインに保存されます。メインWebページのJSコードは、document.cookieを経由してもCookieにアクセスできません。 .withCredentialsプロパティが設定されている場合にのみ、Cookieがサーバーに送信され、サーバーがAccess-Control-Allow-Credentialsヘッダーを設定した場合にのみ受け入れられます。

あなたの最初の質問はもう少し開いています。それはかなり安全ですが、物事を回避する方法があります。たとえば、攻撃者はDNSポイズニング手法を使用して、プリフライト要求を実際のサーバーに送信し、実際のCORS要求を不正なサーバーに送信する可能性があります。ここでCORSのセキュリティ上のいくつかのより多くのリソースは次のとおりです。

• http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
• owasp.org CORS CheatSheet

最後に、あなたの懸念は周りのあなたのCORSデータにあらゆるウェブサイトへのアクセスを与えています。これを防ぐために、Access-Control-Allow-Origin: *ヘッダーは使用しないでください。代わりに、ユーザーのOrigin値をエコーバックする必要があります。例：

Access-Control-Allow-Origin: http://www.example.com 

このヘッダーでは、http://www.example.comのみが応答データにアクセスできます。

Answer 2

CORSの目的は、XHR要求に対するクロスオリジン要求を許可しながら、どのオリジンがどのリソースにアクセスできるかを指定する権限をサーバーに与えることです。特に、CORSはOriginヘッダフィールドを導入しました。これにより、サーバは通常のXHRリクエストと可能なXHRリクエストを区別できます。このヘッダーフィールドは、ユーザーが設定または変更することはできませんが、XHR要求の場合はブラウザーによって設定されます。

したがって、XHRのみで使用するように設計されたAPIをご利用の場合は、CORSに準拠するよう要求することができます（また、そうする必要があります）。特に、リクエストがサーバー上の状態を変更できる場合は、CSRFに対して脆弱になる可能性があります。

CORFに関係なく、GET要求とPOST要求を偽造する他の方法を使用して、CSRF攻撃が可能であることに注意してください。 CORSは、サーバーが許可する場合にのみ、JavaScriptによるXHR要求のサーバー応答にアクセスすることを可能にします。