1

Authenticity Token経由でリクエストを送信するときに、どこに my を置くかは問題ではないことに気付きましたAJAX。としてフォームに追加するかPOST data、Header.

違いはありますか？特にセキュリティに関しては？

さらに：

でトークンをエンコードしませんでしたJavascript。私は今何かにさらされていますか？

前もって感謝します。

編集：

form.on("sending", function(file, xhr, formData) {
   xhr.setRequestHeader('X-CSRF-Token', AUTH_TOKEN);
   // formData.append('authenticity_token', AUTH_TOKEN);
});

これは、または（コメントアウト）にJavascriptトークンを追加することです。生の鍵です。私はそれを決してエンコードしませんでした。HeaderPOST dataAUTH_TOKEN

4

2 に答える 2

4

パート1

GET パラメータ、POST データ、またはリクエスト ヘッダーを介して認証トークンを渡す場合、まったく違いはありません (Rails では POST/GET パラメータは実質的に同じです)。

コードを見てみましょう (私が今まで見た中で最高のコードではありませんが...)

def verified_request?
  !protect_against_forgery? || request.get? || request.head? ||
    form_authenticity_token == params[request_forgery_protection_token] ||
    form_authenticity_token == request.headers['X-CSRF-Token']
end

リクエストが有効な場合 (次のいずれか)

  1. protect_against_forgery?偽です
  2. リクエストはGET
  3. リクエストはHEADです
  4. params のトークンは、セッションに保存されているものと同じです
  5. ヘッダー内のトークンは、セッションに保存されているものと同じです

トークンはリクエストごとに生成され、後で検査するためにセッションに保存されることを追加する必要があります (後続のリクエストが POST/PUT/PATCH/DELETE の場合)

したがって、認証トークンを渡す両方の方法が有効です。

パート2

AJAXで生の認証トークンを渡すのは危険ですか? いいえ、フォームで渡すことはまったく危険ではありません。さらに説明するために、別のSOの質問で優れた回答を引用します

原因: 認証トークンはセッションに保存されるため、クライアントはその値を知ることができません。これにより、Rails アプリ内でフォームを表示せずにフォームを Rails アプリに送信することができなくなります。サービス A を使用していて、サービスにログインしていて、すべて問題ないと想像してください。ここで、サービス B を利用していて、気に入った写真を見つけて、その写真を押して拡大表示したとします。ここで、サービス B に悪意のあるコードがあった場合、サービス A (ログインしている) にリクエストを送信し、 http://serviceA.com/close_accountにリクエストを送信してアカウントを削除するように要求する可能性があります 。これは、CSRF (クロス サイト リクエスト フォージェリ) として知られているものです。

元の回答: https://stackoverflow.com/a/1571900/2422778

私が書いたものはすべてRailsガイドとStack Overflowの両方で非常によく説明されているので、私はまだこの質問をあなたの怠惰/忍耐の欠如と考えています. 次回は、ここに投稿する前に、もっと粘り強く答えを探してください。
とにかくお役に立てて光栄です。

于 2014-01-04T16:31:18.733 に答える
0

https://www.owasp.org/index.php/Category:OWASP_WebScarab_Projectやhttp://www.charlesproxy.com/などのツールを使用すると、違いがわかります。

これはプロキシであり、ローカルで有効にして HTTP リクエストとレスポンスをいじることができます。

Web 開発に非常に役立ちます。

幸運を。

于 2014-01-03T14:26:06.717 に答える