この記事は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を通じてこの脆弱性を報告しました。この記事では、当該脆弱性の概要と発見の経緯などについて報告します。 概要 脆弱性発見の経緯 影響を受けるアプリケーション 影響 対策

サマリ この記事の想定読者は、企業等の脆弱性ハンドリング担当者です。脆弱性情報にしばしば出てくるCWE-20の読み解き方を説明します。 CWEとは CWEはCommon Weakness Enumerationの略で、日本語では「共通脆弱性タイプ一覧」と訳されています。この訳からも分かるように、脆弱性をタイプ毎に分類しているものです。つまり、SQLインジェクション、XSS、バッファオーバーフロー等に、CWE-XXXという「分類番号」をふったものと考えるとわかりやすいでしょう。以下は、IPAが公表しているCWEの解説記事からの引用です。 1999年頃から米国政府の支援を受けた非営利団体のMITRE(*2)が中心となり仕様策定が行われ、2006年3月に最初の原案が公開されました。その後、40を超えるベンダーや研究機関が協力して仕様改善や内容拡充が行われ、2008年9月9日にCWEバージョン1.

この記事は、先日の記事「問題：間違ったCSRF対策～初級編～」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 はじめに CSRF対策の不備として、ありがちなパターンは以下のとおりです。 トークンが予測可能（ユーザIDのハッシュ値をトークンとして用いている等） 他人のトークンが利用できてしまう（参考記事） トークンのチェック方法に不備がある。 問題のコードは、暗号論的に安全な乱数生成器（PHPのrandom_bytes関数）を用いてトークンを生成し、それをセッション変数に記憶しているので、上記1 と 2 は問題ないと考えられます。したがって、3 が該当しそうだと当たりをつけます。そのためには、攻撃者は以下のトークンチェック(chgmail.php内)を回避する必要がありま

この記事は、先日の記事「問題：CSRFの防止策に関するチートシートにツッコミを入れる」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 設問: チートシート旧版の翻訳であるJPCERT/CC訳（以下の引用部分）を元に以下の設問に答えよ。 引用（再掲） Cookie の二重送信 Cookie の二重送信は、Cookie およびリクエストパラメーターの双方でランダムな値を送信し、サーバー側で Cookie の値とリクエストの値が等しいかどうか検証する手法です。 ユーザーがサイトにログイン するとき、サイトは暗号強度の高い疑似ランダム値を生成し、その値を Cookie としてユーザーのマシンに、セッション ID とは別に送ります 。どんな形であれ、サイトはこの値を保存しておく必

この記事は、先日の記事「問題：間違ったCSRF対策～中級編～」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで（できれば自分で解答を考えて）からこの記事をお読みいただくとよいと思います。 それでは、解答を説明します。 はじめに 出題時のわざとらしさから、この問題のポイントはstrcmp関数の挙動にあると気づいた方が多いと思います。 if (empty($_SESSION['token']) || empty($_POST['token']) || strcmp($_POST['token'], $_SESSION['token'])) {  // ワンタイムトークン確認 die('正規の画面からご使用ください'); } そして、strcmpの引数はどちらもempty()によるチェックが入っています。また、$_SESSION['token'] は、状態遷移図（下図）により、NU

先日のブログ記事にて、Welcartのオブジェクトインジェクション脆弱性について説明しましたが、オブジェクトインジェクションという脆弱性自体の情報源があまりないので、入門記事を書こうと思い立ちました。 （2017/11/22追記） OWASP Top 10 2017に正式に公開され、そのA7に安全でないデシリアライゼーション (Insecure Deserialization) が入りました。これは、本稿で扱うオブジェクトインジェクションと同内容ですが、OWASPの表記にならい、タイトルを変更しました。 以下、「そんなプログラムあり得るか?」という現実性についてはあまり気にしないで、原理的にオブジェクトインジェクションがどのようなものかについて順を追って説明していきます。以下、PHP言語のケースを題材として具体例を提示しますが、概念自体は他の言語でも通用するものです。 シリアライズとオブジ

エグゼクティブサマリ 秀スクリプトという小さな言語処理系を開発した。秀スクリプトは、TypeScriptを大幅に縮小した文法を持ち、コンパイラによって秀丸マクロに変換され、秀丸上で実行される。秀スクリプトコンパイラは秀スクリプト自身により記述される。 秀スクリプトの主な特徴は下記のとおり。 TypeScriptに似た文法を持ち、コンパイラも秀スクリプトで記述されている 秀丸マクロを生成し、秀丸上で実行される TypeScript同様、変数に型がある 数値（整数）型と文字列型、これらの配列をサポート if、while、do … whileの制御構造 関数のサポート はじめに Windows上で使用するエディタとして長年秀丸を愛用しています。最近はVisual Studio Codeなども人気で、僕もインストールして使ってみたりはするのですが、長年手に馴染んだツールというのは、中々乗り換えが難

以前の記事CMS四天王のバリデーション状況を調査したところ意外な結果になったで報告したように、Joomla!はログイン名の制限が非常にゆるやかになっています。であれば、🍣とか、💩などを含むログイン名が登録できるのだろうかという疑問が生じました。 とはいえ、以前、Joomla!の「ゼロデイコード実行脆弱性」はPHPの既知の脆弱性が原因で報告したように、少なくともJoomla! 3.4.5までは、MySQLの設定上 UTF-8 の4バイト文字は登録できず、それ以降の文字が全て切り詰められるという問題がありました。 このため、「admin🍣」というログイン名を登録しようとすると、🍣の切り詰めが起こって、adminユーザを二重に登録できなるのではないでしょうか? 試してみる Joomla! 3.4.8の環境を用意して管理者ユーザーを「admin」としておきます。下記のように、default

PHPの挙動を調べていると、マニュアルにも、ChangeLogにも載っていない変更にしばしば遭遇します。たとえば、PCRE系関数（preg_xxxx）の正規表現指定（第1引数）において、過去のPHPではNULLバイトを許容していましたが、最近のPHPでは、正規表現中のNULLバイトをエラーにしています。この変更は、マニュアルには載っておらず、ChangeLogには記載されているもののNULLバイトとは書いていないので、ちょっと気がつきにくいですね。 Fixed bug #55856 (preg_replace should fail on trailing garbage) このような場合、ソースコードの該当箇所を調べるか、適当にあたりをつけたバージョンのPHPをビルドして試すなどの手法がとられているかと思いますが、@hnwさんが phpall　を発表されたことで、この種の調査が一挙に楽に

今年の2月末に、Ruby on Railsに潜在的なリモートスクリプトインジェクションの脆弱性CVE-2016-2098が報告されています。攻撃コード(PoC)も公開されていますが、現実の攻撃が行われているという発表はないようです。この脆弱性の内容と対策について報告いたします。 背景 Hello Worldのような以下のシンプルなアプリケーション（コントローラ）を考えます。 class HelloController < ApplicationController def index render 'hello/hello' end end これに対するテンプレート hello/hello.html.erb は以下だとします。 <div>Hello world</div> ご覧のように、上記テンプレートを指定した場合、Hello worldが表示されます。 次に、以下のテンプレート hel

脆弱性診断をやっていると、たまにtype=hiddenのinput要素にXSSがあるけど、現実的な攻撃には至らないものにぶちあたることがあります。サンプルコードを以下に示します。 <body> 入力確認をお願いします。 <?php echo htmlspecialchars($_GET['t']); ?><br> <form action='submit.php'> <input type='hidden' name='t' value='<?php echo htmlspecialchars($_GET['t']); ?>'> <input type='submit'> </body> 正常系の呼び出しは下記のようになります。 http://example/hidden-xss.php?t=yamada HTMLソースは下記の通りです。 <body> 入力確認をお願いします。 yamad