とっても簡単なCSRF対策 - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。 CSRFおよびその対策の仕組みに関してはこちら↓ これで完璧！今さら振り返る CSRF 対策と同一オリジンポリシーの基礎 - Qiita この記事は，PHPにおけるワンタイムトークンを用いた実装例を示すものです。執筆日が少々古いものになるのでご了承ください。 コメント欄の議論に関するまとめ 以下，XSS脆弱性が存在しない前提．この脆弱性があるとあらゆるCSRF対策がほとんど意味をなさなくなるので，まずここから潰しておくこと． セッション固定攻撃に対する対策 ログイン後にsession_regenerate_idを必ず実行する． ログアウト後にsession_destroyを必ず実行する． CSRF攻撃に対する対策 セッションIDを抜か
Symfony2を使った、AJAX通信時のCSRFトークン検証 - Qiita
Symfony2を使って、AJAX通信のクライアント側とサーバ側を構築する際に、CSRF(クロスサイトリクエストフォージェリ)を防ぐためのトークンをやりとりする方法。 まずは、クライアント側画面を出力するコントローラでは、csrf_providerをつかって、トークンを生成 <?php class DefaultController extends Controller { public function clientAction(Request $request) { $token = $this->get('form.csrf_provider')->generateCsrfToken('csrf_token'); return $this->render('HogeFugaBundle:Default:client.html.twig', array( 'csrf_token' =>
teratailに投稿されたメールフォームにCSRF脆弱性が残存した理由 | 徳丸浩の日記
teratailに以下のような投稿がありました。 PHPでメールフォームを作成したので、脆弱性がないかアドバイスいただけないでしょうか。 エンジニアでもなければ、PHPもろくに書けない雑魚ですが、「php メールフォーム 作り方」でググって表示されるサイトを見ると、「んんんんん？？？」と思うところがあります。 これらを参考にしたり、コピペする方は、記述されているコードの良し悪しは判断できないかと思います。 そのような方々が参考にできるメールフォームを作りたいという思いで、調べて作りました。 周りに書いたコードを確認してもらえる人もいないので、皆様からのアドバイスがほしいです((_ _ (´ω｀ )ﾍﾟｺ 【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうかより引用 どれどれ…と確認すると、トークンのチェックが入っているにも関わらずクロスサイト・リクエストフォージ
Cross-Site Request Forgery is dead!
Scott Helme Security researcher, entrepreneur and international speaker who specialises in web technologies. More posts by Scott Helme. After toiling with Cross-Site Request Forgery on the web for, well forever really, we finally have a proper solution. No technical burden on the site owner, no difficult implementation, it's trivially simple to deploy, it's Same-Site Cookies. As old as the Web its
CSRFトークン インタビューズ - Qiita
VAddyとCSRFトークン VAddyは脆弱性診断を実行する際に、CSRFトークンを最新のものに更新しながら動作します。そのため「どのパラメータがCSRFトークンか？」を判断するロジックが存在しています。最近あるフレームワーク（後述）について「CSRFトークンを正しく認識できない」というバグを修正したのですが、良い機会なのでメジャーなフレームワークやCMSを中心にCSRFトークンの実装をざっと追ってみました。一覧にしても面白くないので、仮想インタビュー形式にまとめてあります。GitHub上で軽く追ったものが多いので、最新のバージョンでなかったり、解釈が間違っている箇所があるかもしれません。 それでは、どうぞ。 Ruby on Rails 金床(以下、金)「こんにちは。ようこそ。」 RoR「こんにちは」 金「相変わらずシェア高いようですね。」 RoR「はい、おかげさまで。この間はルマン24
crossdomain.xmlの脆弱性の話が人気だけど、簡単に解説するよ！:しっぽのブログ
ついったー足あと帳 このサイトを一昨日とかに見てびっくりした人も多いと思うんだけどcrossdomain.xmlの設定をあやふやにしておくと、ユーザーのセキュリティもあやふやになっちゃうんで、そこはWebサービスとしてはまずいよね？っていう話が話題。 Twitter の crossdomain.xml 問題について。 - てっく煮ブログ crossdomain.xml と CSRF 脆弱性について - 川o・-・）＜2nd life だけども、てっく煮の中の人が言うように このような「取得」のゆるさが理由で、Twitter API を活用したサービスを作る人が多発して、それがまた Twitter の人気を押し上げたのは事実。 という具合に、Webサービスのcrossdomain.xmlを全部厳しく（もしくはそもそも置かない）すればそれでいいかっていうと、それだとユーザーの自発的なサービスを
crossdomain.xml と CSRF 脆弱性について - 2nd life (移転しました)
crossdomain.xml を安易に設置すると CSRF 脆弱性を引き起こす可能性があります。というのも、ここ数が月、それなりの数の crossdomain.xml による CSRF 脆弱性を発見し(現在、それらのサイトでは対策がなされています)、まだまだ Web プログラマに脆弱性を引き起こす可能性がある、という考え方が浸透してないんじゃないか、と思ったので。 先月、Life is beautiful: ウェブサービスAPIにおける『成りすまし問題』に関する一考察にも crossdomain.xml について書かれてたのですが、その後もいくつかのサービスで crossdomain.xml を許可ドメインすべてにしているサービスがあったので、注意喚起としてエントリーに書き起こします。 自分も一年半ぐらい前は、crossdomain.xml を許可ドメインすべて ('*') にして設置し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
generateCsrfToken · Issue #9300 · symfony/symfony
Generate new CSRF token without reloading the entire form
超絶技巧CSRF / Shibuya.XSS techtalk #7