令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
PHPサーバーサイドプログラミングパーフェクトマスターのCSRF対策に脆弱性
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 ＄token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
第3回 Webセキュリティのおさらい その3 CSRF・オープンリダイレクト・クリックジャッキング | gihyo.jp
前回は、Webアプリケーションにおける受動的攻撃の代表例の1つであるXSSについて、原理や対策を振り返りました。今回は、同じく受動的攻撃の代表例であるCSRF、オープンリダイレクト、クリックジャッキングについて掘り下げて解説していきます。 CSRF（クロスサイトリクエストフォージェリ） CSRFはどのように引き起こされるのか CSRFとは、たとえば掲示板の書き込みや設定情報の変更などの機能に対して、攻撃者のサイト上に設置されたフォームなどから強制的にリクエストを発行することで、ユーザーの意図していない操作と同様の結果をもたらす攻撃手法です。Webアプリケーションに永続的な副作用がある機能が攻撃の対象となります。 たとえば、http://example.jp/上に設置された掲示板で以下のようなHTMLがあったとします。 <form method="POST" action="/board">
クロスサイトリクエストフォージェリ(CSRF)とその対策
本資料は、web アプリケーションにおける脆弱性のひとつ、CSRF (クロスサイトリクエ ストフォージェリ) の仕組みとその対策に関する説明資料です。 また、CSRF 対策のためのライブラリのいくつかについて、その概要と適用例も紹介しています。 Webアプリケーションを作成する開発者の方々が、CSRF 脆弱性に対する理解を深め、よりセキュアなWebアプリケーションの開発の一助となれば幸いです。 自習用の資料や勉強会での資料としてご活用ください。 - 改訂版+1: 図版や誤記の修正 (2015年10月20日) ※ コメントくださった皆様ありがとうございます! - 改訂版: JPCERT/CC Web サイトにて公開 (2015年10月6日) - 初版: OSC2015Hokkaido 講演資料 (2015年6月13日) Read less
WebAPIのステートレスなCSRF対策 - あめだま
Jerseyのバージョン1.9.1で追加されたCSRFをステートレスに防ぐフィルタが興味深かったので、そのメモです。 CSRF対策の手法 通常、CSRF攻撃を防ぐにはトークンを使う方法があります。サーバがクライアントにトークンを発行して、クライアントは発行されたトークンをクエリパラメータなどの形でリクエストに付与します。サーバはトークンが付与されていないリクエストを実行しません。攻撃者は発行されたトークンを知らないため、リクエストを実行できないという寸法です。 CSRF対策とステート ただし、この方法ではトークンの取得〜リクエストの発行にステートができるため、WebAPIがステートフルになってしまうという問題があります。RESTベースのWebAPIはやはりステートレスに作りたいところです。 そこで、JerseyのCSRF対策フィルタはステートレスになるよう作られています。 JerseyのC
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection
超絶技巧CSRF / Shibuya.XSS techtalk #7