CSRFトークンはどのようにして攻撃を防止し、JSON APIでどのように安全に使用/回避できますか？
IOSアプリがRuby on Rails JSONを使用してWebサイトと通信するようにしています。ユーザーセッションを作成するためにログインを投稿するときに、 CSRFトークンが欠落していることを発見しました。それが何なのかまったくわからなかったので、それを調べ始めたところ、呼び出し形式が「application/json」の場合にCSRF保護を削除するといういくつかの解決策が見つかりました。そのようにウェブサイトは脆弱なままですか？
JSフォームに同じ問題があるという結果が出ました。そこでの答えは、CSRFトークンに追加することでした。調べたところ、ページヘッダーのメタコンテンツタグにあるように見えます。
だからこれは私を混乱させます、ここに私の質問があります：
- 攻撃的な呼び出しの前の呼び出しで読み取ることができる場合、トークンはどのように保護しますか？悪意のあるサイトは、単にリクエストを行い、受信したメッセージを解析し、トークンを使用して別のリクエストを送信することはできませんか？
- ログインポストアクションのトークンチェックを無効にし、成功の応答とともにトークンを返送しても安全でしょうか？そうでない場合、より良い提案はありますか？
CSRF攻撃の仕組みの概要は次のようになります。
- 良いユーザーであるWebサイトAにログインしているときに、他のサイトのページBにアクセスします。
- そのページは、サイトA（ログインしている）のページXに対してGET（POSTにすることもできますが、設定は少し複雑です）を行います。 。ブラウザーは、既に認証されたセッション/ Cookieを使用して義務付けています
- 設計によるページXにより、アカウントの状態が変化します-典型的な例は、「XドルをBに送金」（あまり現実的ではありません）または「ユーザーステータス行をPWNEDに設定」（より現実的）です
CSRFトークンを実装する方法はいくつかありますが、状態を変更するURL Xへの単純なGETリクエストは、追加の変更情報（トークン）が含まれていない限り機能しないと考えています。 「X？token = 123123213」である必要があります。トークンはかなり頻繁に変更されるため、上記のステップ2は機能しません。攻撃者になろうとする者は、現在のトークンを知りません。
あなたの質問1-攻撃者はページXのコンテンツを表示せず、ページにアクセスするよう強制するだけです。
あなたの質問2-これはすでにログインしたときのアクションに関するすべてであるため、ログインページでCSRF保護を使用しないことは多かれ少なかれ問題ありません。ただし、他のユーザーとしてログインするよう強制され、気付かない可能性があります。
http://en.wikipedia.org/wiki/Cross-site_request_forgery
問題のより一般的なクラスは http://en.wikipedia.org/wiki/Confused_deputy_problem です。