CSRF, HTML Form Protocol Attack, Cross-protocol scripting attackについて
先日、Rails で開発しているときに意図しない InvalidAuthenticityToken エラーが発生して、すごくハマってしまいました。そのときに Rails のCSRF対策の仕組みについて調べてみましたので、ブログに残しておきます。 Rails のCSRF対策 Rails が生成した ApplicationController には以下の記述があります。 class ApplicationController < ActionController::Base # Prevent CSRF attacks by raising an exception. # For APIs, you may want to use :null_session instead. protect_from_forgery with: :exception end protect_from_forg
*2: 管理画面のページを含みます *3: ログインユーザーと非ログインユーザーを両立させるには、キャッシュ・プラグインの使い方に注意しなければならないでしょう *4: CSRF 攻撃だけでログインユーザーの秘密情報が漏洩することはありませんが、他の脆弱性との複合を考えれば、使用すべきかと思います *5: 公開ページであっても、ログインユーザー専用の情報を表示する場合には *4 と同様、使用すべきかと思います。 Ajax には Ajax の セキュリティ上の注意すべき事項 が多数あります。特に XSS 脆弱性 があると秘密情報が漏洩し、せっかくの CSRF 対策が台無しになる可能性もあります。使われる文脈と目的に合わせ、抜け目なく実装しましょう 😛 。 nonceを組み合わせたAjaxの実装方法 やっと本題です 😉 。ここからは myajax プラグインの実装を想定し、5つのステップと
nonce ってナンスか? 春だというのに寒いですねぇw それはさておき、みなさんは nonce という言葉を聞いたことがあるでしょうか? 日本ではあまり馴染みがないように思いますが、コンピュータ (というか暗号) の世界では一度だけ使われる使い捨てのユニークな数 (英語版 Wikipedia の説明) のことを言います。 WordPress には CSRF 対策として nonce という機能が実装されています。 wp_create_nonce で nonce を生成し、wp_verify_nonce でこれを検証することができます。 リンク先の Codex にも例がありますが、wp_create_nonce で生成した nonce を HTML のフォームに埋め込み、サーバーで受けたその値を wp_verify_nonce で検証する、というような使い方ができます。 ただし、注意点が一つ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
合わせて読んでください:Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
I wrote a post about CSRF tool and readers noticed an intentional mistake in it — storing a token in a plain cookie can be exploited with cookie forcing (like cookie tossing we saw on github, but works everywhere). TL;DR With MITM attackers can replace or expire any cookie (write-only) Actually I don't think it's mistake in CSRF protection design, I still think problem is about horrible cookies de
1 「CSRF」と「Session Fixation」 の諸問題について 独立行政法人産業技術総合研究所 情報セキュリティ研究センター 高木 浩光 http://staff.aist.go.jp/takagi.hiromitsu/ 情報処理推進機構 ウェブアプリケーション 開発者向けセキュリティ実装講座 2006年2月28日, 4月4日 後日配布資料 2 目次 • 前提知識の確認 – Webアプリにおけるセッション追跡と認証の実装手段 – セッションハイジャック攻撃の原理と脅威 • CSRF (Cross-Site Request Forgeries) 別名: Session Riding – 歴史的経緯、原因、脅威、技術的対策、適法な存在推定手段 • Session Fixation – 歴史的経緯、原因、脅威、技術的対策、適法な存在推定手段 3 セッション追跡と認証の実装手段 • セッ
I'm trying to understand the whole issue with CSRF and appropriate ways to prevent it. (Resources I've read, understand, and agree with: OWASP CSRF Prevention Cheat Sheet, Questions about CSRF) As I understand it, the vulnerability around CSRF is introduced by the assumption that (from the webserver's point of view) a valid session cookie in an incoming HTTP request reflects the wishes of an authe
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image t
Introduction Index Alphabetical Index ASVS Index MASVS Index Proactive Controls Index Top 10 Cheatsheets Cross-Site Request Forgery Prevention Cheat Sheet¶ Introduction¶ A Cross-Site Request Forgery (CSRF) attack occurs when a malicious web site, email, blog, instant message, or program tricks an authenticated user's web browser into performing an unwanted action on a trusted site. If a target use
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
はじめに 広く報道されているように(参考記事)、CSRFによるウソの殺人予告によって、無実の大学生が逮捕される事件が発生してしまいました。 筆者は2006年に「開発者のための正しいCSRF対策」という記事をインターネット上で公開し、またメーリングリスト上での議論などでCSRF脆弱性への対策について啓蒙してきたつもりですが、実際にはインターネット上の多くのウェブアプリケーションは未だCSRF対策がなされておらず、今回問題が起こった横浜市のホームページも氷山の一角に過ぎないだろうと考えています。 CSRF対策がなかなか広まらなかった理由のひとつは、大きな、あるいは目立った被害がこれまであまり見られなかった事かと思います。mixiでのはまちちゃんによる「こんにちはこんにちは」事件などもありましたが、あくまでいたずらレベルに過ぎず、小規模なウェブサイトにおいてそれほど積極的に対策しようという雰囲気
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く