独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使
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
Spring Boot + Spring Security使用時のCSRFとSessionTimeoutの問題 - grep Tips *
はじめに Spring Boot + Spring Security使用時のSessionTimeout対応の最後に、「CSRF対策が有効の場合、POST時にSessionTimeoutしているとHTTP Status：403 Forbiddenが発生してしまう問題がある。」と記載した。 今回はこの問題の対応方法を記載し、Spring SecurityのJavaConfigの完成形を作る。 CSRF対策のせいでHTTP Status：403 Forbiddenが起こる原因 まずこの問題が起こる原因は、CSRF対策の仕組みが、リクエストパラメータで送られるCSRF TokenとSessionに保存されたCSRF Tokenを比較するというロジックであり、Sessionに依存しているから。 SessionがTimeoutによって消滅しているときにCSRF Tokenをリクエストパラメータで送っ
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
とっても簡単なCSRF対策 - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。 CSRFおよびその対策の仕組みに関してはこちら↓ これで完璧！今さら振り返る CSRF 対策と同一オリジンポリシーの基礎 - Qiita この記事は，PHPにおけるワンタイムトークンを用いた実装例を示すものです。執筆日が少々古いものになるのでご了承ください。 コメント欄の議論に関するまとめ 以下，XSS脆弱性が存在しない前提．この脆弱性があるとあらゆるCSRF対策がほとんど意味をなさなくなるので，まずここから潰しておくこと． セッション固定攻撃に対する対策 ログイン後にsession_regenerate_idを必ず実行する． ログアウト後にsession_destroyを必ず実行する． CSRF攻撃に対する対策 セッションIDを抜か
技術/Security/CSRF対策参考メモ - Glamenv-Septzen.net
id: 1050 所有者: msakamoto-sf 作成日: 2012-01-08 20:08:56 カテゴリ: セキュリティ [ Prev ] [ Next ] [ 技術 ] 今更ながらCSRFやCSSXSS関連の参考リンクをメモ。 開発者のための正しいCSRF対策 http://www.jumperz.net/texts/csrf.htm 高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか？ http://takagi-hiromitsu.jp/diary/20060409.html おさかなラボ - [CSRF]高木氏のエントリへの返答 http://kaede.to/~canada/doc/csrf-response-to-mr-takagi CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった
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
java - Custom login form. Configure Spring security to get a JSON response - Stack Overflow
I have a simple application which is splitted into 2 parts : A backend which exposes REST services with Spring-boot / Spring-security A frontend which contains only static files. The requests are received by a nginx server which listens on port 80. If the request URL begins with /api/, the request is redirected to the backend. Else, the request is handled by nginx which serves the static files. I
JavaScript: Fetch API で CSRF 対策のトークンを送信する
前回の記事の jQuery のコードを Fetch API に置き換えた。Fetch API は Firefox 39、Chrome 42 で有効になる。セッション Cookie を送信するために credentials: ‘same-origin’ を指定する。 <?php session_start(); if (!isset($_SESSION['token'])) { $_SESSION['token'] = htmlspecialchars(generateCSRFToken(), ENT_QUOTES, 'UTF-8'); } function generateCSRFToken() { return base64url_encode(openssl_random_pseudo_bytes(48)); } function base64url_encode($data) { r
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ページを開く
Can i disable CSRF check for some controllers? · Issue #179 · spring-projects/spring-boot
Spring Security Reference
CSRF Token lifecycle after Logout
https://github.com/terasolunaorg/guideline/blob/master/source/Security/CSRF.rst
Make server validation using redux-form and Fetch API