12月10日にPC版がスタートしたサイバーエージェントのミニブログサービス「Amebaなう」で、あるURLをクリックすると、「こんにちは こんにちは!!」というフレーズとクリックしたURL文字列が自動で投稿され、「はまちや2」さんのアカウントを自動でフォローしてしまうという現象が広がった。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を突いたもの。同社は10日夜、URLをクリックしないようユーザーに告知。誤ってクリックした場合は投稿を削除し、はまちや2さんのフォローを外すよう呼び掛けた。11日朝までに脆弱性も修正したという。 mixiでも2005年、あるURLをクリックすると「ぼくはまちちゃん！」という日記が勝手に投稿されるという、CSRFを利用したスパムが流通したことがあった。コミュニティーサイト構
teratailに以下のような投稿がありました。 PHPでメールフォームを作成したので、脆弱性がないかアドバイスいただけないでしょうか。 エンジニアでもなければ、PHPもろくに書けない雑魚ですが、「php メールフォーム 作り方」でググって表示されるサイトを見ると、「んんんんん？？？」と思うところがあります。 これらを参考にしたり、コピペする方は、記述されているコードの良し悪しは判断できないかと思います。 そのような方々が参考にできるメールフォームを作りたいという思いで、調べて作りました。 周りに書いたコードを確認してもらえる人もいないので、皆様からのアドバイスがほしいです((_ _ (´ω｀ )ﾍﾟｺ 【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうかより引用 どれどれ…と確認すると、トークンのチェックが入っているにも関わらずクロスサイト・リクエストフォージ
VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について - debiruはてなメモ
2015年12月に私が発見した VALUE-DOMAIN での CSRF 脆弱性について、その脆弱性の報告と修正までの経緯を記しておきます。 きっかけ アカウント削除ページの作り アカウント削除ページの問題点 VALUE-DOMAIN への報告 CSRF 攻撃によるアカウント乗っ取りの問題 IPA への届出 余談：IPA への届出の仕方について IPA へ届出した後の状況 VALUE-DOMAIN ユーザの方へ きっかけ 数年前に VALUE-DOMAIN を利用していましたが最近は使っていないのでアカウントを削除しようとしたところ、アカウント削除操作を行うページの作りが「不自然である」ことに気付きました。更に調べたところ CSRF 攻撃によってアカウント乗っ取りが可能な状況であることが分かりました。 アカウント乗っ取りが可能な CSRF 脆弱性は2015年12月22日にIPAに報告し、2
crossdomain.xml と CSRF 脆弱性について - 2nd life (移転しました)
crossdomain.xml を安易に設置すると CSRF 脆弱性を引き起こす可能性があります。というのも、ここ数が月、それなりの数の crossdomain.xml による CSRF 脆弱性を発見し(現在、それらのサイトでは対策がなされています)、まだまだ Web プログラマに脆弱性を引き起こす可能性がある、という考え方が浸透してないんじゃないか、と思ったので。 先月、Life is beautiful: ウェブサービスAPIにおける『成りすまし問題』に関する一考察にも crossdomain.xml について書かれてたのですが、その後もいくつかのサービスで crossdomain.xml を許可ドメインすべてにしているサービスがあったので、注意喚起としてエントリーに書き起こします。 自分も一年半ぐらい前は、crossdomain.xml を許可ドメインすべて ('*') にして設置し
図のように、大垣本のCSRF対策方式（以下、「大垣方式」と表記）では、トークン（同書ではフォームIDと表記）をランダムな鍵として生成（②）し、それをフォームの隠しフィールドとDBに保存します（③、④）。ユーザーがフォームをサブミット（⑤）すると、送信されてきたトークンがDB上に存在するか確認（⑥）し、あればトークンを削除（⑦）して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR
高木浩光＠自宅の日記 - ハマチをちゃんとテリヤキにするのは難しい, CSRF脆弱性を突く攻撃行為を現行法で処罰できるか
■ CSRF脆弱性を突く攻撃行為を現行法で処罰できるか CSRF脆弱性が攻撃されることは、それがもたらす被害の内容によっては、不正アクセス禁止法が守ろうとしているものと同等のものが侵害される場合もある。たとえば、本人でなければ見ることのできないはずの情報が、CSRF脆弱性を突く罠を仕掛けた者に送信されるといった攻撃は、不正アクセス行為の典型的な侵害事例と同様の被害をもたらす。また、同法の目的である「アクセス制御機能により実現される電気通信に関する秩序の維持」（第1条）が損なわれるという点も共通する。 しかしながら、CSRF脆弱性を突く攻撃行為は、結果が同じてあっても手段が異なるために、不正アクセス禁止法による処罰は難しいのではないかと以前から思っていた。これについては、2005年7月3日の日記「クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか」にも書いた。
CSRF対策のtokenはセッションIDで良い セキュリティ的にワンタイムトークン>セッションIDではない。 という話が、この辺の記事に書かれています。 高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか？ 肝はこういう事のようです tokenは外部のサイトから知り難い(実質知り得ない)ものでないといけない セッションIDはcookieに格納される document.cookieは自ドメインのものと親ドメインのものしか見れない→外部サイトで動かすJavaScriptからは参照できない セッションIDは『暗号学的に安全な擬似乱数生成系で生成されているはず』(引用) 推測も事実上できない 補足すると、セッションIDを使用したCSRF対
悪意のある遠隔操作プログラム（トロイの木馬）で他人になりすまし、犯行予告を繰り返していた一連の事件で、犯人が送ったとされるメール全文を、送付先の1人である弁護士の落合洋司さんがこのほど、ブログで公開した。犯行に使われたトロイの木馬は犯人が1から開発したことや、警察を試す意図があったことなどが記されている。 落合弁護士は、「事件に関する関心が高まっていることや、既に一部で（不完全なまま）公開されつつあることも考慮」し、公開を決めたという。個人名やURL、メールアドレスなど「支障があると考えられるもの」は伏せた上で公開している。 トロイの木馬は「自作」 明大生の事件はCSRF脆弱性狙う メールのタイトルは「【遠隔操作事件】私が真犯人です」。本文では「■はじめに」「■私の目的」「■私が関与した事件一覧」など6つの見出しで、犯行の目的や手口などを詳細に説明している。 冒頭で、「現在報道されている大
イラストSNS「pixiv」の一部の作品に対し、「ツマンネ」「ヘタクソ」「気持ちわる」といった中傷コメントが意図せずに投稿されてしまう問題が起きた。運営会社が調べたところ、何者かがユーザーに脆弱性を悪用した外部URLをクリックさせ、意図しないコメントを投稿させていたことが分かり、既に脆弱性は修正した。 ピクシブの開発者ブログによると、問題は2月5日～14日に発生。イラストのキャプション欄などに貼られていたあるURLをクリックすると、外部サイトを経由し、中傷コメントが投稿されるようになっていた。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を悪用していた。脆弱性は14日に修正した。アカウントが乗っ取られたわけではなく、個人情報の漏えいや改ざんはないとしている。ウイルス感染の被害もないという。 pixiv
書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性について追試してみた — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
以下の記事よると、書籍『Webアプリケーションセキュリティ対策入門』のサンプルにCSRF脆弱性があるということなので、確認してみることにしました。 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記 サンプルのインストール まず、Webアプリケーションセキュリティ対策入門の付録を更新 | yohgaki's blogよりサンプルコードsimple-bbs.tar.bz2をダウンロードします。 展開し、データベースを作成します。 $ tar xvf simple-bbs.tar.bz2 $ (cd simple-bbs/dat/install/; php initdb.php) データベースを作成：/Users/kenji/tmp/simple-bbs/dat/bbs.dat form_idテーブルを作成しました。 userテーブルを作成しました。 thre
S氏に「これってCSRF起こりません？」と指摘され、「あっ！」と思った。とりあえず概要をまとめる。とりまとめなので乱文なのはご容赦を。 結論から先に言うと、CSRFは特定の状況で「起こりうる」。 Twitterには先ほどこの件について報告した。とにかく「URL付きの変なupdateが飛んできたらうかつに踏まないように」。この件ははまちちゃん方式で殖える可能性がある。はまちちゃん事件はgoogleで偽装していたが、twitterはご丁寧にも長いURLをtinyurl化してしまうので、偽装の必要すらない。追記: tinyurlは必ず独自のRefererを送るようにしている模様。むしろ裸のURLが危ない（tinyurlがこの実装を取り消す日が来るまでは）。 とりあえず普通にCSRFを再現してみる。が、Web、APIとも他所サイトのReferer付きリクエストを蹴る模様。なので、Refere
先日より、はてな各サービスにおける CSRF 脆弱性の対策方法を見直しております。これまではリファラをチェックする方法を採用しておりましたが、この方法は対策としては不十分な点があり、新たに POST によるデータの送信時、セッションIDを用いた検査を行う方法を採用しております。 現在、各サービスでの対応がほぼ完了しております。サードパーティ製のツールなど、外部から直接データを POST しているアプリケーションなどが、今回の変更により動作しくなっている可能性がございますが、はてな各サービスの安全性向上が目的の変更となりますので、ご了承いただければ幸いです。 なお、セッションID は Cookie に保存されている rk パラメータの値を MD5 BASE64 でシリアライズした値になります。Cookie を取得可能なサードパーティ製ツールであれば、rk パラメータをエンコードした値を rk
CSRF脆弱性のあるフォームに犯罪予告を書き込んだとして人が逮捕されるニュースが流れた。ところが、どうもそのニュースにはきな臭いところがある。 というのも、その書きこまれたフォームには、CSRF脆弱性があるのだという。つまり、攻撃用のWebサイトを閲覧したものなら誰でも、犯罪予告の書き込みをおこなってしまう状況にあった。 もちろん、このブログを今読んでいるという事は、すでに攻撃が完了している可能性だってあるのだ。おっと、今ブラウザを閉じてももう遅い。確認のためには、ソースコードを読むべきである。 そのような脆弱性の存在するフォームへの書き込みをもとに逮捕するのは危険だ。無知によるものでなければ、邪悪な意図があるのだ。ただ、この場合は、無知によるものであろう。 さて、件の逮捕された被害者は、今、外部との連絡を遮断され、非人道的な方法で自白を迫られていることだろう。 犯行予告に使われたと思われ
ITmediaのアンケートにCSRF脆弱性
ITmediaの記事「「Wii U」の価格、高い？ 安い？」で行われたアンケートがCSRF攻撃を受け異常な結果に(対策済み) http://gadget.itmedia.co.jp/gg/articles/1209/13/news099.html 対策済みとのことですが、根本的な対策(ワンタイムトークンetc)ではなく、受け付けるリファラを記事URLのみにしただけの模様。
OAuth 2.0 では state パラメータってのがあって、それをちゃんと使わないと CSRF 脆弱性ができちゃうよって話は、@ritou 先生のスライドなどでみなさん勉強したんではないでしょうか。state パラメータは RFC 6749 では RECOMMENDED 扱いで、REQUIRED ではありませんが、OAuth 2.0 をログインに使う場合は REQUIRED にすべきでしょう。OAuth 2.0 をログインに使うの、Token 置換攻撃とか Covert Redirect + Code 置換攻撃とか、いろんな罠がありますねぇ〜。 OAuth 1.0 ならそんなことないのに… そう思ってた時期が、僕にもありました。 でも @ritou 先生よく言ってるじゃないですか。「Twitter の OAuth 実装クソや」って。でね、ほんとにクソやったんすよ、コレが。 さて、Dev
Laravel 4のCSRF脆弱性は何が問題だったのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHPでのある意味「典型的な脆弱性」だったので記事を書くことにしました。 Laravel 4のCSRF脆弱性とは？ Laravel 4.2.10以前にCSRF保護が無効になる脆弱性が報告されました。 この脆弱性は、Laravel標準のCSRF保護（csrfフィルタ）を簡単に無効化することができるものです。 既存サイトでは、今すぐ、以下の修正パッチを摘要する必要があります。Laravelのアップデートでは修正されません。 From ba0cf2a1c9280e99d39aad5d4d686d554941eea1 Mon Sep 17 00:00:00 2001 From: Taylor Otwell <taylorotwell@gmail.com> Date: Sun, 9 Nov 2014 16:29:56 -0600 Subject: [PATCH] Check type of toke
はじめに こんにちは。流通事業部、新卒2年目の@mejilebenです。ガチアサリ難しすぎる。。。 ※本記事はLIFULL Advent Calendar 2017 20日目の記事です。 背景 JWT（JSON Web Token）という技術があるのですが、この技術を使うとCSRF脆弱性の対策にもなるということを知って、いったいどういう理屈なのか調べてみました。 色々な意味でツッコミどころ満載の記事になっていますが、お手柔らかにコメントいただけるとうれしいです。 この記事で言いたいこと JWTは改ざんを検知できる等の便利な仕様であることから、Webアプリケーションにおいて認証や認可の用途で使われている CSRFは悪意のある第三者による偽造されたリクエストも本物とみなして処理をしてしまう脆弱性 ユーザーからのリクエスト時はJWTをAuthorizationヘッダに載せることで、CSRF脆弱性
URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる（ITmedia News） - Yahoo!ニュース
URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる 12月11日13時14分配信 ITmedia News 12月10日にPC版がスタートしたサイバーエージェントのミニブログサービス「Amebaなう」で、あるURLをクリックすると、「こんにちは こんにちは!!」というフレーズとクリックしたURL文字列が自動で投稿され、「はまちや2」さんのアカウントを自動でフォローしてしまうという現象が広がった。 URLをクリックしたユーザーが意図しない機能を実行させられるWebアプリの脆弱性の一種・クロスサイトリクエストフォージェリ（CSRF）を突いたもの。同社は10日夜、URLをクリックしないようユーザーに告知。誤ってクリックした場合は投稿を削除し、はまちや2さんのフォローを外すよう呼び掛けた。11日朝までに脆弱性も修正したという。 mixiでも20
2005-04-20 mixiにCSRF脆弱性「ぼくはまちちゃん！」トラップ mixi 昨日書いた「まちちゃん！」トラップがバージョンアップ（ver 3.0）したもよお。以前のは日記を書き込むためのCGIへの引数付きのリンクがそのまま貼ってあったんだけど、今回はサイトを経由させるようになってて手が凝っているもよお。mixiの対策としてはリ… 2005-04-20 え？「はまち」ちゃんなの？ mixi はまちちゃん関連で思ったこと - おれはおまえのパパじゃない“I am MACHI-CHANG”なのかと思ってたっす。あと「【日刊】mixiニュース」というコミュニティで“「ぼくはまちちゃん」ウイルス”というタイトルのトピックが立ってて、それはまあまだいいんだけど、… 2005-04-20 はまちちゃん関連 mixi 恐がりさん経由でやじうまWatchからたくさん人がくるよう怖いようとか震えて
はてなブックマークの CSRF 脆弱性とその対策への流れ http://hxxk.jp/2006/01/31/0031 前の記事 : はてなのプロフィール画像によって表示は遅くなるのかという検証と、プロフィール画像を非表示にするいくつかの方法 次の記事 : フォーカスした際に、フォームの内容をクリアするやり方 記事データ 投稿者 望月真琴 投稿日時 2006-01-31T00:31+09:00 タグ CSRF はてな はてなブックマーク セキュリティ 脆弱性 概要 はてなブックマークに CSRF 脆弱性が存在し、実際にそこを突かれた攻撃がなされた件と、 web システム側による対応を待つだけで良いのかという件について。 リプライ リプライはまだありません。 はてなブックマークの CSRF 脆弱性 ( 対策済 ) はてなブックマーク日記 - お気に入りに追加ボタンのCSRF脆弱性修正について
前回に引き続き、はじめてのPHPプログラミング 基本編5.3対応のゆるいところ第三段は、本書に紹介されているミニミニブログにクロスサイト・リクエストフォージェリ(CSRF)脆弱性があるというものだ。 このミニミニブログは、BASIC認証を利用していて、twitterやwassrなどのように一行コメントが書き込めるというものだ。BASIC認証、投稿機能があればCSRF脆弱性の対策が必要だが、本書にはCSRFに対する解説は特にないので、調べるまでもなくCSRF脆弱性があるのだろうと思っていた。 しかし、人様の書籍に確認もしないで脆弱性指摘をするのも失礼なので、以下のように簡単な検証コードを書いて試してみた。 <html><body> <form action="http://localhost/hajimete_php5/miniblog/index.php" method="post"> <
GmailのCSRF脆弱性修正 - デベロッパもユーザもCSRFに対して認識を | エンタープライズ | マイコミジャーナル
Netcraftは9月30日(米国時間)、GoogleがGmailに存在していたクロスサイトリクエスト偽装(CSRF: Cross-site Request Forgery)に関する脆弱性問題を修正したことを発表した。これまでのGmailにはログインした状態のユーザに対して、メールフィルタを追加してメールを特定のアカウントへ転送することが可能な脆弱性があるとされていた。 今回修正されたCSRFだが、特別な脆弱性ではなくWebアプリケーションに存在する脆弱性として以前から存在する代表的なもののひとつ。特に最近Webアプリケーションを攻撃する場合によく使われる方法となっている。Webアプリケーションの普及にともない、CSRFを使った問題が今後ますます増えると思われる。 Gmailは代表的なWebアプリケーションだ。今回GMailにおいてCSRFの修正が実施されたことは啓蒙の点でも注目に値する。
概要 CookieにSameSite属性を付与することで、CSRF脆弱性1に対していくらかの防御ができる。 SameSite属性はStrict,Lax,Noneの3つの値を取り、設定値により効果の範囲は異なる Strictを設定することで、CSRFを防げる。ただし、Webサイトの使いやすさが損なわれる場合がある Laxを設定することで、POSTメソッドのリクエストのみを受け付ける処理でCSRFを防げる None は従来通りの動作であり、外部サイトからCookieを送信する Webサイトのセキュリティ要件により、設定すべき値が異なる SameSite属性は主要なブラウザすべてで対応されている SameSite属性の付与がCSRF脆弱性への防御とならないケース Windows 10 RS3（2017 Fall Creators Update）未満のIE 11など、SameSite属性をサポート
こんにちはっ 自分の書いたイラストを投稿するサイト、pixivでこんな事件があったみたいです！ 「ヘタクソ」pixivに意図せず中傷コメント CSRF脆弱性を悪用 http://www.itmedia.co.jp/news/articles/1002/15/news086.html CSRFは不正アクセスとはまた違うと素人の僕は思うんですけど、 まぁその話は法律とかに詳しい人にしてもらうとして、 なにはともあれ、中傷はいけませんよね。 pixivはこの件があってから、 脆弱性につながる情報には緊急問合せフォームを設けたりと、 セキュリティ対策に気合いが入ってきたみたいです！ よっしゃ！ というわけで、せっかくなので僕も協力しました！！ ※今は全部修正されてます！ 【XSS】(→最悪アカウントのっとられちゃったりするやつだよ！) 1.イラストのタイトル部分(img要素のalt属性) 2.pi
昨日書いた「まちちゃん！」トラップがバージョンアップ（ver 3.0）したもよお。以前のは日記を書き込むためのCGIへの引数付きのリンクがそのまま貼ってあったんだけど、今回はサイトを経由させるようになってて手が凝っているもよお。mixiの対策としてはリファラとかチェックするのかなあ。詳細は以下など参照。 http://d.hatena.ne.jp/kowagari/20050419/1113897459 http://d.hatena.ne.jp/mixi_love/20050419/p1 なお“CSRF”というのはキーワードによると（つかこのキーワードも全部引用だけど） "Cross-Site Request Forgeries" の略で、要するに「編集」「削除」などのコマンドを実行するような URL を踏ませる攻撃です。 さて、以下が問題の日記。 http://mixi.jp/view
doorkeepr gem に CSRF 脆弱性があり、いつの間にか修正されてました。 version 1.4.1 および 2.0 で修正されています。 詳細は Pull Request に書いてあるとおりなのですが、 phillbaker commented 8 days ago Since the Doorkeeper controllers inherit from Doorkeeper::Application (which inherits directly from ActionController::Base) and not ApplicationController, they never call protect_from_forgery, which means that non-GET methods don’t validate CSRF tokens. Thus
クリックだけで勝手に書き込み…「CSRF脆弱性」とは？ : サイバー護身術 : セキュリティー : ネット＆デジタル : YOMIURI ONLINE（読売新聞）
一連のPC遠隔操作事件では、「CSRF脆弱(ぜいじゃく)性」が使われていた。CSRF脆弱性とは、クリックしただけで他のサイトの書き込みが行われる問題点のことで、防止するのが難しい。 遠隔操作ウイルス事件の犯行声明全文が公開 遠隔操作ウイルスなどを使ってなりすまし、大阪、三重、横浜などで犯行予告の書き込みを行った事件で、犯人のものと思われる犯行声明メールが公開された。先週の記事「犯行予告事件、身元隠す『Tor（トーア）』の悪用と犯人像」で取り上げた落合洋司弁護士のもとに届いた犯行声明メールを、落合弁護士がブログで公開したものだ（遠隔操作事件・真犯人と称する者からのメール全文）。 この犯行声明メールや、今まで起きた事件の経緯を見ると、犯人は二つの手口を使っている。一つは先々週の記事「遠隔操作ウイルスはオリジナル？ 作者は腕の立つ人物か」で紹介したように、トロイの木馬だ。トロイの木馬とは、相
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
URL踏むと「こんにちは こんにちは!!」 AmebaなうのCSRF脆弱性で“意図しない投稿”広がる
teratailに投稿されたメールフォームにCSRF脆弱性が残存した理由 | 徳丸浩の日記
書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記
CSRF脆弱性対策 - monjudoh’s diary
トロイは「1から開発」、明大生事件はCSRF脆弱性突く――なりすまし事件“犯行声明”全文公開
「ヘタクソ」pixivに意図せず中傷コメント CSRF脆弱性を悪用
おさかなラボ - [速報]TwitterにCSRF脆弱性あり
はてな各サービスの CSRF 脆弱性対策について - はてなダイアリー日記
CSRF脆弱性のあるフォーラムに犯罪予告を書き込んだとして人が逮捕される
Twitter Login にも CSRF 脆弱性ができやすい罠が!? - OAuth.jp
JWT（JSON Web Token）でCSRF脆弱性を回避できるワケを調べてみた話 - Qiita
in between days - mixiにCSRF脆弱性「ぼくはまちちゃん！」トラップ
hxxk.jp - はてなブックマークの CSRF 脆弱性とその対策への流れ
ミニミニブログにCSRF脆弱性 - ockeghem's blog
SameSite属性の付与によるCSRF脆弱性対策 - Qiita
ブラザーの複合機「PRIVIO MFC-J960DWN」にCSRF脆弱性、回避ツールの入手にはウェブフォームからの連絡が必要
kinugawamasato0 blog | pixivのXSS/CSRF脆弱性を報告したよ
mixiにCSRF脆弱性「ぼくはまちちゃん！」トラップ - in between days
doorkeepr gem の CSRF 脆弱性が修正されてた - Qiita
up23672.js モリタポのCSRF脆弱性を使ったポイント送信
TDU学生、WordPress用プラグインWP Sticky SocialにおけるCSRF脆弱性発見 | ScanNetSecurity
