令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか
サマリ2020年2月にGoogle ChromeはCookieのデフォルトの挙動をsamesite=laxに変更しましたが、2022年1月11日にFirefoxも同様の仕様が導入されました。この変更はブラウザ側でCSRF脆弱性を緩和するためのもので、特定の条件下では、ウェブサイト側でCSRF対策をしていなくてもCSRF攻撃を受けなくなります。この記事では、デフォルトsamesite=laxについての基礎的な説明に加え、最近のブラウザの挙動の違いについて説明します。 （2022年1月29日追記） 本日確認したところ、Firefoxにおけるデフォルトsamesite=laxはキャンセルされ、従来の挙動に戻ったようです（Firefox 96.0.3にて確認）。デフォルトsamesite=lax自体は先行してGoogle Chromeにて実装されていましたが、細かい挙動の差異で既存サイトに不具合が
CORSの仕様はなぜ複雑なのか
Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別
Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた - Qiita
Chrome 79以下や他ブラウザのデフォルト値。 Chrome 80からこの値を設定する場合、Secure属性も必須となる。 Aサイトに対し、Bサイトからどのようなリクエストがあっても、発行したサイトでCookieヘッダーに含める (Cookieを使用する) 図にすると以下のようになります。 Strict 外部サイトからのアクセスではCookieを送らない。 Lax 外部サイトからのアクセスはGETリクエストのときだけCookieを送る。 None 従来通りの動き。 【追記】なおChrome 80以降でSecure属性を付けずSameSite=Noneを指定した場合、set-cookie自体が無効になります。 セキュリティ上の効果 CSRF対策になります。 CSRF (クロスサイト・リクエスト・フォージェリ) とは、 WEBサイトがユーザー本人の意図した動作であることを検証していないため
次世代Webカンファレンス 2019 振り返り
nwc.md 次世代Webカンファレンス 2019 振り返り この文章に関しても所属組織とは関係のない個人の見解です 所感など 本当に全く打ち合わせをしていないので、話題が分散しがちだったかもしれない。 せっかくの所属組織とは無関係のレギュレーションなので、具体名を上げてガンガン治安の悪いことを言うつもりだったのだけど、直前に「具体的な企業名は避けましょう」と言われて若干遠慮した。 マズいことをガンガンしゃべる覚悟で来たので、防刃ベストを着ているが、特に出番は無かった。トイレにも行った。 本当は話す予定だったトピックについて、いくつかは、別途private gistに書く。 話した話題の参考情報 CDN設定の話、request collapsing という名前の機能 https://tech.mercari.com/entry/2017/06/22/204500 http://www.it
CVE-2016-7401 CSRF protection bypass on a site with Google Analytics の解説
gistfile1.md CVE-2016-7401 https://www.djangoproject.com/weblog/2016/sep/26/security-releases/ https://hackerone.com/reports/26647 pythonのcookie parserが ; 以外もpairsの区切り文字として解釈するので、google analyticsのreferrer経由でsetされるcookieを使ってCSRF tokenを上書き可能だったという問題。 django側でcookie parser自前で実装、python本体は直ってないようだ https://github.com/django/django/commit/d1bc980db1c0fffd6d60677e62f70beadb9fe64a 多くのcookie parserは、pairsの区
SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ
はじめに 以前のエントリでSSLに対する新しい攻撃手法「BEAST」を紹介しましたが、今回はBEASTをさらに発展させた「CRIME」という攻撃について簡単に紹介したいと思います。一次情報源としてこちらのスライド（英語）が閲覧できますので、時間がある方はぜひ目を通してみてください。 CRIMEの意味 CRIMEは "Compression Ratio Info-Leak Made Easy" あるいは "Compression Ratio Info-Leak Mass Exploitation" の頭文字で、SSLやSPDY（あるいはHTTPボディ部のgzip圧縮）で使われる圧縮アルゴリズムに注目した攻撃手法です。あまり知られていませんがSSLには圧縮機能が存在しており、サーバ側・クライアント側双方が圧縮機能をONにしている場合に、データが圧縮されます。 BEASTとの関係 CRIMEはB
GitHub、プロジェクトページの全ドメインを「github.io」に移行
GitHub、プロジェクトページの全ドメインを「github.io」に移行：セキュリティ強化を目的に 米GitHubは4月5日、GitHubでホスティングされているデベロッパのプロジェクトページを全て、新しい専用ドメインの「github.io」に移行させると発表した。 米GitHubは4月5日、GitHubでホスティングされているデベロッパのプロジェクトページを全て、新しい専用ドメインの「github.io」に移行させると発表した。github.comを標的としたクロスドメイン攻撃を仕掛けられたり、フィッシング詐欺にgithub.comのドメインが悪用されるのを防ぐ狙いだと説明している。 対象となるのは「ユーザー名.github.com」のようなgithubのサブドメインを使ったプロジェクトページで、今後は全トラフィックが「ユーザー名.github.io」のドメインにリダイレクトされる。ユ
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
クッキーモンスターバグがあると、IPアドレス偽装防止のCSRF対策が回避される
日経Linux 2013年1月号に「“誤認逮捕”を防ぐWebセキュリティ強化術」を書き、それが今週4回連載で、ITproに転載されました。この中で、クロスサイトリクエストフォージェリ(CSRF)対策について説明しましたが、クッキーモンスターバグ(Cookie Monster Bug)がある場合に対策が回避されることに気がつきました。 それでは、どのような対策が望ましいかを考えてみると、中々難しい問題です。以下、その内容について検討します。 解決すべき課題の整理 記事の趣旨は、昨年無実の市民のパソコンからCSRFによる犯行予告が横浜市のサイトに書き込まれたことを受けて、サイト側でCSRF対策をして、なりすまし書き込みができないようにしようというものです。なりすましの犯行予告には、CSRFのほか、マルウェアを用いる方法、CSRF以外のWebサイトへの攻撃手法もあるので、CSRF対策だけで十分と
mixi足あと廃止に寄せて - 最速転職研究会 | コメント mixiって今ほとんどがモバイルでアクセスされてたはずだけど、スマホ以外のガラケーでもこの問題が起きるの？
mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後) アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。 過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。 http://internet.kil
第3回 JSONPでのクロスドメインアクセス | gihyo.jp
JSONPの動作原理 前回はAjaxに存在するセキュリティモデルであるSame-Originポリシーを紹介し、そのSame-Originポリシーを迂回する方法とセキュリティについて見てきました。また、回避する方法の1つめとしてリバースProxyを用いた方法を紹介しました。リバースProxyを用いた方法ではセキュリティ的な問題点もありましたが、そもそもProxyサーバを用意しなければならないため、この方法は手軽に使うことはできませんでした。 そこで考え出されたのがJSONP（JavaScript Object Notation with Padding）という方法です。 それではまず簡単にJSONPについて説明します。 Ajaxで使われるXMLHttpRequestオブジェクトには前回説明したとおりSame-Originポリシーがありクロスドメインアクセスはできません。一方、SCRIPTタグ
CSRF と Cookie 漏洩は関係ない | 水無月ばけらのえび日記
そしてcookieを奪うのがどれほど簡単かというのは、CSRFの事例が後をたたないことからも伺い知ることができる。 うーむ、CSRFの理解って結構浸透してきたと思っていたのですが、そうでもないようで……。 CSRF は Cookie を奪取してセッションハイジャックするような攻撃ではなく、攻撃者は Cookie の値を知る必要がありません。また、CSRF 攻撃によって攻撃者が Cookie を奪取することもできません。もちろん、別途 XSS があったりすれば Cookie を奪取できる余地がありますが、それは XSS による漏洩ということになるでしょう。 それから、User-Agent の一致チェックは対策としては不十分です。というのも、CSRF では原理上 User-Agent が一致するに決まっていますし、Cookie 奪取を想定するなら、攻撃者が User-Agent を一致させるこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
