[20] CSRF は、攻撃先 Webサイトの利用者を別のWebサイトから攻撃者が誘導し、攻撃先 Webサイトにおける当該利用者の権限で、利用者 (やWebサイトの著者) の意図せぬ動作を引き起こせるような脆弱性・攻撃です。
Origin: が対象URLの起源と同じなら、問題ありません。Origin: や Referer: の起源が対象URLの起源と異なれば、誤りと判断できます。Content-Type: が
application/x-www-form-urlencoded、
multipart/form-data、
text/plain のいずれかなら、フォームから送信されたかもしれません。Authorization: も Cookie:
もないなら、 XHR などから送信されたかもしれません。auth-scheme が oauth や bearer
など Webブラウザー以外のものなら、フォームから送信されたものではありません。[1] 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 <http://takagi-hiromitsu.jp/diary/20050427.html#p01>
[2] Hixie's Natural Log: Different perspectives in the Web standards community ( 版) <http://ln.hixie.ch/?start=1232666113&count=1>
[3] 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 (高木浩光 著, 版) <http://takagi-hiromitsu.jp/diary/20050427.html#p01>
[4] 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 ( (高木浩光 著, 版)) <http://takagi-hiromitsu.jp/diary/20050427.html>
[5] 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)対策がいまいち進まなかったのはなぜか ( (高木浩光 著, 版)) <http://takagi-hiromitsu.jp/diary/20050703.html>
[6] 高木浩光@自宅の日記 - 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない, 駄目な技術文書の見分け方 その1の2 ( (高木浩光 著, 版)) <http://takagi-hiromitsu.jp/diary/20061115.html>
ストアは、ご利用者とストアとの間でのクレジットカード番号を含むすべての通信内容に対して、SSL(Secure Socket Layer)テクノロジーによる暗号化を施すなどして合理的な範囲内でセキュリティの強化に努めておりますが、更なる安全のため、My Sony ID(もしくはストアログインID)にてログインしている間は、ストア以外のウェブサイトを閲覧されないことをお勧めいたします。
万一、他のウェブサイトを閲覧される場合には、ログアウトしていただくことをお勧めします。なお、ログアウトされた場合、30分以内にログインされないとレジの商品が削除されますのでご注意ください。
[18] Webmention () <https://webmention.net/draft/#h-cross-site-request-forgery>
[19] >>18 ここで例示されている「CSRF 対策」は一体誰から何を守るためのものなんだろう。。。 ここに書いてある通りのことをやっても、カジュアル CSRF 攻撃に第三者を巻き込むことを若干防げる程度じゃないかな。。。
[28] How to Mitigate CSRF Using Origin Headers? () <http://lenxwei.blogspot.jp/2014/08/how-to-mitigate-csrf-using-origin.html>
report-uri参照。)