2017-06-23 18 views
0

CSRFトークンをjavascript(jquery以外の)AJAX関数を介して送信されたフォームに渡そうとしています。受け入れられた知恵は、実際のフォームに隠れた入力としてトークンを含めるように見えます。私が見ているように、隠された入力の内容はブラウザ検査機能を使って簡単に見ることができます。トークンを渡すより安全な方法はありますか?CSRFトークンの受け渡し

答えて

1

CSRFトークンはクライアントブラウザに隠されているわけではないため、ソースコードからアクセスできるという問題はありません。ここで私が "隠し"と言うとき、私はフォームのHTMLプロパティ "隠された"を話すのではなく、ページソース、スクリプトの実行、またはネットワークトラフィック(本当に隠されている)を分析することによってトークンを開示する必要があります。

CSRFトークンが有用な理由を理解する必要があります。攻撃者が外部ドメインの下でホストされている悪意のあるWebページを作成した場合(POSTまたはGETをWebサイトに送信した場合)、認証されたユーザー(Cookieに公開セッションとセッションIDを持つ犠牲者)被害者のブラウザはターゲットURLを検出し、GET/POSTヘッダーにCookie /セッションIDを追加し、認証されたユーザーの代わりにアクションを実行します(「アカウントを破棄する」など)。

ランダムなCSRFトークンをソースに作成した場合、攻撃者はそれを読み取ることができません(クロスドメインのコンテンツ分離により、被害者のブラウザの代わりにページを読み込んでコンテンツを読み込むことができないため) GETまたはPOSTを実行する悪質なページ。

その他のWebサイトでは、独自の静的CSRFトークン(セッションinitでユーザーごとに生成されます)を使用します。これはCookieに保存され、JSを介してサイトのフォームに含まれます。結果は同じです。トークンはフォーム送信の一部になります(クライアントのブラウザからもアクセス可能です)。各フォームのCSRFトークンの生成を避けるだけで、サーバーはサイドチャネルトークン管理を行うのではなく、トークンとクライアントのセッションデータを簡単に比較できます。

+0

私が実際にビルドしているアプリは、それぞれ独自のページにいくつかのフォームがあります。私は静的トークンを持つのではなくフォームの1つが読み込まれるたびに新しいCSRFトークンを生成することを考えていました。 – bob

+0

私は単純さと保守性のために、別の方法をとっていきます。私は、クッキー内にCSRFトークンを格納し、すべてのフォームで同じものを再利用する銀行レベルのプラットフォームを知っています。 CSRFが毎回変更された場合、セキュリティ・サイドには実質的な付加価値はありません。一度漏れた場合、ユーザー・セッション全体が漏洩し、CSRFが問題の少ない問題になるからです。しかし、結局のところ、十分に自動化されていれば、どちらも実行可能なソリューションです。 – Fabien

+0

良い点 - ありがとう – bob