2023年4月においてクリックジャッキング未対策のサイトはどの条件で被害を受けるか
サマリ CookieやlocalStorage等でセッション管理しているウェブサイトがクリックジャッキング対策していない場合、どの条件で被害を受けるかを説明する。SameSite属性のないCookieでセッション管理しているウェブサイトは、主要ブラウザのデフォルト設定ではクリックジャッキングの影響を受けない。一方、loaclStorageにトークン類を格納するウェブサイトでは、Google Chrome等のブラウザでクリックジャッキングの影響がある。また、ブラウザの設定を変更した場合の影響についても説明する。 クリックジャッキングとは クリックジャッキングとは、一言で説明すると「ウェブサイト利用者に意図しないクリック（タップ）をさせる」攻撃です。ウェブサイト上で意図しないクリックを勝手にさせられると、重大な結果になる場合があります。例えば、このURLを閲覧すると、以下のようにTwitter
Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621の概要と発見の経緯
この記事はRuby Advent Calendar 2022の第20日の記事です。前日の記事は@ydahさんによる「RuboCopのバージョンを最新に保つ技術」でした。 2022年11月22日に、Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621が発表がされました。 CVE-2021-33621: HTTP response splitting in CGI RubyのCGIライブラリにHTTPレスポンス分割脆弱性があり、秘密情報が漏洩する - HackerOne CGI::Cookieクラスにおけるセキュリティ上好ましくない仕様および実装 - HackerOne 私はHackerOneを通じてこの脆弱性を報告しました。この記事では、当該脆弱性の概要と発見の経緯などについて報告します。 概要 脆弱性発見の経緯 影響を受けるアプリケーション 影響 対策
DNSリバインディング(DNS Rebinding)対策総まとめ
サマリ DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。 DNSリバインディング（DNS Rebinding）とは DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチ
とある通販サイトに学ぶ自動ログイン機能のバッドプラクティス
サマリとある通販サイトにて「 メールアドレス・パスワードを保存する」機能がありますが、サイトにクロスサイトスクリプティング(XSS)脆弱性がサイトにあると生のパスワードが漏洩する実装となっています。本稿では、この実装方式を紹介し、なぜ駄目なのか、どうすべきなのかを紹介します。 記事の最後にはセミナーのお知らせを掲載しています。 はじめに家人がテレビを見ていて欲しい商品があるというので、あまり気は進まなかったのですが、その商品を検索で探して購入することにしました。「気が進まない」というのは、利用実績のないサイトはセキュリティが不安だからという理由ですが、この不安は的中してしまいました。 最初の「えっ?」はパスワード登録のところでして、パスワードを再入力する箇所で「確認のためもう一度、コピーせず直接入力してください」とあるのですよ。私は乱数で長く複雑なパスワードを入力しかけていたのですが、コピ
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にて実装されていましたが、細かい挙動の差異で既存サイトに不具合が
PHPにはエスケープ関数が何種類もあるけど、できればエスケープしない方法が良い理由
このエントリは、PHP Advent Calendar 2021 の20日目のエントリです。19日目は @takoba さんによる PHPプロジェクトのComposerパッケージをRenovateで定期アップデートする でした。 SQLインジェクションやクロスサイトスクリプティング(XSS)の対策を行う際には「エスケープ処理」をしましょうと言われますが、その割にPHP以外の言語ではあまりエスケープ処理の関数が用意されていなかったりします。それに比べてPHPはエスケープ処理の関数が非常に豊富です。これだけ見ても、PHPはなんてセキュアなんだ! と早とちりする人がいるかもしれませんが、しかし、他言語でエスケープ処理関数があまりないのはちゃんと理由があると思うのです。 本稿では、PHPのエスケープ処理用の関数を紹介しながら、その利用目的と、その関数を使わないで済ませる方法を説明します。 SQL用
PHPの脆弱性CVE-2018-17082はApacheの脆弱性CVE-2015-3183を修正したら発現するようになったというお話
最近自宅引きこもりで時間ができたので、YouTube動画を投稿するようになりました。みんな見てねー。 徳丸浩のウェブセキュリティ講座 そんなことで、次の動画は、お気に入りのPHPの脆弱性 CVE-2018-17082 を取り上げようと思ったんですよ。表向きXSSで出ているけど、金床さんのツッコミにもあるように、実はHTTP Request Smuggling(HRS)だというやつです。でね、下準備であらためて調べていると、なんかよく分からない挙動がワラワラと出てくる。なんじゃ、こりゃ。CVE-2018-17082 全然分からない。僕は気分で CVE-2018-17082 を扱っている… で、雑に整理すると、以下のような感じなんです。 古い環境だとCVE-2018-17082は発現しない（2015年以前） 少し古い環境だとCVE-2018-17082は発現する 新しい環境だとCVE-2018
SSRF対策としてAmazonから発表されたIMDSv2の効果と限界
サマリ Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。 SSRFとは SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。 最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得する
シェルを経由しないOSコマンド呼び出しがPHP7.4で実装された
この記事はPHP Advent Calendar 2019の5日目の記事です。 はじめに 私は6年前に、PHP Advent Calendar 2013として「PHPだってシェル経由でないコマンド呼び出し機能が欲しい」という記事を書きました。その中で、OSコマンドインジェクション対策の根本的かつ安全な対策は「シェルを経由しないコマンド呼び出し」であることを指摘した上で、末尾に以下のように書きました。 PHPコミッタのみなさま、PHP5.6の新機能として、シェルを経由しないコマンド呼び出しの機能を追加できませんか? 現実には当時からPCNTL関数にてシェルを経由しないコマンド呼び出しはできたのですが、当関数の使用が難しいことと、CLI版あるいはCGI版（FastCGIは可）のPHPでないとサポートされていないなどの制限があり、popenやproc_openなど使いやすいコマンド呼び出し関数に
PHPサーバーサイドプログラミングパーフェクトマスターのCSRF対策に脆弱性
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 ＄token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
鈴木常彦先生の「共用レンタルサーバにおけるメールの窃盗」の話を聴講した
4月23日（火）に開催された 「#ssmjp 2019/04 ～DNSの話を聞く会～」に「Outputなら任せてください枠」で参加しましたので、講演内容からとくにやばい(?)内容と思われる@tss_ontap（鈴木常彦=浸透言うな先生）の「黒塗りの DNS (萎縮編)」から、「共用レンタルサーバにおけるメールの窃盗」について紹介します。スライドは公開されています。 サマリ レンタルサーバーからメールを送信する場合、悪意の第三者に、特定のドメインに対するメールを横取りされるリスクがある 攻撃手法 攻撃者は、レンタルサーバーを契約（お試しなどでも可能）して、攻撃対象のドメイン名（ここではchukyo-u.ac.jp…中京大学のドメイン名を用いる）を登録する その際に、当該ドメイン名の権利を有している必要はない（権利があれば正当にメールを受信できるので攻撃の必要がない） これだけ なぜメールが横
EC2上でDNS RebindingによるSSRF攻撃可能性を検証した
AWS EC2環境でのDNS Rebindingについて検証したので紹介します。 まずは、「前回までのおさらい」です。先日以下の記事でSSRF攻撃およびSSRF脆弱性について紹介しました。 SSRF(Server Side Request Forgery)徹底入門 この記事の中で、以下のように紹介しました。 ホスト名からIPアドレスを求める際にも以下の問題が発生します。 DNSサーバーが複数のIPアドレスを返す場合の処理の漏れ IPアドレスの表記の多様性（参考記事） IPアドレスチェックとHTTPリクエストのタイミングの差を悪用した攻撃（TOCTOU脆弱性） リクエスト先のWebサーバーが、攻撃対象サーバーにリダイレクトする 上記のTOCTOU(Time of check to time of use)問題は、DNSの名前解決の文脈ではDNS Rebindingとも呼ばれます。 DNS R
bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点
宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数（ソルトやストレッチングも用いる）であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです（この制限はDoS脆弱性回避が
徳丸浩の日記: SSRF(Server Side Request Forgery)徹底入門
SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート（岩間編） この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー（192.168.0.5）はファイアウォールで隔離されているため外部から直接
WordPressのプラグインWP GDPR Complianceの脆弱性CVE-2018-19207について分析した
11月中旬から、レンタルサーバー事業者等から、WordPressのプラグインWP GDPR Complianceの脆弱性について注意喚起が目立つようになりました。 WordPressのプラグイン「AMP for WP」「WP GDPR Compliance」における緊急性の高い脆弱性についての注意喚起 【注意喚起】WordPressのプラグイン『WP GDPR Compliance』の1.4.2までのバージョンに脆弱性が発見されました。 【重要】WordPressのプラグイン「WP GDPR Compliance（1.4.2以前）」「AMP for WP（0.9.97.19以前）」における緊急性の高い脆弱性について 記事本文には以下のように書かれています。 本脆弱性の影響 WordPressにおいて、権限を持たないユーザーが脆弱性を利用してウェブサイト全体の設定を変更したり、第三者が管理者
解答：CSRFの防止策に関するチートシートにツッコミを入れる
この記事は、先日の記事「問題：CSRFの防止策に関するチートシートにツッコミを入れる」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 設問: チートシート旧版の翻訳であるJPCERT/CC訳（以下の引用部分）を元に以下の設問に答えよ。 引用（再掲） Cookie の二重送信 Cookie の二重送信は、Cookie およびリクエストパラメーターの双方でランダムな値を送信し、サーバー側で Cookie の値とリクエストの値が等しいかどうか検証する手法です。 ユーザーがサイトにログイン するとき、サイトは暗号強度の高い疑似ランダム値を生成し、その値を Cookie としてユーザーのマシンに、セッション ID とは別に送ります 。どんな形であれ、サイトはこの値を保存しておく必
徳丸浩の日記: 問題：CSRFの防止策に関するチートシートにツッコミを入れる
この記事は「問題：間違ったCSRF対策～中級編～」の続編です。当初上級編を意図しておりましたが、後述する事情により、級の指定は外しました。 はじめに 問題は、OWASPから出ているCross-Site Request Forgery (CSRF) Prevention Cheat Sheet（JPCERT/CCによる邦訳「クロスサイトリクエストフォージェリ (CSRF) の防止策に関するチートシート」）にツッコミを入れてもらおうというものです。具体的には、このチートシート（カンニングペーパーの意）のDouble Submit Cookie（Cookie の二重送信）の箇所です。以下、JPCERT/CC訳で該当箇所を引用します。 Cookie の二重送信 Cookie の二重送信は、Cookie およびリクエストパラメーターの双方でランダムな値を送信し、サーバー側で Cookie の値とリク
徳丸浩の日記: 解答：間違ったCSRF対策～中級編～
この記事は、先日の記事「問題：間違ったCSRF対策～中級編～」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 はじめに 出題時のわざとらしさから、この問題のポイントはstrcmp関数の挙動にあると気づいた方が多いと思います。 if (empty($_SESSION['token']) || empty($_POST['token']) || strcmp($_POST['token'], $_SESSION['token'])) { // ワンタイムトークン確認 die('正規の画面からご使用ください'); } そして、strcmpの引数はどちらもempty()によるチェックが入っています。また、$_SESSION['token'] は、状態遷移図（下図）により、NU
徳丸浩の日記: 問題：間違ったCSRF対策～中級編～
この記事は「問題：間違ったCSRF対策～初級編～」の続編です。前回同様、この記事では問題のみを出し、想定解答は後日公開することにします。ネタバレとなるブックマークコメントやツイートなどは控えていただけると幸いです（「思いのほか簡単だった」など感想は可）。ブログ記事等に解説記事を書くことは歓迎いたします。 この問題が果たして「中級」なのかについては異論があると思います。きわめて易しいと思う人もいれば、きわめて難しいと思う人も多いと思います。中をとって中級としましたが、現実には難し目かと思います。 今回の問題は、前回（初級編）のトークンチェック部分（chgmail.php内）のみを変更したものです。まずは変更箇所を説明します。 前回のおさらい if ($_POST['token'] !== $_SESSION['token']) { // ワンタイムトークン確認 die('正規の画面からご使用
解答：間違ったCSRF対策～初級編～
この記事は、先日の記事「問題：間違ったCSRF対策～初級編～」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 はじめに CSRF対策の不備として、ありがちなパターンは以下のとおりです。 トークンが予測可能（ユーザIDのハッシュ値をトークンとして用いている等） 他人のトークンが利用できてしまう（参考記事） トークンのチェック方法に不備がある。 問題のコードは、暗号論的に安全な乱数生成器（PHPのrandom_bytes関数）を用いてトークンを生成し、それをセッション変数に記憶しているので、上記1 と 2 は問題ないと考えられます。したがって、3 が該当しそうだと当たりをつけます。そのためには、攻撃者は以下のトークンチェック(chgmail.php内)を回避する必要がありま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
