超絶技巧CSRF / Shibuya.XSS techtalk #7CSRF, HTML Form Protocol Attack, Cross-protocol scripting attackについて
初歩からわかるWordPressのnonceでAjaxをセキュアに実装する方法 | ゆっくりと…
*2: 管理画面のページを含みます *3: ログインユーザーと非ログインユーザーを両立させるには、キャッシュ・プラグインの使い方に注意しなければならないでしょう *4: CSRF 攻撃だけでログインユーザーの秘密情報が漏洩することはありませんが、他の脆弱性との複合を考えれば、使用すべきかと思います *5: 公開ページであっても、ログインユーザー専用の情報を表示する場合には *4 と同様、使用すべきかと思います。 Ajax には Ajax の セキュリティ上の注意すべき事項 が多数あります。特に XSS 脆弱性 があると秘密情報が漏洩し、せっかくの CSRF 対策が台無しになる可能性もあります。使われる文脈と目的に合わせ、抜け目なく実装しましょう 😛 。 nonceを組み合わせたAjaxの実装方法 やっと本題です 😉 。ここからは myajax プラグインの実装を想定し、5つのステップと
WordPress での CSRF 対策
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日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：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
Cookie Forcing protection made easy
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
「CSRF」と「Session Fixation」の諸問題について
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 セッション追跡と認証の実装手段 • セッ
Why is it common to put CSRF prevention tokens in cookies?
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - justinas/nosurf: CSRF protection middleware for Go.
Cross-Site Request Forgeries, by Chris Shiflett
Node.js Connect CSRF bypass abusing methodOverride middleware
Facebook Quietly Rolls Out Pay-Later Option For New Gamers
Rethinking Cookies: originOnly
CSRF Prevention in Java - WhiteHat Security
https://blog.whitehatsec.com/tag/session-token/
Interactive Reading Community (Ver.6)