HTTPOnly Cookieは、withCredentials = TrueでXmlHTTPRequestを介して送信されますか？
ここで2つの質問があります。
特権REST=エンドポイントにアクセスするJavaScript Webアプリケーションがあります。CSRFから保護したいのですが。
現在、暗号化されたペイロード（encrypt-then-MAC）を含むログインCookieを返すログインシステムが構築されています。私は、Cookieの内容が私の知識なしに改ざんされたり、偽造されたりすることはないと確信しています。
上記のCookieを使用してエンドポイントを保護することはCSRFに対して脆弱であることを知っています。これは、Cookieがブラウザーにリクエストを送信すると自動的に送信されるためです。また、CookieのHTTPOnly値をFalseに設定する必要があるため、特定の攻撃のリスクが高まるため、Double Submit Cookieパターンはお勧めしません。
私がやりたいのは、認証クッキー（中期的にログインを持続させるために使用される）をHTTPOnlyとSecureに設定することです。次に、JavaScriptクライアントがCookieを検証できるトークンエンドポイントへのXHR GETリクエストを作成し、短期トークン（DBに格納した情報を指すハンドルを含む）を直接発行できるようにしたいと思いますユーザーエージェントリダイレクトなしでクライアントに。次に、JavaScriptクライアントは短期トークンを使用して、my RESTエンドポイントへの呼び出しを許可します。
私の最初の質問は、このフローに明らかな欠陥があるかどうかです。 RESTのSynchronizerトークンパターンの妥当な適応のように見えますが、深刻な欠陥があるかどうか、または手順に他のベストプラクティスがあるかどうかを知りたいです。
OAuth 2.0 Implicit Grantフローの実装を検討しましたが、適度な時間ログインを維持できるように、認証Cookieを存在させたいです。
2番目の質問は、withCredentials = Trueを設定した場合、XHRを使用してブラウザからHTTPOnly Cookieがトークンエンドポイントに送信されるかどうかです。 HTTPOnlyはJavaScriptがCookieを読み取る機能を制限していることを知っていますが、Cookieタグはリクエストに含まれ、クライアントには見えませんか？
私は答えを求めてグーグルを調べました、そして私のグーグルは私を失敗させました。私が見つけることができたのは、HTTPOnly Cookieの読み取りに関する記事だけでしたが、送信はしていませんでした。
ヘルプやアドバイスを事前にありがとう！
また、CookieのHTTPOnly値をFalseに設定する必要があるため、Double Submit Cookieパターンは推奨されていません。
HTTPOnlyをfalseに設定する必要はありません。これは、非表示のフォームフィールドの値をCookieと同じ値に設定するJavaScriptコードがある場合のみです。これをJavaScriptなしで行うには、Cookieの値をページサーバー側に出力するだけです（もちろん、XSSを回避するために正しくエンコードします）。
私の最初の質問は、このフローに明らかな欠陥があるかどうかです。
同一生成元ポリシーにより、GETリクエストを攻撃者が読み取ることができないため、これは問題ないようです。ただし、情報の安全性が高い場合は、 JSONハイジャック から保護することをお勧めします。これは長い間問題ではありませんでしたが（Firefox 3を考えてください）、欠陥がブラウザに再導入された場合に備えて、 サイトを保護するための基本的な手順 を少しのコストで実行できます。たとえば、これをPOSTに変更して、応答に解析不能な残骸を追加します。これは、RESTの原則に多少反しますが、これは自分の体重を測る。
2番目の質問は、withCredentials = Trueを設定した場合、XHRを使用してブラウザからHTTPOnly Cookieがトークンエンドポイントに送信されるかどうかです。
はい、そうです。 HTTPOnlyは、クライアントのJavaScript自体から保護します。HTTPリクエストには影響しません。
はい、提出されています。 W3C仕様 を参照してください。
HTTPOnlyはXSSのような攻撃を軽減することを目的としていますが、攻撃者がサイトにXSSを持っている場合、CSRFは必要ありません。 暗号化されたトークンパターン を検討しましたか？