2016-06-14 12 views
0

私のアプリケーションをcsrfから保護したいと思います。問題の内容とソリューションの仕組みを理解できませんでしたが、いくつかの研究の後、私はAngularが使用する解決策を思いつきました。私の知る限りだと、私の解決策は、以下の手順を実行する必要がありますリクエストごとのcsrfトークンはどのように動作するのですか

- 私スパ

用>クライアント要求 - >私は(ないHttpOnlyのJSはそれを読むことができるようになりますように)CSRFトークンを送信します。また、このcsrfトークンをサーバーのユーザーセッションに保存します。

- >投稿リクエストごとに、クライアントがcsrfトークンを読み取り、X-XSRF-TOKENヘッダーをこのトークンに設定するようにします。

→リクエストヘッダーとユーザーセッションcsrfトークンを確認することですべてのリクエストをチェックします。もし一致すれば、必要ならば認証のためにjwtもチェックします。

- > csrfトークンを検証した後、データベースを変更します。また、csrfトークンを再度変更し、新しいトークンをユーザーに送信し、セッションのトークンを変更します。

しかし、私はこれがどのように役立つかわかりません。もし私にxssの脆弱性があるなら、注入されたjavascriptコードでも同じことができます。私は問題と、そのようなソリューションがどのように役立つかを理解したい。ありがとう。

FYI。また、JWTベースの認証を、エクスプレスサーバー上のセッション管理にredisを使用して実装しています。

答えて

2

次のリンクは役に立ちますが、ここではまとめておきます。

https://nirajrules.wordpress.com/2010/01/16/cross-site-scripting-xss-vs-cross-site-request-forgery/

CSRFは、クロスサイトリクエストについての詳細です。誰かがあなたのフォームアクションを見つけて、それらに直接投稿するなどです。それがCSRFトークンが防止するのに役立つものです。実際にあなたのフォームにエンドポイントを送信するフィッシングサイトである偽のウェブサイトを作っているとします。

XSSは非常に異なります。あなたのページ内で実行できる悪意のあるjavascriptがあれば、そのトークンにアクセスして取得できます。しかし、これらは異なるものであり、CSRFトークンの価値を低下させません。

幸運。

+0

私は読んだあなたのポイントと以前のものを得た。だから私の実装は有効です。なぜなら私はトークンでヘッダを必要とし、クロスサイト要求は私のクライアントでやっているようにできないからです。 – FurkanO

+0

サイトに注入されていないクロスサイトは、簡単にクッキーを取得できません。したがって、これに加えてあらゆる認証は、あなたの安全を保ちます。 CSRFトークンは短命であり、単一の要求に対してのみ有効であることが推奨されます。 –

関連する問題