c4se記:さっちゃんですよ☆

.。oO(さっちゃんですよヾ(〃l _ l)ノ゙☆)

.。oO(此のblogは、主に音樂考察Programming に分類されますよ。ヾ(〃l _ l)ノ゙♬♪♡)

音樂は SoundCloud に公開中です。

考察は現在は主に Scrapbox で公表中です。

Programming は GitHub で開發中です。

CSRF (cross site request forgery) とは

半年以上前 (2013-08-12よりまえ) に書いたものだが、公開しわすれてゐた。Vimのmemoを整理してゐたら出てきたから、何かの序で [ついで] とおもひ公開する。
凄くわかりにくい文章だ。私が悪い。pointは、攻撃者が用意したWeb pageにわたしたちがaccessした時、攻撃者の用意したHTTP requestをわたしたちのWeb browserに送らせるのがCSRF攻撃であること、故に攻撃者の用意できないHTTP requestを使ふ工夫をすればよいと云ふことだ。page遷移は関係ない。HTTP requestだけが重要だ。然してHTTPはそもそもWebの根幹であり、clientはどんな本質的な防衛策も用意できない。HTTP 1.1の設計上の欠陥である (HTTP 2.0はどう成ってゐるのか)。100% site作成者側が対策をおこなうしか術はない。そして100%対策をおこなふことができる筈だ。clientには、どんなまともな気をつけようも有りはしない。極めて嘆かわしいがWeb siteはuserのものではないから (だからAGPLができてGPLv3ができたのだが、この問題は明らかに解決されてゐない)。
ちなみに此っちをみた方が好い。
cf. 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリCSRF)の正しい対策方法 http://takagi-hiromitsu.jp/diary/20050427.html#p01

CSRF (cross site request forgery) とは

CSRF (cross site request forgery) とは、利用者があるWeb siteを表示した際に、利用者の意図しない外部のWeb siteに対して自動でHTTP requestを発行させ、利用者のclient (Web browser) に不正な動作を行わせる攻撃をいう。これによってその外部のWeb siteに対し、利用者の意図しないうちに、その利用者がもし意図すれば可能であったあらゆる動作を、利用者が意図して行ったか否かほぼ判別できない痕跡で行いうる可能性がある。Web serverにとってはHTTP requestがclientから有り得る入力の全てだからだ。
clientの利用者が可能な対策は、現実的にはほぼ存在しない。例えばリチャード・ストールマン (Richard Matthew Stallman) の様に、Webを閲覧する際には遠隔のcomputerにwgetでHTMLを落とさせemailで手元に受け取って読むと云う事を実行すればCSRFは防げる。また、リチャード・ストールマンの様に、ほぼFSF管轄以外のWeb siteは閲覧しないと云う体勢をとれば、CSRFは防ぐことができる。要するに自らの送るHTTP requestを厳重に制限すれば、防げる可能性は高い。しかしこれらは現実的ではない。
よって、Web siteの構築側がCSRFの対策を行なっておく以外にはない。送られて来て困る可能性の有るHTTP requestに就いては、client利用者が意図したものであるか否か、server側が判別出来る様にする必要が有る。

対策

代表的な対策としては、以下の二つが知られる。

  1. (わたしは此の方法を一切推奨しないが) HTTP headerのRefererを参照し、不正なRefererと見做せば処理を拒否する。CSRFに当たるHTTP requestは、必ずclientが外部のWeb siteを表示した際に送られてくる。自らのWeb siteをRefererとしたHTTP requestは、CSRFに当たらない。Web siteは、clientがどのようなRefererでHTTP requestを行うか制御できないからである。外部のWeb siteは、自らのWeb siteをRefererに設定したrequestを、利用者に意図せず送らせることができない。故に、もし自らのWeb siteをRefererにもった不正なHTTP requestが有れば、心配すべきは不正な利用者による意図的な攻撃か、Web site自体のbugや改竄であって、CSRFではない。clientによってはRefererが空白の場合もありうる。このrequestに対しては、安全を期して拒否しなければならない。この対策法の欠陥は、正当な利用者を拒否する可能性が充分に高いと云う点だ。古い携帯電話のWeb browserにはRefererを送信しないものがある。また、利用者がsecurity上の観点からRefererを送信しないよう設定している場合がある。これらはどちらも正当な利用者であり、考えによってはむしろ望ましい設定をしている利用者であるため、この利用者を排除する当対策は、導入前に検討を要する。ちなみにOpera 12でRefererをoffに設定するのは極めて簡単であった。しかしそれ以外の場合でも、送るHTTP requestを決めるのは100%利用者のclientである。
  2. 利用者が送るべきHTTP requestを、利用者が正当な状況下でしか送信できない値を含めることで、変更する。この「或る値 (token)」は、利用者とWeb site側以外が知り得ない、あるいは予測し得ないものである必要がある。まず予測し得ない値にする為に、暗号論的に強固な乱数を利用する。この値をまずWeb server側が生成する。
    この値を利用者と共有する方法には、form要素のhidden属性の値として渡すことが行われる。この値は攻撃者が予め手に入れる事はできないため、事前に不正なHTTP requestを用意する事はできない。またCSRFによりこの値を発行させる事はできる (このrequestにより不正な動作は行い得ない事は前提とする。これはWeb siteの設計者が保証しなければならない) が、知ることはSame Origine Policyによりできない為、tokenが必要な危険なrequestは回避される。中間者攻撃を行えばこの値を知るのは容易であると想像できるが、中間者攻撃が可能な状態であればわざわざCSRFは行わない。他にsession fixation脆弱性等によってもこのtoken値を知られる可能性がある。
    またtokenを知らなくてもよいと企み、攻撃対象のWeb siteをこっそり表示させ (可能である)、これを利用者に意図せず自動で操作させようとしても、同じくSame Origin Policyにより自動動作は防がれる。但しclick jacking攻撃により、利用者の助けを借りれば攻撃は成功させることが可能である。また別に、Web site側にXSS (cross site scripting) 脆弱性があればCSRFも成功する。XSS対策はCSRF対策の前提である。

出題文中のWeb siteにて行われている事が確認できるのは、2番のtokenを照合する対策である。対象Web siteは、おそらくsessionの発行時にCSRF用tokenも生成している。CSRFを対策すべきformには、formの送信時に以下の様なhidden値が埋め込まれている。

<input type="hidden" name="csrf_token" value="d37b6e0d70542ea28d6b6aed106971a3">

value属性の値がこの場合のCSRF token値である。form情報POST時にこのtoke値も同時に送られる。server側は、事前に生成していた値とtoken値が同じ事を確かめ、処理を継続する。この値はserver側と利用者の二人しか知りえず利用もできない為、token値が一致するrequestは、利用者の正当なrequestの筈だからである。