「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
ASP.NETでのCSRF(XSRF)対策方針について纏める。
対応方針の材料 †
POST †
ViewState の ViewStateUserKey? にセッション ID を割り当てる方法がメジャー。
GET †
GETでは攻撃しやすいのでQueryString?で予期せぬCRUD等の操作がされないように作る。
POST †
ValidateAntiForgeryToken?属性とHtml.AntiForgeryToken?ヘルパを使う。
GET †
GETでは攻撃しやすいのでQueryString?で予期せぬCRUD等の操作がされないように作る。
- 主に、業務系SPAの裏のWebAPIは同様に対応が必要になる。
- Cookieに設定したX-CSRF-TOKENを、HTTPヘッダに設定する方式が一般的。
- ソレ以外のWebAPIは、client_id, client_secretの基本認証やbearer tokenを使用。
対応方針の案 †
案件依存だが・・・。
上記から選択。
上記から選択。
上記から選択。
判断材料 †
案件毎にCSRF(XSRF)対策のポリシーを持って対応する必要がある。
- GETが通れば即、warningになるので診断ツールの誤検知が多い。
- CSRF(XSRF)になっても実際に問題は起きるかどうかはアプリの作りによる。
攻撃対象 †
一般的に、足がつかない、
- 匿名アクセス可能なサイトか、
- フリーメールサービスのアドレスでサインアップ可能なサイト
が多いと考える。
攻撃者 †
- 上記のような匿名アクセスが可能なサイトの場合、誰でも攻撃可能。
- 会員制サイトの場合、そのサイトを利用可能な会員でしないと、攻撃方法を見い出せない。
攻撃方法 †
操作中にリンクを踏む必要があるので、
- 対象システム内にリンクの書き込みを行う事が多い。
- しかし、会員制の場合、通常、書き込み者が解れば足がつくので攻撃しない。
対象システム外に書き込みを行う場合、
- そもそもリンクを踏む可能性が低い。
- 会員制サイトを攻撃する場合、会員である必要がある。
GET要求を投げるための偽装テクニックがある。
- 0サイズのiframeタグなどを利用する。
- 0サイズのimgタグのsrc属性に書く
参考 †
Tags: :テスト