徳丸浩の日記

ISO-2022-JP自動判定を用いたHTMLコンテキスト破壊によるXSS

2025-01-06T12:57:00.001+09:00

サマリ

ISO-2022-JPエンコーディングの誤判定を悪用したXSSの技法としてEncoding Differentials: Why Charset Matters | SonarのTechnique 2を紹介する。これは、HTMLの属性を囲むダブルクォート等をISO-2022-JPの2バイト文字と誤認させることによって引用符の効果を無効化させることによるXSSである。本稿で紹介する攻撃は、従来からのセキュリティベストプラクティスである「文字エンコーディングの明示」に従っていれば影響を受けることはない。
ここで紹介する攻撃は、はせがわようすけ氏のブログ記事ISO-2022-JPによるXSSの話 - 葉っぱ日記で紹介されている「2. 属性値やテキストノードのエスケープのバイパス」と同じ原理であり、本記事の方が条件が複雑であるが、エスケープ対象の文字に関する制約は緩やかである。

はじめに

昨年末のブログ投稿「ISO-2022-JPの自動判定によるクロスサイト・スクリプティング(XSS)」で、ISO-2022-JPの悪用により、バックスラッシュを円記号に誤認させることにより、バックスラッシュによるエスケープを無効化するXSSについて紹介しました。この攻撃は昨年（2024年）7月にSonarSourceブログで投稿された方法のTechnique 1に該当しますが、本稿では同じ記事から「Technique 2 HTMLコンテキストの破壊」を紹介したいと思います。
ISO-2022-JP文字エンコーディングそのものや、その自動判定については説明を繰り返さないため、前回のブログ記事を参照ください。

ダブルクォートを無効化できればXSS攻撃が可能になる

安全なウェブサイトの作り方や私の本では、クロスサイト・スクリプティング脆弱性の必須対策として、「属性値は」ダブルクォートで囲むように要求しています。

HTMLタグを出力する場合は、その属性値を必ず「"」（ダブルクォート）で括るようにします。そして、「"」で括られた属性値に含まれる「"」を、HTMLエンティティ「"」にエスケープします。
安全なウェブサイトの作り方 - 1.5 クロスサイト・スクリプティングより引用

具体例で見てみましょう。Webアプリケーションにおいて以下のようなinput要素を生成しているとします。

<input name=mail value=外部の値>

外部の値はHTMLエスケープを行って表示されているとします。エケスープされている場合でも、外部の値として以下を指定することでXSS攻撃ができます。

1 onmouseover=alert(1)

生成されるinput要素は以下となります。

<input name=mail value=1 onmouseover=alert(1)>

外部からの入力はすべてvalue属性になるはずが、空白により属性値が終わってしまい、新たなonmouseover属性（イベント）ができてしまいます。この攻撃は、属性値をダブルクォート等で囲むことで防ぐことができます。

過去の攻撃手法: Shift_JISの先行バイトによるXSS

過去に有効だった文字コードXSSとして、Shift_JISの先行バイトによりダブルクォート等を無効化するテクニックが発見されています。はせがわようすけさんの記事を参照します。

第6回　先行バイトの埋め込み | gihyo.jp

詳しくは上記記事を読んでいただくとして、外部入力として0x82等のバイト値を入力することで、属性値を囲っているダブルクォート（0x22）と合わせて1文字と認識させようというテクニックです。これは過去にIEやFirefoxで成立していましたが、これらブラウザでもかなり前から対策されていて、現在この攻撃はできません。ブラウザ側の対策は、Shift_JISの2バイト目としてはダブルクォート（0x22）やシングルクォート（0x27）に該当するバイトは出現しえないため、\x82\x22等の並びはShift_JISとしては不正な文字であることを利用していると思います。

ISO-2022-JPの自動認識によりダブルクォート等を無効化する

これに対して、SonarSourceブログで紹介されたテクニックは、引用符の前にISO-2022-JPのエスケープシーケンスによりJIS X 0208の2バイト文字の開始を指定することにより、引用符を2バイト文字と認識させる方法です。当該記事では、マークダウンをHTMLに変換するプログラムにより、img要素を生成するシナリオを用いて説明しています。
マークダウンでのimg要素の一般的な記法は以下の通りです。

![ALT文字列](https://example.jp/a.png)

これに対して、下記のHTMLが生成されます。

<img src="https://example.jp/a.png" alt="ALT文字列"/>

SonarSourceブログでは、以下のように2つの画像とその間の文字列の構成を利用しています。

![AAA](BBB) CCC ![DDD](EEE)

これは以下のように変換されます。

<img src="BBB" alt="AAA"/> CCC <img src="EEE" alt="DDD"/>

攻撃は、まずAAAの箇所に ESC$@（ESCは0x1b）を指定します。これはISO-2022-JPにおいて、日本語（JIS X 0208）の開始を意味します。すると、AAA直後の「"」以降が2バイト文字と解釈されます（下図）。

このままだと攻撃はできないので、CCCの位置にESC(Bを指定します。これはASCIIの開始を意味するため、これ以降がASCIIとして解釈されます（下図）。

上記の赤い網掛けの箇所に注目ください。alt=を閉じるダブルクォートが文字化けしたため、<img src=までが属性値として扱われ、EEEの部分は属性値からはみ出しています。ここに攻撃文字列を指定できます。なので、EEEの箇所に onerror=alert(1) を指定することでXSS攻撃ができます。

検証用PHPスクリプト

ここで、検証用のPHPスクリプトを用意しました。これは画像のみを解釈できるマークダウンパーサーです。正規表現で![xxx](yyy)を探索してimg要素に変換するだけの単純なものです。元のテキストは全てHTMLエスケープされるので、簡単にはXSSはできないはずです。

<body>
<?php
  $md = $_GET['md'];
  $html = preg_replace('/!\[(.*?)\]\((.*?)\)/', 
      '<img src="\2" alt="\1">',
      htmlspecialchars($md));
  echo $html;
?></body>

このスクリプトに以下のクエリ文字列を指定してみましょう。

md=![%1b$@](BBB)%1b(B![DDD](+onerror=alert(1))

攻撃は失敗します。生成されたHTMLソースを見てみましょう。

alert(1" となっています。これは、![]()に対して、alert(1)の右括弧が反応してしまったものです。これを避ける方法はあるでしょうか。
一つの方法はalert(1)の代わりにaler`1` を指定するものです。これはタグ付きテンプレートと呼ばれるものです。詳しくはMDNの解説を参照ください。
これにより攻撃が成功します。onerror=alert`1`の前後に空白を挟んでいます。

md=![%1b$@](BBB)%1b(B![DDD](+onerror=alert`1`+)
  ↓
<img src="BBB" alt="⊂<img src=" onerror=alert`1` " alt="DDD">

ところで、Qiitaを含む一般的なマークダウンパーサーでは、括弧の対応をきちんとチェックしてくれるようです。なので、先のPHPスクリプトを括弧の対応を見るように変更してみました。PHPのPCRE拡張正規表現を使っています。

  $html = preg_replace('/!\[(.*?)\]\((((?>[^()]+)|\((?2)\))*)\)/',
      '<img src="\2" alt="\1" />',
      htmlspecialchars($md));

これだと、onerror=alert(1) も期待通り攻撃が成功します!

対策

ISO-2022-JPの自動判定によるXSSの対策は以下の通りです。

ウェブコンテンツの文字エンコーディングを適切に行う

これは従来からのセキュリティベストプラクティスであり、元々セキュアなアプリケーションが、この攻撃により突然危険になるわけではありません。

まとめ

HTMLの属性を囲むダブルクォート等をISO-2022-JPの2バイト文字と誤認させることによって、引用符の効果を無効化させることによるXSSについて説明しました。この攻撃が成立するために必要な条件は複雑で、かなりわざとらしいCTFのような状況でしか再現しなさそうではありますが、それはともかくとして、ウェブコンテンツの文字エンコーディングを適切に設定することをお勧めします。

ISO-2022-JPの自動判定によるクロスサイト・スクリプティング(XSS)

2024-12-31T16:57:00.005+09:00

サマリ

ISO-2022-JPという文字エンコーディングの自動判定を悪用したクロスサイト・スクリプティング(XSS)攻撃について説明する。これは、文字エンコーディングを適切に指定していないウェブコンテンツに対して、文字エンコーディングをISO-2022-JPと誤認させることでバックスラッシュが円記号と解釈されることによりエスケープ処理を回避する攻撃である。本稿で紹介する攻撃は、従来からのセキュリティベストプラクティスである「文字エンコーディングの明示」に従っていれば影響を受けることはない。

はじめに

クロスサイト・スクリプティング対策として、記号文字のエスケープ処理に加えて、コンテンツの文字エンコーディングをレスポンスヘッダやmetaタグで明示しましょうと言われてきました（参照）。その背景として、UTF-7という文字エンコーディングを悪用したXSSの存在がありました。この攻撃については以下の記事を参照ください。

はせがわようすけさんの記事にもあるように、UTF-7によるXSSは、UTF-7に特徴的な文字列を注入することで、ブラウザに文字エンコーディングをUTF-7と誤認させることによるものです。
しかし、上記で「ありました」と表現している理由は、この問題がInternet Explorer(IE)限定の問題であること、IEでもかなり前に対策が進められて、現実的な攻撃は困難になっていたことによります。このため、徳丸本初版（2011年3月）でもUTF-7によるXSSは取り上げていません。
そのため、以下の記事に見られるように、「もうウェブコンテンツに文字エンコーディングが明示されていなくても脆弱性として指摘しなくてもよいのでは?」という意見も見られます。

令和になった今、Content-TypeヘッダのCharset付与によるクロスサイトスクリプティングについて考えてみる - 僕と技術とセキュリティ

ところが、今年（2024年）の7月に、SonarSourceのブログに以下の記事が投稿され、早々にCTFの作問等に応用されました。

Encoding Differentials: Why Charset Matters | Sonar

この記事ではISO-2022-JP文字エンコーディングの文字列を注入することにより、ブラウザにコンテンツの文字エンコーディングをISO-2022-JPと誤認させるテクニックです。すなわち、「文字エンコーディングを誤認させる」という点で、この記事の手法はUTF-7によるXSSの後継と考えられます。以下、上記ブログ記事のTechnique 1のパターンについて説明します。

ISO-2022-JP とはなにか

まずは、ISO-2022-JPについて説明しましょう。徳丸本2版から、ISO-2022-JPの説明を引用します。

ISO-2022-JPは7ビットの文字エンコーディングで、エスケープシーケンスという符号により文字集合（US-ASCIIとJIS X 0208）を切り替える方式です。「JISコード」と呼ばれる場合もあります。図6-15にエスケープシーケンスの例として、ISO-2022-JP符号化された「ABCと漢字!」という文字列を図示します。

　同図で、「ESC $ B」がJIS X 0208の始まり、「ESC ( B」がUS-ASCIIの始まりを示します。ISO-2022-JPは状態の切り替えを伴うため、コンピュータ上の内部処理や検索用のデータとしては適していません。歴史的な理由から、主に電子メールの伝送に用いられてきました。
　なお、「インターネットでは半角片仮名を使うな」という主張を目にする場合がありますが、これはISO-2022-JPが半角片仮名（JIS X 0201の片仮名）をサポートしないことに由来しています。
体系的に学ぶ安全なWebアプリケーションの作り方第2版 P535より引用

上記には言及されていませんが、ISO-2022-JPは、US-ASCIIとJIS X 0208以外も扱えるようになっていまして、主なものとしては以下があります。表はとほほの文字コード入門から引用しました。

記号表記	16進表記	意味
ESC ( B	1B 28 42	ASCII。
ESC ( J	1B 28 4A	JIS X 0201(旧称 JIS C 6220)-1976 ラテン文字集合
ESC $ @	1B 24 40	JIS X 0208(旧称 JIS C 6226)-1978(通称：旧JIS)
ESC $ B	1B 24 42	JIS X 0208-1983(通称：新JIS) または JIS X 0208-1990

下の2種類はJIS X 0208の旧規格と新規格なので中身は少し違うもののセキュリティ上の違いはありませんが、問題はJIS X 0201です。これは8ビットの1バイトでASCIIと半角カナを使えるようにした文字集合です。以下、英語版のWikipediaより引用です。

https://en.wikipedia.org/wiki/JIS_X_0201 より引用

この赤枠で囲った箇所がASCIIとは異なっていて、\（バックスラッシュ）の代わりに¥（円記号）、~（チルダ）の代わりに ‾ （オーバーライン）が割り当てられています。ISO-2022-JPでは、片仮名の部分は割り当てられておらず、ローマ字と記号の部分（0x00～0x7F）のみが使えます。ISO-2022-JPで半角片仮名が使えないのは、この制約によるものです。

ISO-2022-JPでは、エスケープシーケンス ESC $ J によりJIS X 0201に切り替えができますが、使えるのはローマ字部分のみで、ASCIIとの違いは\ → ¥、~ → ‾ のみなので実用上はわざわざ用意する意味がないように思える一方、これがセキュリティ上問題になります。

ISO-2022-JPによるXSSの基本的な考え方

我々に馴染み深いShift_JIS等ですと、表示上は ¥ となっていても、ブログラミング等ではバックスラッシュとして扱われますが、JIS X 0201の ¥ はあくまで円記号でありバックスラッシュではありません。このため、JavaScript等でエスケープ処理のために使ったバックスラッシュが円記号に化けてしまうと、「エスケープ処理が無効になってしまう」というセキュリティ上の問題になってしまいます。

たとえば、PHP等でJavaScriptを以下のように動的生成する箇所があったとします。

const v = "ここを動的生成する";

動的生成の箇所に "; alert(1)// を入力するXSSを防ごうとすると、以下のようにエスケープ処理するはずです。

const v = "\"; alert(1)//";

ところが、\が¥に化けると以下のようになり、XSS攻撃ができてしまいます。

const v = "¥"; alert(1)//";

日本のプログラマだと¥がバックスラッシュに見えてしまう方が多いと思いますが、上記はバックスラッシュではない円記号です。なので、文字列リテラルは “¥” だけとなり、後続の ; alert(1)//が文字列リテラルからはみ出し、実行されてしまいます（//以下はJavaScriptのコメントとなり無視されます。JavaScriptは行末のセミコロンは省略可能です）。

文字エンコーディングの自動判定

そうは言っても、文字エンコーディングがISO-2022-JPと認識されていなければ問題はありません。具体的には、レスポンスヘッダやmeta要素でcharsetが明示されている場合は、ISO-2022-JPと誤認されることはありません。問題は、適切な文字エンコーディング指定がない場合です。具体的には、以下のケースです。

文字エンコーディング指定がない
文字エンコーディング指定はあるが間違っている（charset=EUC_JP等）

これらのケースでは、ブラウザはテキストの中身から文字エンコーディングを「推測」します。このため、ISO-2022-JPに特徴的なエスケープシーケンスがある場合、ISO-2022-JPのコンテンツと「誤認」する場合があります。これを以下のスクリプトにより試してみましょう（実験する場合は日本語のコメントは削除してください）。

<?php
  header('Content-Type: text/html; charset=EUC_JP');  // 正しくはEUC-JP
?><body>
<?php echo htmlspecialchars($_GET['p']); ?>
<script>
  document.write("\\".codePointAt(0).toString(16)) // \のコードポイントを取得する
</script>
</body>

このスクリプトを p=%1b(J というクエリ文字列を指定して実行すると a5 と表示されます。バックスラッシュのコードポイントはU+005C、円記号のそれはU+00A5ですから、ESC ( J の指定によりJIS X 0201と解釈され、バックスラッシュが円記号に化けていることが分かります。

XSSを試す

ISO-2022-JPによるXSSの肝は、バックスラッシュが円記号に誤認されるところですから、バックスラッシュによりエスケープ処理を行っているスクリプトが脆弱性の対象になります。その具体例として、以下のPHPスクリプトを用います。

<?php
  header('Content-Type: text/html; charset=EUC_JP');
  function escapeJS($str) {  // Escape function for JavaScript String
    $replacements = [
        '\\' => '\\\\',
        '"'  => '\\"',
        "'"  => "\\'",
        "\n" => '\\n',
        "\r" => '\\r',
        "\t" => '\\t',
        '<'  => '\\u003C',
        '>'  => '\\u003E'
    ];
    return strtr($str, $replacements);
  }
?><body>
<script>
  const v = "<?php echo escapeJS($_GET['p']); ?>"
  console.log(v)
</script>
</body>

このスクリプトは、クエリー文字列 p をJavaScriptの変数 v に代入していて、その際に関数escapeJSを呼んでJavaScript文字列リテラルのエスケープ処理を行っています。小なり・大なり記号のエスケープはJavaScriptの文法上は必要ありませんが、これがないと、</script><script>alert(1)</script> のような形で、いったんscriptタグを終端するという攻撃ができるための処理です。
これに対する攻撃文字列は以下の通りです。

p=%1b(J";alert(1)//

実行結果は以下となります。

この際に生成される該当箇所を示します。まずは16進数ダンプ。

赤枠で囲った部分が ESC (J であり、JIS X 0201への切り替えのエスケープシーケンスです。
その結果、当該箇所は以下のようにデコードされます。

const v = "¥";alert(1)//"

¥はバックスラッシュではない円記号なので、直後のダブルクォート「"」で文字列リテラルが閉じられ、後続のalertが実行されていることが分かります。

コンテンツにマルチバイト文字があればどうなるか?

この攻撃は、文字エンコーディングの自動判定の結果ISO-2022-JPと判定されることが条件なので、元々コンテンツにShift_JISやEUC-JP等の日本語があれば¹、ISO-2022-JPと本来の文字エンコーディングのどちらが「勝つ」かが問題になります。私の調べた範囲では、文字列を注入できる箇所（外部入力の表示など）の前にマルチバイトの文字があると、ISO-2022-JPとは判定されないようです。かと言ってUTF-8やShift_JIS、EUC-JP等と判定されるわけでもなく、windows-1252（ISO-8859-1に類似のMS独自文字エンコーディング）と判定されることが多いようです（下図）。

<head>
<title>日本語のタイトル</title>
</head>
<body>
ESC ( J 等としてもISO-2022-JPとは判定されない
</body>

一方、コンテンツが英字のみで構成されていると、ISO-2022-JPと判定させることは容易になります。
それでは、外部入力を注入できる箇所より「後に」マルチバイト文字列がある場合はどうでしょうか。下図のようなケースです。

<head>
<title>English Title</title>
</head>
<body>
<div>ここに外部入力を注入できる</div>
<div>日本語コンテンツ(Shift_JISあるいはEUC-JP)がある</div>
</body>

このようなケースでは、ISO-2022-JPの文字列を長くすることで、後ろにUTF-8等のマルチバイトの文字があっても、ISO-2022-JPと判定されることが分かりました。ただし、ブラウザにより挙動が異なります。まず、実験に用いたPHPスクリプトを以下に示します。

<?php
  function escapeJS($str) {  // Escape function for JavaScript String
    /* Same as before. Omitted. */
  }
?><body>
<?php
  echo htmlspecialchars($_GET['txt']);
?>
<script>
  const v = "<?php echo escapeJS($_GET['js']); ?>"
  console.log(v)
</script>
<!-- 雀の往来（EUC-JPコンテンツのための魔法の文字列） -->
<p>こんにちは こんにちは!!</p>
</body>

このスクリプトは2つのクエリ文字列txtとjsを取ります。txtは通常のテキスト（要素内容）としてHTMLエスケープして表示します。jsはJavaScriptエスケープしてJavaScriptの文字列リテラルとして埋め込まれます。txtの方は、元コンテンツの日本語が出現する前に置かれている必要があります。jsの方は場所はどこでも問題ありません。「雀の往来」はEUC-JP文字エンコーディングのコンテンツを文字化けしにくくする「魔法の文字列」です（参照）。「雀の往来」は実験には必要ありませんが、ノリで入れてみました。

Google Chrome

Google Chrome用の攻撃文字列は以下となります（バージョン131.0.6778.205で確認）。

http://example.jp/iso-xss-m.php?js=%1B(J";alert(1)//&txt=%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA

クエリー文字列 js は先のものと同じです。txtの方は、以下の文字列「誓A」を8個繰り返したものです。見やすくするために空白を挟んでいます。

ESC $@ @@ ESC (B A

jsの方（JavaScrpit文字列）で文字エンコーディングの誤認がさせられないか調べましたが、私が試した範囲ではできませんでした。なので、「文字エンコーディングの誤判定（txt）」と「XSS攻撃（js）」は別に指定する必要があるようです。

Firefox

Firefox用の攻撃文字列は以下です（バージョン133.03で確認）。

http://example.jp/iso-xss-m.php?js=%1B(J";alert(1)//&txt=%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA%1B$@@@%1B(BA

js側はGoogle Chromeと同じですが、txtの方は先の「誓A」を120個続けた形となっています。パーセントデコード後のバイト数は1080バイトなので、文字数制限をしているフィールドだと攻撃は難しいかもしれません。
Firefox特有の性質が2つ見つかりました。
まず、Firefoxは文字エンコーディングの自動判定する際に、コンテンツがある程度の長さがあると、レンダリングを2回行う場合があります。1回目は最初に判定した文字エンコーディングでレンダリングして、コンテンツ全体から判定した文字エンコーディングが1回目と異なる場合、もう一度レンダリングを用います。そうすると、先の「誓A」でいったんISO-2022-JPによりレンダリングした後、後続のEUC-JP等のデータも合わせて他のエンコーディング（典型的にはwindows-1252）でレンダリングし直します。これに合わせてJavaScriptも2回実行されます。
この場合、1回目のJavaScript実行の際に文字エンコーディングがISO-2022-JPと判定されているので、XSS攻撃は成功します。2回目は攻撃に失敗するのですが、1回成功すれば攻撃には十分です。
次に、Firefoxの場合だと、js側に「文字エンコーディング誤判定用の文字列」を入れても攻撃は成功します。なので、攻撃対象フィールドが1つしかない場合でも攻撃できる可能性があります。

Safari

Safari（macOS 15.2上のSafari 18.2）で確認したところでは、Safariは文字エンコーディングの自動判定の結果ISO-2022-JPを選択することはないようです。明示的にISO-2022-JPを指定することはできますが、本稿で説明するISO-2022-JPの自動判定による攻撃のパターンはできないようです。

影響を受けるアプリケーション

この攻撃の影響を受ける条件は下記の両方を満たす場合です。

文字エンコーディングを正しく指定していない
バックスラッシュによるエスケープ処理でXSS対策をしている

ただし、日本語のコンテンツだと通常title要素として日本語が記載されているわけで、その前に「外部から文字列を注入できる箇所がある」というのはレアケースかなと思います。しかし、多国語化対応されているサイトであれば、英語版のページを狙うことで攻撃成功の可能性は高まると思います。

対策

ISO-2022-JPの自動判定によるXSSの対策は以下の通りです。

ウェブコンテンツの文字エンコーディングを適切に行う

また、JavaScriptの動的生成は元々XSS対策が難しいので、HTML上のカスタムデータ属性に動的な値を設定して、その値をJavaScriptから読み込むという方法を推奨します。詳しくは拙著「体系的に学ぶ安全なWebアプリケーションの作り方第2版」を参照ください。

まとめ

ISO-2022-JPの自動判定によるXSSについて説明しました。ウェブコンテンツの文字エンコーディングの設定漏れは脆弱性と言えるのかという意見も見られるところでしたが、やはり文字エンコーディングは適切に設定しましょう。文字エンコーディングの指定は元々必要な処理なので、「既知の攻撃手法ができなくなったから、もう対応しなくてよい」というものではありません。

文字エンコーディングを指定しない場合、UTF-8は自動判定されないようなので、Shift_JISあるいはEUC-JPを使っている場合が問題になると思います。 ↩︎

「はじめて学ぶ最新サイバーセキュリティ講義」の監訳を担当しました

2024-04-01T17:18:00.002+09:00

日経BPから4月4日発売予定の『はじめて学ぶ最新サイバーセキュリティ講義　「都市伝説」と「誤解」を乗り越え、正しい知識と対策を身につける』の監訳を担当したので紹介させていただきます。

本書の原書は、ユージーン・H・スパフォード、レイ・メトカーフ、ジョサイヤ・ダイクストラの3名の共著として書かれた「Cybersecurity Myths and Misconceptions」で、米国Amazonのレビューでは4.6の高評価を得ています。また、「インターネットの父」ことヴィントン・サーフ氏が本書に前書きを寄せています（後述）。

はじめに

サイバーセキュリティは、その短い歴史にも関わらず、神話や都市伝説に満ちています。古典的なものとして、本書の冒頭では、「ウイルス対策企業が自社製品を売るためにマルウェアを作って拡散した」が紹介されています。

本書は、このようなセキュリティの都市伝説や神話をとりあげ、これらの「ウソを暴き」ながら、セキュリティの真髄を説明していくスタイルをとっています。

本書によると、「この本は、一般的な問題、人間の問題、文脈的な問題、データの問題という4つのパートに分かれ、175件以上の都市伝説、偏見、誤解を収めています。」とあります。175件! すごいですね。

割合とっつきやすい都市伝説から紹介しましょう。それは「パスワードはひんぱんに変更せよ」です。

かつて、セキュリティのベストプラクティスとして「パスワードを定期的に変更を強制する」がありましたが、さまざまな議論を経た後に、2017年6月アメリカ国立標準技術研究所（NIST）がNIST SP 800-63-3を発表し、その中でパスワードの定期的変更の強制を否定したことで、一応の「都市伝説の終結」をみました。

とはいえ、パスワードの定期的変更は永く信じられてきた「ベストプラクティス」なので、各種ガイドライン等には今でも残っていますし、セキュリティに携わるものでも、「パスワードは定期的に変更するべきもの」と思っている人は多いと思います。本書は、この種の神話や都市伝説を多数取り上げ、次々に否定していきます。

意外なところにも「神話」が

神話の中には、読者には意外なものも含まれます。たとえば、「ユーザーが最弱リンク」がそれです。

サイバースペースでは、サイバーセキュリティの最弱リンクはユーザーであるとの言説が不当に支持されていますが、それは誤りです。

意外に思いませんか? なぜこれが不当なのかはぜひ本書で確かめてください。ヒントとして、本書から下記を引用しておきます。

人々を力づけたいという思いやりにより、ユーザーは高いセキュリティ意識を持つパートナーになります。そのように意識を改めることで、強い信頼関係が生まれます。ミスを報告しやすくして、修正の手助けをする。それこそが、ユーザーを見下しミスを責めるよりもずっと望ましい態度と言えます。

もう一つは、「攻めるほうが守るよりも楽」です。よく攻撃側に比べて防御側は不利と言われます。本書でも、この節は以下の書き出しから始まっています。

サイバーセキュリティ分野の非常に多くの尊敬すべき人たちが口をそろえてこう言っていました。「攻撃側はたったひとつの突破口があればいいのに対して、防御側はあらゆる攻撃に備えなければならないため不利だ」と。アタックサーフェイス（攻撃対象領域）で考えれば、この主張は本当らしく聞こえます。たくさんのサーフェイスを防衛するとなると、リソースを薄く広く分散しなければなりません。攻撃側がサーフェイス点にリソースを集中し、攻撃方法もひとつに絞ってきたなら、たしかに相手が圧倒的に有利です。

ではあるのですが、現実の局面では、攻撃よりも守備がかんたんというケースもあることと、あまりに「防御側が不利」と強調することによるセキュリティ担当者へのメンタルへの影響に本書は言及しています。

徳丸は何をしたか

私は主に以下を担当しました。

訳語として日本のセキュリティ分野の一般的な用語を選択する
翻訳を読んで意味の通りにくいところの訳を手直しする
米国と日本で違いがある箇所（法律など）などに監訳注をつける

原書は、凝った文体や、反語のようなレトリック、古典や著名な映画を踏まえた表現、韻を踏んでいる箇所などがあり、「米国のインテリはこういう文体が好きなのかなぁ」と感慨に耽っておりましたが、できるだけ日本の読者に読みやすい訳を心がけました。

その一つとして、原書の見出しは「正しいこと、望ましいこと」と「神話、都市伝説、誤解」が特に区別なく並べられています。これだと読者は混乱すると思い、編集部と相談した結果、「神話、都市伝説、誤解」に相当する見出しにはメガホンのアイコンをつけました。下図に例を示します。

本書の対象読者

本書の対象読者は、エンジニアやセキュリティ担当者だけでなく、もっと広範囲にセキュリティに関係する人たちです。本書の出版元のページでは以下のように紹介されています。

本書は、開発者、デザイナー、アナリスト、意思決定を行う人、学生など、プロ、アマを問わずサイバーセキュリティに関係する人たちに向けて書かれています。加えて、サイバーセキュリティに関わっていない人にも役立ちます。テクノロジーに依存しているなら、サイバー防衛と無縁ではいられないからです。あなたもきっと含まれるはずです。

本書の読み方と得られるもの

本書は技術書ではなく、エッセイ集のような形ですので、一つ一つの節は割合読みやすいと思いますが、神話が175件も集めてあるだけあって500ページ以上の大部となっています。いきなり通読する必要もないため、読みたいところから拾い読みのような形でも良いと思います。とはいえ、本書を読み進めることにより、ハウツー本からは得られないセキュリティの本質的な思考方法が習得できます。

これに関しては、「インターネットの父」ことヴィントン・サーフ氏が本書に前書きを寄せていますが、その中に以下の一節があります。

なかでも強力な防衛ツールに「クリティカルシンキング（懐疑的思考）」があります。この本が伝えようとしているのは、サイバー空間でのリスクに対してもっと懐疑的になる方法です。たやすく身につくものではないので、多少の訓練は必要になるでしょう。悪者は我々の人間としての弱みにつけ込んできます。悲しいかな、困っている人を助けずにはいられない私たちの善意すら狙われます。そのため、そうした人間性やポジティブな社会感情を狙った詐欺は数知れません。この本は、そんな策略を見破る方法を教えてくれます。

本書でクリティカルシンキングを身につければ、詐欺行為のみならず、ネットのセキュリティ記事に右往左往することなく、どっしりと構えつつ、本当に必要な備えは何か、自分で考えられるようになるでしょう。

2023年4月においてクリックジャッキング未対策のサイトはどの条件で被害を受けるか

2023-04-03T10:52:00.000+09:00

サマリ

CookieやlocalStorage等でセッション管理しているウェブサイトがクリックジャッキング対策していない場合、どの条件で被害を受けるかを説明する。SameSite属性のないCookieでセッション管理しているウェブサイトは、主要ブラウザのデフォルト設定ではクリックジャッキングの影響を受けない。一方、loaclStorageにトークン類を格納するウェブサイトでは、Google Chrome等のブラウザでクリックジャッキングの影響がある。また、ブラウザの設定を変更した場合の影響についても説明する。

クリックジャッキングとは

クリックジャッキングとは、一言で説明すると「ウェブサイト利用者に意図しないクリック（タップ）をさせる」攻撃です。ウェブサイト上で意図しないクリックを勝手にさせられると、重大な結果になる場合があります。例えば、このURLを閲覧すると、以下のようにTwitterにて「犯行予告を投稿する」画面になり、「ツイートする」を押すと、押した人のアカウントで犯行予告をツイートする結果になります。Twitterのこの機能はウェブインテントと呼ばれます。

このような拙い「攻撃」だと、被害者は画面内容を見た結果ツイートボタンは押さないわけですが、これにiframeを用いた仕掛けを組み合わせて「知らない間にボタンを押させる攻撃」がクリックジャッキングです。具体的には、iframeを用いて、下図のようにボタンを押させるための罠と、Twitter等の掲示板の画面を重ねます。

この際、掲示板を手前に配置してCSS設定により透明にします。一方罠サイトは奥側に配置します。すると、見た目上は罠サイトだけが見えますが、ボタンをクリックすると手前側の掲示板のボタンを押したことになり、ログイン中の利用者のアカウントで意図しない投稿がされます。これがクリックジャッキングです。現実のTwitterはクリックジャッキング対策がされているので、この攻撃は成立しません。

この例では「意図しない投稿」でしたが、これ以外に、設定変更や退会など「クリックだけでできる操作」全てで影響がありえます。

クリックジャッキング対策には、以下のようなレスポンスヘッダを出力することで行われます。

Content-Security-Policy: frame-ancestors 'none';

上図はCSPを用いた対策ですが、伝統的なX-Frame-Optionsヘッダを用いた対策も有効です。

しかしながら、上記対策をしていない場合でも、モダンブラウザでは、iframe内のコンテンツからCookieおよびlocalStorageへのアクセスが制御されていて、クリックジャッキング攻撃ができないケースが多くなっています。
本稿では、モダンなブラウザの利用者がクリックジャッキング被害を受ける条件について説明します。

検証方法

今回は、クリックジャッキングの影響の有無を、iframe内のウェブページがCookieやlocalStorageの値を受け取れるかどうかで判断することにしました。もしもiframe内のページがCookieやlocalStorageにアクセスできない場合、ページはログイン状態にはならず、被害者のアカウントでの投稿や設定変更などはできないからです。
下図は検証環境の模式図です。サイトAがクリックジャッキング脆弱なサイト、サイトBは罠サイトです。

サイトAのログインを模して、CookieやlocalStorage、sessionStorageをセットします（図の左側）。この後サイトBに遷移しますが、サイトB内にiframeがあり、その中にサイトAのページがあります（図の右側）。このiframe内のサイトAのページでCookie、localStorage、sessionStorageの値を表示して、これらの値を受け取れているかを確認します。

CookieのSameSite属性は以下の3種類のものを用意しました。SameSite属性の意味についてはこちらの記事を参照ください。

SameSite属性なし
SameSite=None
SameSite=Lax

SameSite属性なしは伝統的なセッション管理を想定しています。SameSite=Laxの場合、iframe内のコンテンツにCookieは送信されないはずですが、比較のためテスト条件に加えました。

検証結果

検証結果を下表に示します。

結果の要約は下記の通りです。

SameSite属性のないCookieでセッション管理しているサイトは全てのブラウザにてクリックジャッキングの被害を受けない
localStorageでセッション管理しているサイトは、Google Chrome、Edge、Opera（デスクトップ、Android）のユーザが被害を受ける
Brave、Firefox、Safariの利用者はいずれのケースでもクリックジャッキングの被害を受けない

このように、ブラウザのセキュリティ機能の差により、クリックジャッキング被害の条件が変わっています。

各ブラウザのセキュリティ機能

次に、各ブラウザのセキュリティ機能がどのようにクリックジャッキングを防いでいるかを説明します。

Chromium系ブラウザの防御はデフォルトSameSite=Lax

CookieのSameSite属性にてLaxあるいはStrictを指定した場合、iframe内に置かれたページに対してはCookieは送信されません。これはすべてのブラウザに共通の仕様ですが、Chromium系のブラウザ（Google Chrome、Edge、Brave、Opera…）では、SameSite属性のないCookieはSameSite=Laxとして扱われます（参考）。
このため、SameSite=Noneを明示的に設定していないCookieは、iframe内のページには送信されないことになります。SameSite属性は、もともとはCSRF対策を意図した機能と思われますが、クリックジャッキング対策にも効果があります。
デフォルトSameSite=Laxの効果はCookieのみであるため、sessionStorageとlocalStorageには効果が及びません。

※注
SameSite属性のないCookieは、Cookieが生成されてから2分以内であれば、クロスサイトのPOSTリクエストに付与されます（参考）が、iframeの場合はこの2分間の猶予期間はなく、ただちにSameSite=Laxとして扱われます。

Firefoxは2022年1月11日にデフォルトSameSite=Laxを導入しましたが、非互換を理由に直後にキャンセルされました（参考）。現在でも、SameSiteのデフォルトは、SameSite=None相当です。
一方、Firefoxは2022年6月14日に包括的 Cookie 保護（Total Cookie Protection：TCP）と呼ばれる機能を投入しました。TCPはセキュリティ目的というよりはプライバシー保護を目的としたものですが、クリックジャッキング防御にも効果があります。

下図は包括的Cookie保護(TCP)のイメージ図です（引用元）。

従来は一つのCookieの入れ物（cookie jar）をすべてのサイトで共有していました（上図左）が、TCPが有効になるとサイト毎にcookie jarが独立するようになります（上図右）。これだけだと抽象的でわかりにくいので、サイトAがサイトB、サイトCのiframeにて表示されている様子を用いて説明します（下図）。

上図のように、サイトAのCookieは、単独で表示されている場合（左）、サイトBのiframe内で表示されている場合（中央）、サイトCのiframeで表示されている場合（右）で、それぞれ別の値となります。この機能はサードパーティCookieによるトラッキングを防ぐ目的で導入されたものですが、セッション管理のCookieもiframe内では分離・保護されるため、結果としてクリックジャッキングに対する防御として作用します。また、Cookieだけでなく、sessionStorageやlocalStorageもサイト毎に分離されます。

なお、実験による検証の結果、Braveブラウザにも包括的Cookie保護と同様の機能が実装されているようです（sessionStorageの挙動はFirefoxともSafariとも異なりますが、詳細は省略します）。BraveはChromiumベースのブラウザなので、デフォルトSameSite=Laxも実装されています。

Safariの防御機能はITP（Intelligent Tracking Prevention）

Safari（WebKit）にはITP（Intelligent Tracking Prevention）というトラッキング防止機能があります。これにより、結果としてクリックジャッキングも防御されています。
下図は、ITPによりiframe内のページのCookieがどうなるかを模式的に示しています。

サイトAでセットされたCookieは、サイトBにiframeで埋め込まれてもCookieは送信されず、またレスポンスのSet-Cookieも無視されます。すなわち、iframe内ではCookieの送信も受信もされないということになります。

一方、sessionStorageとlocalStorageについては、FirefoxのTCPのような挙動になります。すなわち、サイト毎に分離された形になります。この挙動はWebKitのドキュメントに記載されています。

Partitioned Third-Party Storage
Third-party LocalStorage and IndexedDB are partitioned per first-party website and also made ephemeral.
試訳: サードパーティのlocalStorageとindexedDBはファーストパーティのウェブサイト毎に分離され、またエフェメラル（一時的）なものになります。

すなわち、localStorage等については、iframe等に埋め込まれていた場合、ファーストパーティのウェブサイト毎に別の名前空間になります。
しかし、実験の結果はsessionStorageも上記の分離がなされていました。Safari 16.0まではsessionStorageは分離されておらず、Safari 16.1以降においてsessionStorageもlocalStorage同様のサイト毎の分離がされているようです。私はこの件についてのドキュメントを発見できていませんので、ドキュメントをご存知の方はぜひ教えてください。また、エフェメラルいうのは、ブラウザを終了すると削除されるという意味です。通常localStorageはブラウザを終了しても保持されますが、iframe等のサードパーティで保存されたlocalStorageはブラウザの終了と共に削除されます。一方、FirefoxのlocalStorageはサイト毎に分離されていますが、ブラウザを終了しても、localStorageの値は保持されます。

防御機能を無効化するとどうなるか

ここまで、ブラウザの提供する保護機能により、クリックジャッキング攻撃から防御される仕組みをご紹介しました。しかし、これらの機能は利用者が無効にすることができます。以下、利用者が保護機能を無効にした場合の影響を調べるため、まずはブラウザ毎にセキュリティ機能を無効化する方法を説明します。以下は、セキュリティを低下させる設定なので、検証以外では使用しないことをお勧めします。また試用した後は忘れずに戻しておいてください。

Google Chrome、Edgeの場合

Google Chrome等のChromium系ブラウザにて、デフォルトSameSite=Laxを無効化するには、Windowsの場合レジストリのLegacySameSiteCookieBehaviorEnabledForDomainListにて、無効化するドメインのリストを指定します。参考記事によると、この設定は暫定的なもので将来変更される見込みです。設定例を下図に示します。この設定では、すべてのドメインにてデフォルトSameSite=Laxを無効化しています。危険な設定なので、検証用途以外には使わないでください。

同じ方法でEdgeでも設定可能です。

Firefoxの場合

FirefoxのTCPを無効化するためには、設定|プライバシーとセキュリティから、強化型トラッキング防止機能から、カスタムを選択して、Cookieのチェックを外すか、その右のセレクトボックスで「クロスサイトトラッキングCookie（一番上）」を選択します。

Safari

SafariのITPを無効化するには、Safariの設定からプライバシーを選び、「サイト超えトラッキングを防ぐ」のチェックを外します。

結果

上記の設定変更をした結果を下表に示します。赤字で(*)付きで示した項は設定変更により条件が変わっていることを示します。

考察

前述の設定変更により、以下の状態となりました。

ブラウザ側の変更により、ほぼ全ての条件でクリックジャッキングの影響を受けるようになる
FirefoxのTCP、およびSafariのITPはプライバシー強化のための機能だが、セキュリティの効果もある
SameSite=Lax設定はクリックジャッキング対策としても効果が高い

各ブラウザの設定変更の中で、もっとも現実にありそうなものがSafariのITPの無効化です。「サイト超えトラッキングを防ぐ」でGoogle検索するとトップに表示されるのが、以下のYahoo! JAPANの記事です。

iOS 11以降では、「サイト越えトラッキングを防ぐ」がオン（有効）になっている場合があります。
「サイト越えトラッキングを防ぐ」がオンになっている場合、Cookie（クッキー）がSafari上に残らなくなります。
Yahoo! JAPANでは、複数のサービスでCookieを使用しているため、「サイト越えトラッキングを防ぐ」をオンにしていると、サービス内の機能が限定されるなど、一部のサービスを利用できません。
以下の手順を参考に、「サイト越えトラッキングを防ぐ」機能をオフにしてからYahoo! JAPANのサービスをご利用ください。
iPhone向けSafariで「サイト越えトラッキングを防ぐ」機能をオフにするより引用

しかし、当該の設定変更を行うと、Yahoo!以外のサイトでもセキュリティを弱くする結果になります。このページには以下のような記載もありますが、

注意
「サイト越えトラッキングを防ぐ」機能の設定変更は、お客様ご自身の責任において変更してください。

「お客様ご自身の責任において変更」と書いてありますが、変更による影響は何も説明されていないため、この書き方はいかがなものかという感想を持ちました。

まとめ

SameSite属性のないCookieによるセッション管理という伝統的なサイトはモダンなブラウザのデフォルト設定ではクリックジャッキング攻撃の影響はない
localStorageにトークン類を保存する実装の場合、Chromium系のブラウザ（Chrome、Edge、Opera）ではクリックジャッキング攻撃の影響がある
ブラウザのトラッキング機能を解除するとクリックジャッキング攻撃の影響を受けやすくなる
アプリケーション提供者は、ブラウザの設定によらずクリックジャッキングを防御するために、CSPやX-Frame-Optionsによりクリックジャッキング対策を実施すること
サイト運営者は、ブラウザの設定変更を促さないこと
サイト利用者は、ブラウザの設定を安易に変更しないこと

[書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法

2023-03-27T13:36:00.004+09:00

サマリ

ハッキングAPI―Web APIを攻撃から守るためのテスト技法（2023年3月27日発売）を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃（テスト）を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。
本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。

重要事項説明

本書の監修者の一人（洲崎俊氏）と評者は知人関係にある
評者が読んだ書籍はご恵贈いただいたものである
この記事のリンクにはアフィリエイトが含まれる

APIセキュリティテストとは何か

まずは、本書の主題である「APIセキュリティテスト」を本書でどのように定義しているかを紹介しよう。以下は、本書p3からの引用である。

APIセキュリティテストは、一般的なペネトレーションテストともWebアプリケーション診断とも異なります。APIが持つ攻撃対象領域（Attack Surface）の幅広さと複雑さのため、多くのペンテスターはAPIセキュリティテストを独自サービスとして位置づけています。

通常のWebアプリケーション脆弱性診断でもAPIのテストは当然含まれるが、APIはウェブアプリケーションからだけ利用されるものではなく、IoT機器などからも呼び出される。この場合、IoTシステムとしてセキュリティテストあるいはAPI単体でのセキュリティテストが行われる。本書で説明されるAPIセキュリティテストは、脆弱性診断というよりはペネトレーションテストである。

APIのペネトレーションテストを業務で経験できるエンジニアは限られていると思うが、例えばバグバウンティプログラムに参加して、公開APIをテストするような機会は、意欲と技量さえあれば誰にでも与えらるし、本書はバグバウンティプログラムに参加するバグハンター向けの注意や心構えについても度々言及している。

本書の構成

ここで、本書の構成について紹介しよう。本書は4つの部、16の章で構成される。ここからも分かるように、本書は非常に広範囲のトピックについて扱っている。

第1部 API セキュリティの原理

「第1部 API セキュリティの原理」では、後述の章立てからもわかるように。Web APIの基礎知識と、0章としてAPIテストのスコープ（範囲）、顧客からテスト許可を取得することの必要性などを説明している。2章 Web APIの解剖学では、RESTful APIに加えてGraphQLについても簡単な説明をしている。JSON/XML/YAML等のデータ形式、APIの認証方式（BASIC認証、APIキー、JWT、HMAC、OAuth2.0…）について説明する。REST APIおよびGraphQLを前提とすることから、Cookieによるセッション管理は本書では取り扱われておらず、そのためかCSRF脆弱性やCookieのSameSite属性に関する説明は割愛されている。

0章セキュリティテストへの準備
1章 Webアプリケーションの仕組み
2章 Web APIの解剖学
3章一般的なAPI脆弱性

3章の「一般的なAPI脆弱性」としては以下が紹介されている。概ねOWASP API Security Top 10 2019と重なっているが、3.1 情報漏えいと3.11 ビジネスロジックの欠陥は独自に追加したものである。

3.1 情報漏えい
3.2 オブジェクトレベルの認可不備 (BOLA)
3.3 ユーザ認証の不備
3.4 過剰なデータ露出
3.5 リソース不足とレート制限
3.6 機能レベルの認可不備 (BFLA)
3.7 マスアサインメント
3.8 セキュリティ設定ミス
3.9 インジェクション
3.10 不適切な資産管理
3.11 ビジネスロジックの欠陥

第2部 APIテストラボの構築

4章 API ハッキングラボの構築
5章脆弱なAPIラボ環境の準備

第2部はAPIテストのための実習環境として、診断ツールと脆弱なAPI環境を準備する。診断ツールとしては、Burp Suite、Postman、Wfuzzが大活躍することになるが、これら以外にOWASP Amass、KiterunnerなどAPIを発見するためのツールも紹介されており興味深い。脆弱なAPI環境としてはcrAPIなど数種を紹介している。また、訳注の形で拙作のBad Todoも紹介頂いていた（APIではなく古典的なWebアプリケーションとして）。

第3部 APIへの攻撃

第3部は、いよいよAPIの実際のテスト（攻撃）を説明する。第3部の章立ては以下の通りである。

6章 APIの検出
7章エンドポイント分析
8章認証への攻撃
9章ファジング
10章認可への攻撃
11章マスアサインメント
12章インジェクション攻撃

まず6章と7章でAPIの検出と分析を行うが、この2章は十分な紙面を使って詳しく説明されている。このあたりが、よくある「ハッカー入門」的な書籍とは異なり、本書が実務的な内容になっていることの表れのように思える。
6章 APIの検出では、OSINT的な手法を活用してAPIを検出する。通常の脆弱性診断ではAPIエンドポイントの情報は開示されるので、このステップは省略されるが、本書でいう「ブラックボックス型テスト」では、APIの検出から始まるのでこのステップが必要になる。

7章のエンドポイント分析は、APIの正常系の仕様を把握するステップであり、ウェブアプリケーション脆弱性診断のサイト巡回（クローリング）に相当する。APIの仕様はドキュメント化されている場合も多いが、そうでない場合、アプリケーション経由のAPI通信をキャプチャすることになる。このステップは本書ではリバースエンジニアリングと表現されている。通信のキャプチャはBurp Suite等の診断プロキシを用いることもできるが、本書では主にPostmanを使用する。Postmanのプロキシ機能（評者は本書を読むまで知らなかった）を用いて、API仕様を明確にする。7章の後半は情報漏洩や過剰なデータ露出等、ファジングを伴わない脆弱性検査を行う。

8章から12章はさまざまな攻撃によるセキュリティテストである。8章の前半はパスワード認証に対する辞書攻撃やパスワードスプレイなど古典的な攻撃だが、Hydraのようなパスワード解析専用ツールではなく、Burp Suite IntruderやWfuzz等のファジング用のツールを使っている。パスワードスプレイの場合、ユーザIDのリストが必要になるが、6章で解説した偵察や7章の過剰なデータ露出脆弱性を利用できるとする。8章の後半は、トークンやJWTに対する攻撃で、ブルートフォースを含む攻撃手法を解説している。

9章で説明されるファジングとは異常なデータをAPIに送信して意図しない結果を引き起こすことである。ファジングにはワイドファジング（広く浅く）とディープファジング（狭く深く）があり、前者にはPostmanのCollection Runnerを用い、後者にはBurp Suite IntruderやWfuzzを用いている。評者はPostmanを使ってはいたが、もっぱらAPIの機能的なテストの目的であり、ファジングに用いる発想がなかったので勉強になった。

10章は認可への攻撃である。認可脆弱性に関しては特に目新しいものではないが、テストの観点とツールの効果的な使い方は興味深い。ここでも、Postmanを効果的に使用している。

11章はマスアサインメントに対する攻撃である。マスアサインメント脆弱性とは、主に更新系のAPIで、「変更できてはいけない項目を変更できる」問題であり、過去のGithubの事例が有名である。例えば、利用者が自身のメールアドレスやパスワードを変更できるのは問題ないが、テーブル上のadmin列をtrueに勝手に変更できたら大問題である。API呼び出しにadmin=trueを追加するだけで意図しないadmin列の更新ができる場合がマスアサインメント脆弱性である。Ruby on Rails 4以降ではStrong Parametersと言う機能によりマスアサインメントに対策している。マスアサインメントのテスト自体は簡単なのだが、問題は「変更できてはいけないパラメータ（先の例ではadmin）」をどう発見するかである。本章では、マスアサインメント可能なパラメータの探索についていくつかの方法を説明している。

12章はインジェクションということで、クロスサイトスクリプティング(XSS)やSQLインジェクションなどが含まれる。有名な脆弱性であるからか、この章の説明は簡潔なものである。12.4.1項で説明されるSQLインジェクション攻撃文字列は、あまり凝ったものではないし、本番環境で試すには危険なものが含まれていて評者はぎょっとした（p304）。だが、直後に訳者による適切なコラム「SQLインジェクションのテストを実施する際の注意と補足（pp305-306）」があり、評者は安心した。もっとも、コラム内の文字列「’||’」や「’+’」もMySQLの場合は危険なので、SQLインジェクション検査は厳重な注意が必要である（参考:とある診断員とSQLインジェクション）。

第4部実世界におけるAPI攻撃

第4部は、「実世界におけるAPI攻撃」というテーマで、13章はバイパス技術の応用とレート制限テストとして、バリデーションやWAF、APIの利用制限を回避する技術といういかにもハッカー的なテーマ、14章は皆さん大好きGraphQLへの応用、15章では、APIの脆弱性が情報漏洩やバグバウンティでどのように発見されたかを紹介している。

13章バイパス技術の応用とレート制限テスト
14章 GraphQLへの攻撃
15章データ侵害とバグバウンティ

本書のすごいところ

本書の眼目は、APIセキュリティテストの方法論に徹底しているところである。それは、APIを検出するところから始まる。種々の検出手法は、APIそのものを探すだけではなく、マスアサインメント可能なパラメータを探す場合にも応用できるもので、この種の解説は非常に貴重なものだ。
また、テストに使うツールの説明も詳しい。筆者は主にBurp SuiteやPostmanなどの汎用的なツールを使い、Burp SuiteのIntruderやPostmanのCollection Runnerによりファジングだけでなく、パスワードに対する辞書攻撃やマスアサインメントのパラメータ探索にも用いる。その他にも多くのツールが紹介されているが、評者には、汎用ツールの使いこなしこそ勉強すべきだと思えた。
さらには、テストに対する心構えや、方針の立て方など、現役のペンテスターならではの知見が学べるところも、本書ならではの価値といえる。

本書で扱ってない内容

本書で扱っていない項目についても紹介しよう。
まず、現在APIの主流であるRESTfulAPIはステートレスだからCookieによるセッション管理は行わないという主張から、Cookie関連の記載は一切ない。これに関連して、以下の項目もない。

Cookieに関する説明（例えばSameSite属性を含め、Cookieの言及がない）
セッション管理（トークン類の保存場所はlocalStorageかCookieか等）
APIのCSRF（Content-Type、CORSとの関連を含むが、そもそもCSRFの言及がない）

また、Web APIの基礎としてJSONなどの説明はあるが、同一オリジンポリシーやCORSの説明はない。
XSSの話題は少し出ているが、Content-Typeの話題はない。例えば、以下のケースは、レスポンスボディの見かけ上はXSSだが、Content-Type: application/jsonなのでJavaScriptは実行されない。この種の話題は、他の本（例えば拙著）で学ぶ必要がある。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 43

{"message": "<img src=x onerror=alert(1)>"}

その他、触れられてないテーマの例として下記がある。

JSONP（RESTfulAPIだから関係ない）
CSP（API側だから無関係というのは分かる）
X-Content-Type-OptionsやHSTSなどのレスポンスヘッダ（侵入とは直接関係がないからか?）
脆弱性の対策方法

注意点

筆者は根っからのペンテスター気質という感じで、例えば、以下のような記載がある（p301）。

プロバイダのAPIがコンテンツを追加したり、そのWebアプリケーションに変更を加える場合、脆弱性が存在しないか探すべきかもしれません。

これに対しては、下記の訳注がついている。

一般に、許可なくサードパーティAPIをテストすることは許されていないケースが多いため、注意が必要です。

また、以下のような記載もある(p115)。

筆者は、Webアプリケーションの存在を発見すると、すぐにNiktoでスキャンを行います。

おそらく文脈的には「セキュリティテストの過程でWebアプリケーションを発見すると…」ということであろうが、Niktoも脆弱性診断ツールの一つではあるので、許可なくNiktoスキャンを行うことは問題がある。

本書の眼目は訳者の知見にある

本書は、本格的なAPIセキュリティテストの書籍の和訳というだけで価値が高いものであるが、次の点において、価値が倍加していると考える。

原書の出版後に利用サイトやツールのバージョンアップ、サイトの閉鎖等に伴う利用法の変更や代替手段の説明があること
豊富な訳注と訳者コラムにより、原書の説明不足や、日本の読者になじみのない一般知識（例えばAcmeの意味）が補足されていること
訳注での参考情報の記載がとても豊富であり、追加の勉強のために役立つこと

したがって、読者が英語に堪能であったとしても、それでもこの和訳を選択する価値は十分にある。また、参考リンクが豊富であることから、買うなら電子版(PDF)が圧倒的にお勧めである。評者はレビューを紙版で行ったが、電子版も購入した。
翻訳はこなれていて、問題となるような箇所はなかった。

本書の使い方

本書のお勧めの活用法は以下のようなものであろう。

4章「APIハッキングラボの構築」と5章「脆弱なAPIラボ環境の準備」に従い実習環境を準備する
各章を読む
章末に示された実習を行う
本書を読むだけでは分からない箇所を訳注の参考文献に従って勉強する

かなり時間がかかるはずだが、それだけの価値は必ずある。

まとめ

本書はAPIセキュリティテストに関する実践的なガイドである
ツールの紹介が多いが、読者はツールを能動的に活用する必要があり、そのための情報が本書にはある
訳注および訳者コラムは価値が非常に高く、それだけで訳書を選択する理由になる
買うなら絶対に電子版(PDF)をお勧めする

Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621の概要と発見の経緯

2022-12-20T12:20:00.003+09:00

この記事はRuby Advent Calendar 2022の第20日の記事です。前日の記事は@ydahさんによる「RuboCopのバージョンを最新に保つ技術」でした。

2022年11月22日に、Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621が発表がされました。

私はHackerOneを通じてこの脆弱性を報告しました。この記事では、当該脆弱性の概要と発見の経緯などについて報告します。

概要
脆弱性発見の経緯
影響を受けるアプリケーション
影響
対策
まとめ

概要

この脆弱性はRubyでCGIプログラムを記述際に用いられるcgi gem のheaderメソッドに内在するものです。PoCを以下に示します。このスクリプトは、クエリ文字列 num を受け取り、http://example.jp/?num=<指定された数値>にリダイレクトするものです。

#!/usr/bin/ruby
require 'cgi'

cgi = CGI.new
num = cgi.params['num'][0]
print cgi.header({'status' => '302 Found', 'Location' => "http://example.jp/?num=#{num}"})

ここで、numとして下記を指定した場合、

num=3%0d%0aSet-Cookie:+SESSID%3d1234567890

%0d%0aは改行なので、以下のレスポンスヘッダが出力されます。

Status: 302 Found
Location: http://example.jp/?num=3
Set-Cookie: SESSID=1234567890

すなわち、リダイレクトする「ついで」に任意のクッキーをセットすることができます。

クッキのセット以外に、任意URLへのリダイレクトもできます。

num=3%0d%0aLocation:+http://trap.example.com/

この結果のレスポンスヘッダは下記となりますが、

Status: 302 Found
Location: http://example.jp/?num=3
Location: http://trap.example.com/

Apacheの場合複数のLocationヘッダがあった場合、最後のLocationヘッダのみがブラウザに返されるので、結果として、trap.example.comにリダイレクトされます。これにより、偽ログイン画面に遷移してパスワードを盗むなどができます。

また、以下のようにHTTPレスポンスボディを出力することもできます。

num=3%0d%0a%0d%0a<script>alert(1)</script>

レスポンスは下記となります。空行の後にJavaScriptコードが出力されていることが分かります。

Status: 302 Found
Location: http://example.jp/?num=3

<script>alert(1)</script>

ただ、このままだとリダイレクトが優先されるのでレスポンスボディは表示されません。リダイレクトを避けるテクニックとして、ヘッダインジェクションによりStatus 500等を出力する方法があります。このテクニックははるぷさんに教えていただきました。

num=3%0d%0aStatus:+500%0d%0a%0d%0a<script>alert(2)</script>

このケースでの出力は下記となります。

Status: 302 Found
Location: http://example.jp/?num=3
Status: 500

<script>alert(1)</script>

Statusヘッダが2つありますが、前述のようにApacheは最後のStatusヘッダのみをブラウザに返すため、リダイレクトは無効となり、JavaScriptが実行されます。これはXSSと同等の脅威となります。

脆弱性発見の経緯

なぜ今どきRubyのcgi gemを調べたか、それにはちょっとした理由があります。元々は、2020年1月にRuby on RailsのHTTPヘッダインジェクションに脆弱性を見つけて、HackerOneにて報告したところ、これはRailsの脆弱性ではなくて、ウェブサーバーのPumaの脆弱性だということになり、Puma側で修正された(CVE-2020-5247)ことがきっかけです。

この脆弱性について、適当な場で紹介したいと思っていたところ、2021年6月18日に銀座Rails#34@リンクアンドモチベーションがオンライン開催されることがわかりましたので、CfPに応募して採択されました。

Rails周辺におけるHTTPヘッダインジェクション脆弱性の動向

この内容は私のYouTubeチャンネルにて公開しています。動画データを主催者様に提供いただきました。ありがとうございます。

この発表（動画）では、冒頭のHTTPヘッダインジェクション入門をPHP（の古いバージョン）にて行っていますが、元々はRubyのCGIで説明するアイデアがありました。そのサンプルプログラムを作成する過程でRubyのcgi gemに脆弱性があることに気づきました。ゼロデイの脆弱性を説明に使うわけにもいかず、本番ではPHPの旧版の脆弱性を用いた形になりました。

さて、cgi gemに脆弱性があることは疑いのないものでしたが、「RubyでCGIを書いているサイトはどれくらいあるのだろう」という疑いもあり、gem側で修正しなくても、注意喚起してアプリケーション側での改修でもよいのではないかと思いました。とはいえ、当方が勝手に「ゼロデイ脆弱性」を公開することもよくありません。

このためRubyコミッタ柴田さんに相談したところ、チームで検討するのでHackerOne経由で申告してほしい（日本語でOK）旨の連絡をいただきましたので、HackerOneに投稿した内容が冒頭で紹介したものです。こちらは脆弱性と認められ、改修されることになりました。また、CGI::Cookieにもセキュリティ上好ましくない実装を見つけましたので、追加の報告として提出しました。

CGI::Cookieクラスにおけるセキュリティ上好ましくない仕様および実装 - HackerOne

内容は、Cookieのname、path属性、domain属性設定時に外部由来の値を使うとインジェクションが可能というものでした。こちらも脆弱性と認められ、同時に修正されています。詳しくはHackerOneの報告を御覧ください。

影響を受けるアプリケーション

当脆弱性の影響を受けるアプリケーションは下記のとおりです。

cgi.headerメソッドに外部由来の値をセットしている場合
CGI::CookieによりCookieのname、path属性、domain属性設定時に外部由来の値を使っている場合

※ Cookieのpath属性およびdomain属性へのセミコロンを用いたインジェクションは、PHP-7.2以前にも存在していました（バグ#69948）。

影響

当脆弱性の影響は概要で示したとおりですが、まとめると以下のようになります。

任意のレスポンスヘッダの追加・改変
- （その結果）クッキーの追加、改変
- （同上）任意URLのリダイレクト
レスポンスボディの追加・改変
- （その結果）任意JavaScriptの実行（XSSと同等の脅威）
Cookieのname、path、domainを通じた属性等の改変

対策

cgi gemを最新版（0.3.5, 0.2.2, 0.1.0.2）にアップデートすることで対策されます。

Ruby本体のバージョンアップ

Rubyのバージョン 3.1.3 / 3.0.5 / 2.7.7 にて最新のcgi gemを含む形で対応されています。現時点では、主要Linuxディストリビューションはアップデートを提供していないようです。

cgi gemのアップデート

前述のように、Linuxディストリビューション経由でのyumやaptによるアップデートでは本問題の対応はできませんが、gemコマンドによるアップデートは可能です。

$ sudo gem update cgi

ただし、Rubyのバージョンが2.7以降である必要があります（参考）。Ruby 2.7未満を使用している場合は、Ruby自体をバージョンアップする（推奨）か、以下のアプリケーション側の対策を実施してください。

アプリケーションでの対応

アプリケーション側で対策するには、以下を実施してください。

cgi.headerメソッドに渡すパラメータを検証して改行(\rや\n)が混入しないようにする
CGI::Cookieに渡すname属性やdomain属性を検証する

まとめ

Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621について、脆弱性の内容と経緯について説明しました。今時RubyでCGIプログラムを記述するケースもほとんどないとは思いますが、HTTPヘッダインジェクションという今となってはレアな脆弱性が発見され、きちんと修正されたことをご報告したいと思い本稿を書きました。

脆弱性そのものは拙著「安全なWebアプリケーションの作り方」に記載されている範囲のものですので、バグハンターを目指す皆さんは、「著名ソフトウェアだけどあまり使われていない機能」に着目すると、比較的容易に脆弱性が見つけられ、インターネットの安全にも貢献できるのではないでしょうか。

また、今回の脆弱性対応くださった柴田(@hsbt)さん、@mameさん、@nobuさんに感謝申し上げます。きちんと対応いただき、発見者としてうれしく思います。ありがとうございました。

PHPカンファレンス2022にてSPAセキュリティ超入門の話をします

2022-09-09T11:32:00.001+09:00

今年もPHPカンファレンスにてトークさせていただくことになりまして、以下のようなお話をいたします。

日時：9月25日(日) 14:40〜15:40
場所：大田区産業プラザPiO および YouTube
費用：無料
講演タイトル：SPAセキュリティ超入門
申し込み: connpass
アジェンダ:

SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。
本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。

実は昨年も「SPAセキュリティ入門」というテーマでトークをしておりまして、今年はもう少し易しめということで「超入門」としました。

昨年の講演のスライドおよび動画は以下から参照ください。

昨年は主にSPAにまつわるセッション管理に焦点をあてて、JWTによるセッション管理は是か非か、JWT等トークン類の保存場所はCookieかlocalStorageかという基本的な考え方（しばしば論争になる）のお話をしました。

今年はもう少し現実的なテーマとして、アジェンダにもあるように、LaravelによるサーバーサイドAPI、Reactによるフロントエンドという構成のSPAを題材として、以下のような「よくある」脆弱性がいかにして混入するか、およびその対策について説明します。

認可制御不備
SQLインジェクション
クロスサイトスクリプティング(XSS)

これら脆弱性は、LaravelおよびReactを普通に使っていれば混入しないはずのものです。しかし脆弱性診断等ではこれら脆弱性はしばしば目にします。普通に作れば混入しないはずの脆弱性がなぜ混入するのか。私はその原因を追い続けていましたが、どうも従来型のアプリケーション（マルチページアプリケーション=MPA）では常識だった知識が、SPAでは伝承されていないのではないかと考えるに至りました。この要因ファクターXについて紹介するとともに、なぜ今基本的な脆弱性が多いのかを説明しようと思います。

なお、前述のようにファクターXは従来の常識ですので、「なぁんだ、そんなことか」となること請け負いですが、「そんなこと」レベルのことが問題になっているように考えています。

それでは、よろしくお願いいたします。

無事終了しましたのでスライドと動画を添付いたします。

SPAセキュリティ超入門 by @ockeghem

メタップスペイメント不正アクセス事件の第三者報告書から攻撃の模様を読み解く

2022-07-04T10:39:00.004+09:00

株式会社メタップスペイメントの運営する決済代行システムから約288万件のクレジットカード情報が漏洩した不正アクセス事件について、第三者委員会の報告書および経済産業省の行政処分（改善命令）があいついで公開されました。

第三者委員会調査報告書（公表版）
クレジットカード番号等取扱業者に対する行政処分を行いました（METI/経済産業省）

本稿では、主に第三者委員会の調査報告書（以下「報告書」と表記）をベースとして、この事件の攻撃の様子を説明します。

システムの概要

報告書にはシステム構成図やネットワーク構成図は記載されていないため、報告書の内容から推測によりシステムの構成を以下のように仮定しました。

図中のサーバー名は報告書の記載に従っています。以下、概要を説明します。

サーバ名	概要
A社アプリ	一般社団法人A 会員向け申込みフォーム経産省改善命令では、「同社とコンビニ決済に係る契約を締結していた加盟店にサービスを提供するために開発、運用していたアプリケーション（以下「加盟店向けアプリ」という。）」が該当すると思われる
K管理画面	社内用決済管理画面。A社アプリのサーバーと同居していた(*1)
決済サーバ	決済機能を提供するサーバー。攻撃対象ではなかった可能性があるが機能としては存在するので記載した
データベース	各システム共用のデータベース報告書内にデータベースの種類は明記されていないが、用語集にMySQLの説明があるので、MySQLを使用していると推測
復号化サーバ	報告書に登場する。暗号化されたクレジットカード情報を復号を提供するAPIと思われるが、不正アクセスに関する記載はない(*2)

注 *1 : 報告書中には、A社アプリとK管理画面が同居していた旨は明記されていませんが、時系列表には、事故後の対応として「管理画面サーバから確認用サイト、A社アプリの分離（2022年1月7日）」を実施した旨が記載されているので、元々これらは同一サーバに同居していたと考えられます。

注 *2 : 報告書には「Web2系に暗号化されたカード情報に係る復号化サーバが配置されていた。Web2系には、決済システムも配置されており、そこで暗号化されたカード情報も管理されていた。」と記載されています。報告書中では「サーバー」、「サイト」、「画面」、「機能」の使い分けが明確でないため断言は難しいのですが、「Web2系」がサーバーを意味すると解釈すると、決済サーバと復号化サーバは同一マシンに同居していた可能性があります。

時系列の流れ

第三者委員会の報告書に加えて、メタップス社の2月28日づけリリースも合わせて時系列の流れをまとめました。

日時	出来事
2021年8月2日	メタップスペイメントの決済データセンターに対する不正アクセスが開始。K管理画面へのXSS攻撃か?
2021年8月31日	K管理画面に対する不正ログイン始まる
2021年10月14日	A社アプリにSQLインジェクション攻撃始まる
2021年10月15日	A社アプリに、SQLインジェクションで得たパスワードによる不正ログイン
2021年10月19日～10月27日	A社アプリのSQLインジェクションにより2万5千件のカードデータ窃取
2021年10月25日～12月14日	K管理画面不正ログインによりカード番号全桁の検索が実行される（2万件程度）
2021年10月25日	メタップスペイメントがA社アプリのメンテナンス中にSQLインジェクション攻撃を発見
2021年10月27日	メタップスペイメントがA社アプリのSQLインジェクション対策を完了
2021年11月11日	A社アプリのアップロード機能よりバックドアが設置され、攻撃開始。最終的にカード情報データベースの全データが窃取されたとみられる（460,395件 + 2,415,750件）
2021年12月14日	アクワイアラ E 社からイベントペイで不正利用懸念の連絡
2021年12月16日	イベントペイでクレジットカード決済を停止
2022年1月6日	K管理画面の管理用サイトにBasic認証を追加
2022年1月7日	K管理画面サーバから確認用サイト、A社アプリの分離、A社用DBとペイメントDBの分離
2022年1月8日	A社アプリのサーバの分離を実施
2022年1月24日	メタップスペイメントがバックドアプログラムの存在を確認、削除
2022年1月24日	メタップスペイメントが不正アクセス被害を公表
2022年1月28日	管理用サイトのクロスサイト・スクリプティングに対応、Basic認証の追加
2022年2月28日	メタップスペイメントが不正アクセスによる情報流出を公表

攻撃の流れの詳細については以下で説明します。

1. K管理画面のアカウント情報の窃取、不正ログイン

報告書によると、以下の順で攻撃が行われました。

K管理画面のXSS脆弱性を悪用し、当管理画面のID・パスワードを窃取（報告書には時期の記載がないが、2022年2月28日づけメタップス社のリリース記載の2021年8月2日の不正アクセスが該当するか?）
X氏アカウントによる不正ログイン（2021年8月31日～）
メタップス社内にてX氏アカウントのパスワードを変更（2021年9月末から2021年10月初旬までの間）これ以降X氏アカウントの不正ログインなし
Y氏アカウントにて不正ログイン（2021年10月6日以降）

攻撃の模様を下図に示します。

報告書によると、XSS攻撃を許してしまった理由は下記のとおりです。

自社で実施した脆弱性診断ではXSS脆弱性が検出されていたが、高危険度の脆弱性があるとPCI DSSの審査に通らないため、報告書を改ざんして脆弱性自体をなかったことにした
WAFが導入されていなかった（PCI DSSではコードレビューまたはWAFのいずれかの導入を求められているので、WAF導入は必須ではない）

XSS攻撃の詳細

K管理画面は社員向けのシステムであるので、画面の詳細は外部の攻撃者にはわからないはずです。報告書ではXSS攻撃の詳細は発表されていませんが、管理画面を狙うXSS攻撃自体は最近よく見かけるもので、おそらく問い合わせ画面のように外部から入力できるフォームからJavaScriptによる攻撃コードを注入したのではないかと予想されます。その種の攻撃の例としては、Water Pamolaが知られています。Water Pamola型のXSS攻撃の例については以下の動画を参照ください。

なぜパスワードが窃取できたか?

次にXSS攻撃でK管理画面のパスワードが窃取できた理由を考察します。こちら報告書には書かれていないので、「ありそうな経路」を列挙するにとどめます。

管理機能としてパスワードを平文で表示する箇所があった
ログイン状態で自分自身のパスワードを変更した（パスワード再入力なし）
他の管理者のパスワードを変更する機能を悪用した（パスワード再入力なし）
ログイン中のユーザあるいは他の管理者のパスワードをリセットする機能を悪用した
偽のタイムアウトを引き起こして「IDとパスワードを入力してください」という画面を表示した（12:56追記）

1は通常はあり得ないのですが、この事件では「あり得ないことが幾つも起こっている」のでないと断言することもできません。ありそうな経路は2または3ですが、そうすると、本来の管理者がログインできなくなります。その段階で気づきそうなものですが、報告書には当初不正ログインに使われていたX氏のパスワードが変更されたとあるものの変更した理由は明記されていない（ちなみに時期も明確ではない）ため、「X氏は攻撃者にパスワードを変更されたことに気づかないままパスワードをリセットした」可能性も考えられると思います。

社内用決済管理画面はインターネットからアクセスできた

K管理画面に不正ログインされたということは、社内用決済管理画面にインターネットからアクセスできたことを意味します。これも奇異な状態ですが、報告書の時系列表には、2022年1月6日に「管理用サイトにBasic認証を追加」とあるので、それまではインターネットから自由に当該システムにアクセスできたものと推測されます。

2. SQLインジェクション攻撃によるカード情報とパスワードの窃取

報告書には以下のように記載されています。以下引用です。

攻撃者は、2021年10月14日から2021年10月27日に渡り、A社アプリに対するSQLインジェクション攻撃により、暗号化されたカード番号、マスクされたカード番号及びA社管理画面の管理者アカウント情報をそれぞれ不正取得した。

この攻撃の様子を下図に示します。

A社アプリは元々他のクラウドに設置されていたものですが、2018年に東京データセンターに移設され、その際、データベースのテーブルはカード情報データベースと同じスキーマに設置されていたとのことです（データベーススキーマの未分離）。このため、A社アプリに対するSQLインジェクション攻撃により、カード情報まで窃取されたことになります。

SQLインジェクションによるパスワード窃取と不正ログイン

また、A社管理画面の管理者アカウントの窃取と不正ログインについては以下のような時系列となっています。

2021年10月15日 05：09	SQLインジェクションによりID・パスワードの窃取
2021年10月15日 05：12	不正ログイン

IDとパスワードの窃取から、わずか3分後に不正ログインされていることから、パスワードは平文で保存されていた可能性が高いと推測されます。仮にハッシュ値等で保存されていたとしても3分間で平文パスワードを復元されたのでは意味がありません。この不正ログインが次項の「バックドアプログラムの設置」につながります。

SQLインジェクション脆弱性が残置された理由

SQLインジェクション攻撃を許してしまった理由は、前述のWAFの未設置の他、A社管理画面の開発経緯が原因だったようです。以下報告書からの引用です。

上記ソースコード・レビューに関する社内規程が作成されたのは、2012年10月であるところ、A社アプリが委託先であるB社によって開発されたのは、2007年頃であるため、当時は、社内的にも同アプリに対してSQLインジェクション攻撃への対策としてソースコード・レビューを実施することは必須とされていなかった。また、MPにおいては、以前より「決済システム以外は脆弱性対策をする必要がない」との認識があったため、同規定の作成時において、当時フロントシステムにあったA社アプリが見直し的にソースコード・レビューの対象となることもなかった。

A社アプリが東京データセンターに移設された後も、同様の認識により、ソースコード・レビューや脆弱性診断の対象にはなっていなかったようです。

3. バックドアプログラムの設置と攻撃

こちらも報告書から引用します。

攻撃者は、2021年10月15日、A社管理画面に一度不正アクセスしているが、更に2021年11月11日、A社管理画面に不正アクセスを行い、A社アプリの管理機能の一つであるファイルアップロード機能を悪用し、バックドアプログラムを設置した。
そして、不正ファイル経由で、データベース内から、暗号化されたカード情報を含む当時格納されていた全ての情報を不正取得したと考えられる。

この様子を下図に示します。

ファイルアップロード機能によるバックドアプログラム（おそらくWebShell）を設置するのは定番の攻撃方法です。報告書には「東京DCがA社アプリと同じJavaで構築されているため」という記述があるのため、A社アプリはJavaで構築されていることがわかります。なので、バックドアプログラムは、JSP記述のWebShellと推測されます。

また、「不正ファイル」という用語はバックドアプログラムとは別のものとして記載されているようです。不正ファイルの中身は判然としませんが、WebShellから起動されたリバースシェルあるいはデータベース（MySQL）アクセス用のツールではないかと思われます。

バックドア設置はSQLインジェクション対策後に行われた

A社アプリのSQLインジェクション脆弱性対策は2021年10月27日に完了していますが、A社アプリのパスワードを悪用してのバックドア設置は2021年11月11日に実行されています。SQLインジェクション対応の一環として、A社アプリのパスワード変更を実施しておけば、バックドア設置はできなかったはずです。

復号鍵の窃取

また、報告書には記載がありませんが、経産省の改善命令には復号鍵について以下の記載があります。

当該クレジットカード決済システム内のデータベースに保存していた暗号化されたクレジットカード番号（マスキングされたクレジットカード番号を含む。）、有効期限、セキュリティコード及びこれらを復号化するための復号鍵が窃取され

復号鍵が窃取されたと明記されていますが、復号鍵がデータベースに保存されていたとは考えにくく、また「復号化サーバ」が存在する以上は、復号鍵はそこにあると考えるのが自然です。

報告書には復号鍵の漏洩ルートに関する記載はないようですが、時系列表には以下の記載があります。

2022年1月28日復号APIのディレクトリトラバーサルに対応。

このため、復号APIのディレクトリトラバーサル脆弱性が悪用されて復号鍵が窃取された可能性があります。

任意形式のファイルをアップロード可能だった

管理画面にファイルアップロード機能があること自体はよくあることですが、この場合、任意ファイル名で任意の内容のファイルをアップロードできると、簡単にWebShell等を設定されてしまうので通常はファイル名やファイルの中身に制限をつけます。しかし、報告書によると、以下のような記載があり、

アップロード機能の設定の不備により、想定以外のファイルをアップロード可能だった為、バックドアプログラムを設置されていた。

拡張子.jspのファイル等をアップロードできていたことがわかります。

ファイル改ざん検知の不備

バックドアプログラムの設置は一種の「改ざん」にあたるため、ファイル改ざん検知システムが導入されていれば、バックドア設置を早期に発見できた可能性があります。メタップスペイメント社はPCI DSS 3.2.1完全準拠をうたっていましたし、PCI DSSではファイル改ざん検知システムの導入を要求しています。A社アプリはPCI DSSの対象外だったようですが、このアプリケーションにも改ざん検知システム（ファイル整合性監視ツール）を導入して監視しておけば、早期にバックドアの設置を検知して対応できた可能性があります。また、この記事の冒頭で推測しているようにA社アプリとK管理画面が同一サーバーに同居していたとするならば、PCI DSSの観点からも、ファイル改ざん検知の対象にすべきであったと考えます。

もっとも当社の監視体制については、報告書に以下の記載もあるため、改ざん検知システムを導入していただけでは有効に機能しなかった可能性が高いです。

従業員のヒアリング結果によれば、実際はセキュリティアラートにする検証ができる人材が不足しており、また、必要な範囲でセキュリティアラートを発信するようにするためのシステム面での調整（チューニング）が出来ていないことも相まって、MPの従業員は、セキュリティアラートが発信されても、特段気にして監視していなかったとのことであり、十分な検証がなされていなかったことが認められた。

事故後の対応として、2022年1月29日に「改ざん検知設定を修正」とあるため、改ざん検知システム自体は元々導入されていたようです。

4. 管理画面への再度の不正アクセス及びカード番号照会開始

報告書には以下のように書かれさています（2021年10月25日から同年12月14 日）。

上記SQLインジェクション攻撃及びバックドアプログラムにより、既にデータベースからマスクされたカード番号を不正取得しており、K管理画面上で不正取得したマスクされたカード番号を検索照会することによって、平文のフル桁のカード番号を閲覧することができたと考えられる。

また時系列表には以下のように記載されています。

海外IPアドレスによりUserID「Y氏」を利用してカード番号の検索が行われ、不正取得した閲覧用パスワード入力後、平文のフル桁のカード番号の検索結果が表示された。
なお、この間、平文のフル桁のカード番号を確認可能なURLに対し、約2万回不審な連続アクセスが確認された。

この攻撃の様子を下図に示します。

クレジットカード窃取は3経路存在した

ここまで説明した攻撃手法から、クレジットカード情報を攻撃者が入手した経路は以下の3経路があることになります。

A社アプリ経由: SQLインジェクション攻撃によりマスク化カード情報と暗号化カード情報を入手（2万5千件、2021年10月27日まで）
バックドア経由: バックドアにより暗号化カード情報と復号鍵を入手（288万件、2022年1月18日まで）
K管理画面経由: K管理画面のもつクレジットカード番号検索機能の悪用による平文全桁カード情報取得（2万件、2021年12月14日まで）

3のK管理画面経由での平文カード情報取得は2021年12月14日で終わっています。攻撃者がなぜ経路3をこの時期にやめたかという理由を推測すると、この時期に復号鍵が入手できたため、経路3を悪用する理由がなくなったから、というのが私の推測です。

事故対応の過程で、当初メタップスペイメント社は上記1および3の経路のみを把握していたようですが、以下のように、1および3以外の経路があることに気づきます。

MPは、2022年1月21日に受領したK社12件のログの社内検証結果として、判明している原因（K管理画面に対する不正アクセスやSQLインジェクション攻撃）以外でクレジットカード情報が窃取されていると判断した（1月8日までの対策のみでは情報漏えいを防ぎきれていないことを認識した。）。

その後の調査にて、2022年1月24日にバックドアプログラムの発見、削除に至ります。

まとめ

メタップスペイメントのクレジットカード情報漏えい事件の概要を第三者委員会の報告書を元に説明しました。決済代行事業社からクレジットカード情報が大量に漏洩するという衝撃的な事件でありましたが、漏洩に至る経緯も驚くべきもので、第三者委員会報告書はセキュリティ関係者にとって非常に学びの多い資料だと思います。

侵入の発端となった脆弱性は、クロスサイトスクリプティングおよびSQLインジェクションという非常に基本的なものでありますが、仮にそれらの脆弱性があっても、他の保険的な対策や侵入発見後の対処が適切であれば、被害を最小限に留められたはずという点でも学びが多く、機会があれば別の記事で紹介したいと思います。

クロスサイトスクリプティングやSQLインジェクションなどの基本的な脆弱性や、当事件で悪用されたファイルアップロード機能やアカウント管理に関する対策方法については下記の書籍にて説明しています。

DNSリバインディング(DNS Rebinding)対策総まとめ

2022-05-16T10:53:00.004+09:00

サマリ

DNSリバインディングが最近注目されている。Google Chromeは最近になってローカルネットワークへのアクセス制限機能を追加しており、その目的の一つがDNSリバインディング対策になっている。Googleが提供するWiFiルータGoogle Nest WiFiはデフォルトでDNSリバインディング対策機能が有効になっている。 DNSリバインディング対策は、攻撃対象アプリケーションで行うべきものであるが、ブラウザ、PROXYサーバー、リゾルバ等でも保護機能が組み込まれている。本稿ではそれら対策機能の状況と対策の考え方について説明する。

DNSリバインディング（DNS Rebinding）とは

DNSリバインディングはDNS問い合わせの時間差を利用した攻撃です。DNSのTTL（キャッシュ有効期間）を極めて短くした上で、1回目と2回目の問い合わせ結果を変えることにより、IPアドレスのチェック等を回避する攻撃です。下図は、DNSリバインディング時のDNS問い合わせの様子です。

DNSリバインディングの主な脅威

DNSリバインディングによる脅威は、DNS問い合わせがあるところ全てにありえますが、典型的な脅威として下記があります。

外部からアクセスできない対象へのブラウザ経由での攻撃
SSRF攻撃のチェック回避

ブラウザ経由での攻撃

ブラウザ経由での攻撃の概要図を示します。

上図は、攻撃者の誘導により、被害者が罠のページ(http://trap.example.org/)を閲覧しているところです。罠ページが閲覧された瞬間にDNSのAレコード（IPv4アドレス）を変更し、罠ページは10秒後にXMLHttpRequestにより http://trap.example.org/secret.html をアクセスします。この時点ではIPアドレスは変更されているためイントラネット内のサーバーにアクセスします。この攻撃により、外部からは直接アクセスできないサーバーにアクセスできます。

このように、DNSリバインディングは、イントラネット内のサーバーの他、ルーターやファイアウォール、IoT機器など、利用者のパソコン自身など、「外部からはアクセスできないが内部ネットワークからはアクセスできる」機器やサーバーが主な攻撃対象です。IPアドレスのみでアクセス制御されているサイトも攻撃対象になります。

攻撃対象の例として、Ruby on Railsの開発環境がありました。Railsの開発支援機能web-consoleはDNSリバインディングに脆弱で、任意のコードを外部から実行できる問題が指摘されていました。

DNS rebinding attacks protection in Rails 6

このため、バージョン6以降で開発版でのDNSリバインディング対策が入るようになりました）。具体的にはHostヘッダのチェックであり、これはDNSリバインディングの定石的な対策方法の一つです。

この機能は開発環境のみでプロダクション環境では無効になります。これは、Web-consoleのようなデバッグ支援環境でリモートコード実行の脆弱性が入りやすい（現実にあった）ので、開発環境だとDNSリバインディングの脅威があるという想定だと思います。

【参考】

SSRF攻撃との組み合わせ

SSRF攻撃の際に使われるDNSリバインディングについては以下の記事をお読みください。

EC2上でDNS RebindingによるSSRF攻撃可能性を検証した | 徳丸浩の日記

ここでは概要を説明します。以下のようなスクリプトがEC2上で動いているとします。外部からURLを取得して、その内容を表示するものです。

$url = $_GET['url'];
$urlinfo = parse_url($url);
$host = $urlinfo['host'];       // URLからホスト名を取り出し
$ip = gethostbyname($host);     // 接続先IPアドレスを取得
if ($ip == "169.254.169.254") { // AWSのIMDSチェック
  die("Invalid host $host");    // IPアドレスが169.254.169.254ならエラー
}
$ch = curl_init($url);          // URLからコンテンツ取得、表示

上記のスクリプトに、IPアドレス 169.254.169.254 のチェックをしていますが、これはEC2のIMDS (Instance Metadata Service)という機能を悪用されることを防ぐためです。IMDSは下記のように、169.254.169.254という仮想的なエンドポイントにアクセスすると、参照元インスタンスの設定を返します。以下は、EC2インスタンスに付与されたIAMクレデンシャルを参照する様子です。

[ec2-user@web ~]$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/XXXX
{
  "Code" : "Success",
  "LastUpdated" : "2022-05-08T04:17:09Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAR6Mxxxxxxxxxxxxx",
  "SecretAccessKey" : "Wrt7en1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "Token" : "IQoJb3JpZ2luX2VjEAQaDxxxxxxxxxxxxxxxx...",
  "Expiration" : "2022-05-08T10:52:42Z"
}

先に示したスクリプトは複数の抜け道があるのですが、その一つがDNSリバインディングによる攻撃です。以下は、DNSサーバーにdigコマンドにより連続してアクセスしたところ、2回目にIMDSのIPアドレスが返っている様子です。

[ec2-user@web ~]$ dig example.net +short ; dig example.net +short
203.0.113.2
169.254.169.254
[ec2-user@web ~]$

これにより、IPアドレスチェックの際は無害な内容を返し、本番アクセスの際はIMDSのIPアドレスということになって、SSRF攻撃によりIMDSの内容を盗むことができます。

【参考】

DNSリバインディングの対策

下図はDNSリバインディングの対策ができる場所を示しています。

以下、図中の数字の順に説明します。

① 対象サイト側の対策

DNSリバインディングの根本対策は、攻撃対象のサイトや機器側で行われるべきです。DNSリバインディングの対策は以下のいずれかにより対策できます。

ホスト名のチェック、あるいはダミーのデフォルトバーチャルホスト
認証機能の実装（安全なパスワードを設定すること）

以下はNginxでダミーのバーチャルホストを設定している例です。本番サイトはexample.jpですが、それ以外のホスト名のリクエストはすべてダミーのコンテンツが返されることになります。ダミー側には機密情報や機能などはないので、DNSリバインディング攻撃を「受け流す」ことができます。

# ダミーのバーチャルホスト(Hostヘッダがexample.jp以外はこちらが設定される)
server {
        listen 80 default_server;
        server_name '_';
        root /var/www/dummy;  # 無害なコンテンツが返される
}
# 本番サイトのバーチャルホスト
server {
        listen 80;
        server_name example.jp;
        …

あるいは、認証機能の実装でも対策になります。DNSリバインディング攻撃は利用者のセッションを乗っ取れるものではないからです。IoT機器やルーターなど初期パスワードが設定されているものは、必ず初期パスワードを変更する必要があります。

【参考】

DNSリバインディング入門 - YouTube

SSRF対策のパイパスについては、SSRF自体の対策の中で考える必要があります。詳しくは以下のコンテンツを参照ください。

② ブラウザ側対策

DNS Pinning

主要ブラウザでは、DNSリバインディング対策としてDNS Pinning（DNSピニング）が実装されています。DNS Pinningとは、DNSのTTLが短い場合でも、DNSの参照結果を一定時間保持することです。下図は主要ブラウザのDNS Pinningの期間です。

Google Chrome	Firefox	Safari	IE
1分程度	1秒～70秒	15秒～30秒	無期限?

DNSリバインディング対策という観点からはDNS Pinningの期間は長いほど安全ですが、DNSリバインディング以外の正当な状況でサーバーのIPアドレスが変化する場合もあるので、過度にDNS Pinningの期間が長いと副作用もあると考えられます。DNS Pinningの期間は時代とともに変化しており、最近はウェブサイトの本来のIPアドレスが短期間で変化するため、DNS Pinningの期間は短めにされる傾向があります。

Google Chromeで提唱されている対策

Google ChromeではDNS Pinning以外に「ローカルネットワークに対する攻撃」への防御機能が実装され始めています。Google Chrome 94では、XMLHttpRequestやFetch APIにより「パブリックネットワークからプライベートネットワークへの送信」については、HTTPSであることを要求するようになりました。

Starting in Chrome 94, public non-secure contexts (broadly, websites that are not delivered over HTTPS or from a private IP address) are forbidden from making requests to the private network.

Private Network Access update: Introducing a deprecation trial - Chrome Developers より引用

Chrome 94以降、パブリックな非セキュアコンテキスト（広義には、HTTPSで配信されていないウェブサイトや、プライベートIPアドレスからでないウェブサイト）は、プライベートネットワークへのリクエストが禁止されるようになりました（私訳）。

これにより、Google ChromeでDNSリバインディング攻撃しようとすると以下のようなエラーになります（ホスト名は例示用のもの）。

Access to XMLHttpRequest at 'http://example.com/secret.txt' from origin 'http://example.org' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `private`.

エラーメッセージとしてはCORSエラーとなっていますが、DNSリバインディングは通常同一オリジンポリシーの範囲内のアクセスであり、当然CORSのエラーではありません。しかし、Google Chromeの最近のセキュリティ機能では、パブリックネットワークからプライベートネットワークへのリクエスト、およびプライベートネットワークからローカルホストへのアクセスについては、通常より厳しい制限を課していることになります。

このセキュリティ機能は、ローカルネットワークに対するCSRF緩和策として導入されたようですが、DNSリバインディング対策としても機能すると思われます。なぜなら、HTTPSによりDNSリバインディング攻撃しようとすると、攻撃先サーバーへのアクセスで証明書のエラーエラーになり、アクセスは停止するからです。

さらに、Google Chrome 102 以降では、このような状況でプリフライトリクエストが送信されるようになる予定です。

Preflight requests for PNA are also sent for same-origin requests, if the target IP address is more private than the initiator. This is unlike regular CORS, where preflight requests are only for cross-origin requests. Preflight requests for same-origin requests guard against DNS rebinding attacks.

Private Network Access: introducing preflights - Chrome Developers より引用

PNA(Private Network Access)のプリフライトリクエストは、ターゲットIPアドレスがイニシエーターよりもプライベートである場合、同一オリジンのHTTPリクエストに対しても送信されます。これは、プリフライトリクエストがクロスオリジンリクエストに対してのみ送信される通常のCORSとは異なります。同一生成元リクエストのプリフライトリクエストは、DNSリバインディング攻撃を防止します（私訳）。

引用元にもDNSリバインディング攻撃防止のためと明記されています。

このようにGoogle Chrome（あるいはChromium系ブラウザ）を使うことでDNSリバインディングの対策が強化されますが、これら対策はProxyサーバー経由での通信には適用されません。Proxy経由での通信の場合、ブラウザからはパブリックあるいはプライベートという区別がつかないからです。これはDNS Pinningについても同様であり、各ブラウザ共通の挙動になります。

③ Proxyサーバーでの対策

前述のようにProxy経由でのブラウザ利用の際には、ブラウザ側のDNSリバインディング対策は機能しないため、Proxy側での対策が求められます。よく理由されるFoward ProxyであるSquidには、以下のDNS Rebindin対策が利用できます。一方、Apache HTTPdをProxyとして使う場合、DNSリバインディングに使える機能は調査の範囲では見つかっていません。ご存じの方はぜひご指摘ください。

(1) IPアドレスによるアクセス制御

Squidのアクセス制御機能から、接続先(Destination)のIPアドレスを制限することができます。以下は、192.168.0.0/24に対するアクセスを拒否する例です。

acl localnet dst 192.168.0.0/24
http_access deny localnet

(2) DNS Pinning

SquidはDNSキャッシュの上下限を指定することができます。

ディレクティブ	意味	デフォルト値
positive_dns_ttl	DNSキャッシュの上限	6時間
negative_dns_ttl	DNSキャッシュの下限	1分

これらのうち、negative_dns_ttl はDNS Pinningの用途に使うことができます。しかしながら、negative_dns_ttlをむやみに長くすると副作用もあります。もしも正規のDNSクエリに失敗した場合、その失敗の結果もキャッシュされるからです。また、前述のように、正常なIPアドレスが短期間で変わる場合もありえます。このため、negative_dns_ttlをデフォルトより長くすることはお勧めできません。

結論としては、SquidでDNSリバインディング対策する場合は、(1)のアクセス制御による方法がお勧めです。

【参考】

PROXY（プロキシ）経由でのDNSリバインディングと対策 | 徳丸浩の日記

④ DNSキャッシュサーバーでの対策

リゾルバ（DNSキャッシュサーバー）による対策も可能です。Squidの項で説明したDNS Pinningとアクセス制御の両方が主要リゾルバで用意されています。

DNS Pinning

下表に主要ブラウザでDNS Pinningを指定するディレクティブを示します。DNSコンテンツサーバー側でTTL=0秒などと短い秒数が指定されていた場合でも、こちらで指定した秒数に切り上げられます。

リゾルバ	bind9	unbound	dnsmasq	PowerDNS	KNOT DNS
設定項目	min-cache-ttl	cache-min-ttl	min-cache-ttl	minimum-ttl-override	cache.min_ttl()
備考	90秒以下	制限など記載なし	1時間以下	デフォルト1秒	デフォルト5秒

PowerDNSとKNOT DNSは最短のTTLがデフォルトとして指定（1秒～5秒）されており、TTL=0は許容されない設定になっています。このような控え目の設定でもSSRF攻撃の緩和には役立つと思われます。

特定IPアドレスの拒否

また、多くのDNSサーバーは、DNSリバインディング対策として、IPアドレスのフィルタリング機能を提供しています。下表はIPアドレスの拒否リストあるいはDNSリバインディング対策として使えるプライベートIPアドレス等を拒否するためのディレクティブの一覧です。

リゾルバ	bind9	unbound	dnsmasq	PowerDNS	KNOT DNS
設定項目	deny-answer-addresses	private-address	stop-dns-rebind	設定は見つからなかった	modules.load('rebinding < iterate')
備考	サブネットマスク等で指定	サブネットマスク等で指定	一括停止	Luaスクリプトで可能	一括停止、詳細にやるならLuaスクリプト

私の調査では、PowerDNSのみ該当する項目を探せなかったのですが、Luaスクリプトで特定IPアドレスを拒否することは可能でした。また、dnsmasqとKNOT DNSはIPアドレス指定ではなく、DNSリバインディングに使われそうなサブネットマスクを一括して拒否する形になっています。

また、単体のリゾルバではありませんが、Googleが提供するGoogle Nest WiFiにはDNSリバインディング防御機能が提供されてます。

Google Nest スピーカー、ホームメディアサーバー、IoT（モノのインターネット）デバイスのような接続されたデバイスをホストするホームネットワークは、DNS リバインディングと呼ばれる攻撃を受けるおそれがあります。Google Wifi では、この種の攻撃を防止するため、DNS リバインディングに対する保護機能で、公開ドメインにプライベート IP アドレス範囲を使用されないようブロックすることができます。この機能はデフォルトで有効になっています。

DNS リバインディングに対する保護機能 - Google Nest ヘルプより引用

試したところ、192.168.10.1 のようなプライベートIPアドレスはブロックされる一方で、127.0.0.1 のようなlocalhostのアドレスはブロックされません。また、当該機能は副作用の可能性もあるため、無効にすることもできます。

リゾルバでのDNSリバインディング対策をどう考えるか

多くのリゾルバがDNSリバインディング対策の機能を提供しますが、デフオルトは無効化されていることから、いずれも「積極的に使っていきましょう」という姿勢ではないように感じます。その典型はbindです。min-cache-ttlの最大値は90秒なので「これで守り切る」という数字ではありません。また、IPアドレスの拒否リストについては以下のような注意書きがマニュアルに付記されています。

The “rebinding” attack must primarily be protected at the application that uses the DNS. For a large site, however, it may be difficult to protect all possible applications at once. This filtering feature is provided only to help such an operational environment; turning it on is generally discouraged unless there is no other choice and the attack is a real threat to applications.

4. BIND 9 Configuration Reference — BIND 9 9.19.0 documentation より引用

リバインディング攻撃は、主にDNSを使用するアプリケーション側で保護されなければなりません。しかし、大規模なサイトでは、可能性のあるすべてのアプリケーションを一度に保護することは困難な場合があります。このフィルタリング機能は、そのような運用環境を支援する目的にのみ提供されています。他に選択肢がなく、攻撃がアプリケーションにとって本当に脅威とならない限り、この機能を有効にすることは一般に推奨されません。（私訳）

この「DNSを使用するアプリケーション側で保護されなければなりません」という指摘に私も同意します。また、以下の資料にはDNSリゾルバの防御機能の抜け穴が報告されています。例えば、CNAMEとしてlocalhost.を返すようなケースが紹介されています。

State of DNS Rebinding - DEF CON 27 Hacking Conference Presentation

このため、DNSリゾルバでの対策はあくまで緩和策としてとらえておくべきだと思います。

結局DNSリバインディング対策はどうすればよいか

ここまで説明したように、DNSリバインディング対策が「出来る」ポイントは以下の4箇所あります。

攻撃対象
ブラウザ
PROXYサーバー
リゾルバ

これらの中で、確実な対策がとれるのは攻撃対象のみです。対策自体は難しいものではないので、まずはこれを検討するべきです。しかし、以下のような状況はありえます。

社内ネットワーク内に攻撃対象となり得る機器が多すぎで把握すら難しい
対象のサーバーや機器側の仕様上対策が難しい

このため、以下のステップで対策を検討するとよいでしょう。

ネットワーク内に存在するDNSリバインディング攻撃対象の機器やパソコンの洗い出し
対策の要否検討
対策方法の検討
対策実施

DNSリバインディングはマイナーな攻撃方法であり、他のウイルス感染などの方が簡単に侵入できるため、あまり過敏になることもないとは思いますが、原理的には可能であるので、「重要情報が盗まれる」などの状況は放置しない方がよいでしょう。DNSリバインディングの確実な対策の一つが「認証ちゃんとやる」ですので、結局のところ、

社内ネットワークといえども認証とアクセス制御をきちんとやる

この当たり前のことをちゃんとやっていれば大丈夫です。後は、保険的な対策としてPROXYやリゾルバの対応をどうするかですが、近年はPROXYやリゾルバはセキュリティ製品の一機能である場合も多く、自前でオープンソースソフトウェアを構築するケースは少ないと思います。なので、PROXYやリゾルバでの対策は、積極的に活用するというよりは、「使える場合は使うことも考える」くらいのレベル感ではないでしょうか。

まとめ

DNSリバインディングの対策として使える機能について説明しました。Google社がDNSリバインディング対策に熱心なことが印象的ですが、まずは攻撃可能性の洗い出しと、ローカルネットワークでも認証をおろそかにしないという基本的な対策を推奨いたします。

とある通販サイトに学ぶ自動ログイン機能のバッドプラクティス

2022-03-14T10:48:00.001+09:00

サマリ

とある通販サイトにて「メールアドレス・パスワードを保存する」機能がありますが、サイトにクロスサイトスクリプティング(XSS)脆弱性がサイトにあると生のパスワードが漏洩する実装となっています。本稿では、この実装方式を紹介し、なぜ駄目なのか、どうすべきなのかを紹介します。

記事の最後にはセミナーのお知らせを掲載しています。

はじめに

家人がテレビを見ていて欲しい商品があるというので、あまり気は進まなかったのですが、その商品を検索で探して購入することにしました。「気が進まない」というのは、利用実績のないサイトはセキュリティが不安だからという理由ですが、この不安は的中してしまいました。

最初の「えっ?」はパスワード登録のところでして、パスワードを再入力する箇所で「確認のためもう一度、コピーせず直接入力してください」とあるのですよ。私は乱数で長く複雑なパスワードを入力しかけていたのですが、コピペができないとなると長すぎるので、パスワードを短くしました。セキュリティ上は逆効果だと思うのですが、なぜこうするのでしょうかね。しかし、これは本題ではありません。

「パスワードを保存する」チェックボックスの存在

会員登録が終わってサイトにログインしようとすると、パスワード欄の下に下記のようなチェックボックスがあり、デフォルトはONになっています。

メールアドレス・パスワードを保存する

「ログイン状態を保持」とかならよくある機能ですが、「パスワードを保存」とは匂いますね。そこで、そのままログインをした後、ログアウト後にもう一度ログイン画面を表示させると、なんということでしょう! メールアドレスとパスワードが初期値として入っているではありませんか! 以下のようなHTMLがサーバー側で生成されていました。

<input name="email" value="[email protected]">
<input type="password" name="pwd" value="P@ssw0rd">

「パスワードを保存する」機能の実装は?

こういう実装を見ると「サーバー側でパスワードが平文で保存されている」と思う人が多いようですが、そうではないようです。

メールアドレスとパスワードは、あるクッキー（ここではXとする）に紐づけられています。当初は、クッキーXをキーとしてサーバー側でパスワード等を保存しているのかと思いましたが、そうではなく、クッキーXにメールアドレスとパスワードが暗号化して保存されているようです。そう判断した理由は、メールアドレスとパスワードの長さを変えるとクッキーの長さも変わるからです。また、暗号化に際し初期化ベクトルも使ってないようです。

クッキーが漏洩すると平文パスワードまで漏洩する

「初期化ベクトルを使わないなんてダメじゃないか」と思いますよね。そうなんですが、このサイトの場合、もっとダメな理由があります。というのは、暗号化されたクッキーをセットしてログイン画面を表示させると、先に紹介したように、平文でメールアドレスとパスワードがHTML上に表示されるのです。つまり、暗号化していても簡単に平文に戻せるのですよね。なので、初期化ベクトル云々という次元ではなくなってしまっているわけです。

このサイトの場合、クッキーXにsecure属性はついていますが、HttpOnly属性はついていません。なので、サイト上にクロスサイトスクリプティング（XSS）脆弱性があると、クッキーは簡単に漏洩します

仮にHttpOnly属性がついていてもXSSで平文パスワードが漏洩する

しかし、仮にクッキーXにHttpOnly属性がついていても、XSS攻撃により平文のメールアドレスとパスワードは漏洩します。XSS攻撃によりXMLHttpRequestでログイン画面をリクエストすると、そのレスポンスのログイン画面HTMLにはメールアドレスとパスワードが平文で記載されているからです。

そもそもサイトにXSSがあると、クッキーにHttpOnly属性がついていても「なりすまし」により情報漏えいやサイト機能の悪用は避けられません。このあたりは以下の動画にて詳しく説明しています。

しかし、パスワードまで漏洩してしまうと、そのパスワードがパスワードリスト攻撃により悪用されたり、「パスワードを入力しないと利用できない機能」まで悪用できるので通常のXSSよりも被害が増大することになります。

この場合のベストプラクティスは?

ログインを簡便にするために、いったんログインした後はパスワードを入力しなくてもログインを継続したいというニーズ自体はよくあるものであり、拙著では、「5.1.4 自動ログイン」にて解説しています。

体系的に学ぶ安全なWebアプリケーションの作り方第2版脆弱性が生まれる原理と対策の実践

本項では、自動ログインの危険な実装を紹介した上で、トークンを使うなど安全な自動ログインの実装方法について紹介しています。詳しくは上記書籍を参照してください。

サイトオーナーはどうすればよかったのか?

とある通販サイトの自動ログイン機能がイケてないことを紹介しましたが、このサイトの運営者はどうすればよかったのでしょうか。

まず思いつくのは「脆弱性診断はしていなかったのか?」ということです。脆弱性診断していたかどうかは外部の者には分かりませんが、以下の可能性が考えられます。

脆弱性診断はしていなかった
脆弱性診断はしていたが指摘されなかった
脆弱性診断で指摘されていたが、改修はしなかった

最後のケースを考えると、仮に脆弱性診断で指摘されていたとしても、サイトが出来上がった後では簡単に修正できるものでもなく、いささか「手遅れ」という感があります。なので、サイトを実装する前に自動ログインのセキュリティを検討しておくべきでした。

自動ログインは珍しい機能ではなく、「徳丸本にも載っている」ようなよくある機能なのですから、ウェブアプリケーションのセキュリティガイドラインのようなものがあれば、安全な実装ができていたかもしれないと考えられます。このガイドラインには、自動ログインのような機能面だけでなく、SQLインジェクションのような実装面にも言及されているとよいですね。

宣伝

では、「徳丸本にも載っていないような機能」についてはどうすればよいでしょうか。こちらについては個別に検討するしかありません。その際に類似機能を持つ先行サイトを調べてもよいでしょうが、たまたま参考にしたサイトがセキュリティ的に強固な仕様であるとは限りません。

また、「そもそもセキュリティ上の問題があるのか」という脅威分析をしないことには、セキュリティを検討する・しないの俎上にも上がらないということになります。

ということから考えると、セキュアな開発にも到達度レベルがあって、以下のようになるのではないかと考えています。

今回紹介したケースは、脆弱性診断はしていたかもしれないが、指摘されたか否かは分からず、少なくとも危ない実装が修正されないまま本番リリースされたという意味で、「レベル1にも到達していない」と考えられます。

私は拙著を書く際に、ウェブアプリケーションに存在する問題を列挙してできるだけ多くのパターンを解説してしまおう、と目論みました。なので徳丸本はあんなに分厚いのですが、それでも全てのパターンを列挙することは当然できなません。なので、徳丸本をいくら読んでも到達できるのは上記の「レベル2」です。

私の最近の関心はその上のレベルに到達するための方法論です。これについては2022年3月16日のセミナーにて簡単に紹介する予定ですので、お時間がある方は参加いただけると幸いです（宣伝）。

2022年3月16日（水）16:00～17:00（オンライン）
講演タイトル：セキュア開発ライフサイクル（SDLC）実践入門
イベント詳細・お申し込みはこちらから

2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか

2022-01-26T13:02:00.007+09:00

サマリ

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にて実装されていましたが、細かい挙動の差異で既存サイトに不具合が生じたようで、いったん巻き戻されたようです。
このため、Firefoxについての現状の挙動はSafari等と同じになります。以下、当面の間読み替えていただければと思います。

デフォルトsamesite=laxキャンセルの情報は、TwitterにてMasataka Yakuraさんから教えていただきました。以下のスレッドにて確認することができます。

そのFirefox 96のSameSite=Laxデフォルト化なんですが、既存サイトの互換性に影響したためバックアウトされるようです（Schemeful SameSiteはすでにバックアウトされました）。https://t.co/otiTV0uf9y
— Masataka Yakura (@myakura) January 27, 2022

（追記終わり）

Cookieのsamesite=laxとは

Cookieのsamesite属性は、元々Google Chrome 51にて導入されたセキュリティ機能で、その後他の主要ブラウザにも導入されています。samesiteのとり得るパターンは、指定なし、none、lax、strictですが、本稿では主にsamesite=laxについて取り上げます。

Cookieにsamesite=laxを指定した場合、異なるサイトから遷移してきた場合にCookieが送信されるか否かは文脈によって変わります。下図の状況においては、example.jpに対してGETメソッドで遷移する場合はCookieが送信されますが、POSTメソッドの場合はCookieは送信されません。

GETリクエストとPOSTリクエストで挙動が変わるのは合理的な仕様です。例えば、gmailからtwitterにリンクをたどって遷移する場合はGETメソッドが使われるためtwitterにCookieが送信され、twitterをログイン状態で閲覧することができます。一方、罠サイトから投稿ページに偽投稿を送信する場合は、「更新処理にはPOSTメソッドを使う」という原則によりPOSTメソッドのはずなので、samesite=laxのクッキーはサイトに送信されず、ログイン状態にはならないためCSRF攻撃も成立しないことになります。

このように、Cookieのsamesite=lax指定は、サイト閲覧時の利便性と安全性のバランスがよく、優れた仕様であると考えられます。

デフォルトsamesite=laxの流れ

samesite属性がブラウザに導入された当初は、従来のサイトの互換性は維持されていましたが、Google Chorme 80において、samesite無指定時の挙動がsamesite=laxに変更され、Firefoxもバージョン96にて追随しました。

この変更により「サイト側でCSRF対策していなくてもブラウザ側にてCSRF防御する」ことが可能になります。この変更は過去のサイトの互換性を崩す大胆なものであるため議論を呼んだようですが、Google ChromeおよびFirefoxという主要ブラウザが対応したことにより、今後の主流となることが確定しました。

その他のブラウザはどうか

本稿執筆時点（2022年1月26日）において、Google Chrome、Edge、Opera、Firefox等主要ブラウザの多く（Chromium系およびFirefox）にてデフォルトでsamesite=laxとなっています。一方、IEおよびSafariはsamesite属性を実装しているものの、現時点ではデフォルトでsamesite=laxにはなっていません（参考）。また、iOS上のブラウザはすべてWebKitベースとなっているので、iOS上のChrome等もSafariと同じ挙動になります。

2022年1月においてCSRF攻撃を受ける条件

それでは、「サイト側でCSRF対策していない場合」において、CSRF攻撃を受ける条件はどうでしょうか。以下、ケース別に説明します。

古いブラウザを使っている場合

samesite属性未実装の古いバージョンのブラウザを使っているユーザーは、サイト側のsamesite属性の設定に関係なくCSRF攻撃を受けることになります。最近のブラウザは自動アップデートの機能を実装していますが、自動アップデートを無効にしていたり、スマホ版のブラウザのバージョンが古い、スマホのOSをアップデートしていないケースではsamesite属性が無視される場合があります。

2分間ルール

最新のGoogle ChromeおよびFirefoxにおいて、samesite属性を指定しないCookieはsamesite=laxの扱いを受けますが、Cookieが生成されてから2分経過してからsamesite=laxになる仕様になっています。このため、ログイン処理などで新たにCookieが発行してから2分間であれば、CSRF攻撃の影響を受ける可能性があります。

2分間ルールの挙動の違い

さらに、Google ChromeとFirefoxでは「2分間ルール」の実装に違いがあるようです。

Google Chromeの場合、Cookieが新規生成されなくても、同名のCookieが上書きされた場合、2分間ルールが延長されます。これは、セッション固定攻撃対策などでセッションIDの値を再生成（PHPの場合はsession_regenerate_idを使う）した場合が該当します。

これに対して、Firefoxの場合、Cookieを同名で上書きした場合は2分間ルールは延長されず、新規にCookieが生成された時刻が起点になります。このため、脆弱性のデモなどで敢えて2分間ルールを使いたい場合は、いったんCookieを削除してから新規にCookieを生成することにより、2分間ルールの恩恵を受けることができます。

下図は上記挙動を図示したものです。時刻=1.5分のところでCookie SESSIDを再生成したところ、Google Chromeはsamesite=noneの時間が2分間延長されているのに対して、Firefoxは延長されていないこと、一旦Cookieを削除すると、どちらのブラウザでもsamesite=noneの期間が2分間復活することが図から見て取れます。

Google ChromeとFirefoxのこれら挙動は実験により確かめたもの（Google 97.0.4692.99、Firefox 96.0.2にて確認）なので、将来のバージョンアップなどで変更される可能性があります。

まとめ

2022年1月時点でのCSRFの影響について説明しました。ブラウザ側のセキュリテイ強化により、CSRF攻撃はかなり影響を受けにくくなっていはいますが、まだ「サイト側で何もしなくてもCSRF攻撃を受けない」状況ではありません。

引き続きCSRFの対策は必要であり、以下を推奨いたします。

アプリケーションフレームワークの提供するCSRF防御機能を使う
セッションIDのCookieにはsamesite=laxを明示する
更新処理ではGETメソッドを受け付けないことを確認する

おわび・訂正

当初の版では「IEはsamesite属性に対応していない」と記載していました。これはMDNの記載を根拠としたものですが、実際にはIEの最新版ではsamesite属性に対応しています。本来であれば該当箇所を打消し線で訂正すべきところですが、煩わしくなるため、単に修正しております。

PHPにはエスケープ関数が何種類もあるけど、できればエスケープしない方法が良い理由

2021-12-20T16:13:00.000+09:00

このエントリは、PHP Advent Calendar 2021 の20日目のエントリです。19日目は @takoba さんによる PHPプロジェクトのComposerパッケージをRenovateで定期アップデートするでした。

SQLインジェクションやクロスサイトスクリプティング(XSS)の対策を行う際には「エスケープ処理」をしましょうと言われますが、その割にPHP以外の言語ではあまりエスケープ処理の関数が用意されていなかったりします。それに比べてPHPはエスケープ処理の関数が非常に豊富です。これだけ見ても、PHPはなんてセキュアなんだ! と早とちりする人がいるかもしれませんが、しかし、他言語でエスケープ処理関数があまりないのはちゃんと理由があると思うのです。

本稿では、PHPのエスケープ処理用の関数を紹介しながら、その利用目的と、その関数を使わないで済ませる方法を説明します。

SQL用のエスケープ関数

セキュリティとエスケープといえば、真っ先に思いつくのがSQL文字列のエスケープです。関数名にescapeが含まれるものとして下記があります。これらのエイリアスもありますが、割愛します。

これらのうち、pg_escape_identifierは識別子のエスケープをする関数です。SQLの識別子の問題については、下記の連作を御覧ください。

結論として、SQL識別子のエスケープは、phpMyAdminのようなツールを開発する場合は必要になるが、一般のアプリケーション開発であれば識別子のエスケープをしなくてもすむようにした方がよい、というものです。

また、pg_escape_literalは、エスケープするだけでなく文字列を引用符で囲ってリテラルの形にしてくれるものです。PDOだと以下のメソッドが該当します。

PDO::quote

単にエスケープだけするのに比べて、引用符で囲ってリテラルを生成する関数・メソッド（pg_escape_literalやPDO::quote）を使ったほうが安全です。これらquote系の関数は、対象が数値の場合も適切に処理してくれることが期待できるからです（ただし、伝統的にPDOは数値の扱いがイマイチですが）。

さて、SQLインジェクション対策にはエスケープが重要とはよく言われることですが、数値が対象の場合はエスケープしない（してはいけない）ことや、データベース・ソフトウェア毎にエスケープのやり方が異なるなど、現実には難易度の高い処理です。このあたりの事情についてはIPAの安全なSQLの呼び出し方をぜひご一読ください。

安全なSQLの呼び出し方

結論としては、リテラル中の文字列をエスケープするのではなく、プレースホルダを用いてSQLを呼び出すべきであり、さらに言えば、今どきのモダンなアプリケーション・フレームワークを使う場合は、フレームワーク付属のO/Rマッパーを使うので、現実のアプリケーション開発でSQLのエスケープ関数を利用するケースは多くはないと思います。

HTMLエスケープ

HTMLエスケープ、すなわち文字を文字参照に変換する関数には以下があります。

通常クロスサイトスクリプティング対策にはhtmlspecialchars関数を用いますが、こちらについてもフレームワークを使う場合はテンプレートエンジンの機能で自動エスケープさせるのが吉でしょう。

また、PHPはJavaScriptの文字列リテラルのエスケープについては提供していません。json_encodeでできないこともないですが、JavaScriptの動的生成は非常に難易度の高い処理なので、拙著2版では、カスタムデータ属性に値を書いて、それをJavaScriptから参照する方法を推奨しています。これにより、JavaScriptのエスケープではなくHTMLのエスケープで統一できます。

体系的に学ぶ安全なWebアプリケーションの作り方第2版

OSコマンド（シェル）

PHPは、system関数などOSコマンド呼び出しのために、シェル形式のエスケープ関数を提供しています。これは他の言語ではあまり見当たらず、比較的珍しい機能だと思います。

これらのうち、escapeshellcmdについては仕様にまつわる脆弱性があり修正も不可能ということで、使用禁止となっています。

警告
escapeshellcmd() はコマンド文字列全体に適用しなければなりません。また、そうしたところで、まだ任意の数の引数を渡すことによる攻撃を許してしまいます。単一の引数をエスケープするには、かわりに escapeshellarg() を使わねばなりません。
https://www.php.net/manual/ja/function.escapeshellcmd.php より引用

この脆弱性は、下記ブログ記事で私が報告したものです。

PHPのescapeshellcmdの危険性

この脆弱性を見つけたきっかけは、拙著の初版を書いている際に、OSコマンドインジェクション対策としてエスケープ処理で本当に大丈夫だろうかと心配になり色々試している中で見つけたものです。心配になった理由は、シェルのエスケープ処理の難易度が高いためです。

そして、この心配はPHPMailerの脆弱性CVE-2016-10033という形で現実のものになりました。

さて、シェル形式のエスケープ処理関数は比較的珍しいと書きましたが、他の言語ではどうしているのでしょうか。実はもっと良い方法、すなわちシェルを経由しないコマンド呼び出しが提供されています。以下の記事で解説しています。

PHPだってシェル経由でないコマンド呼び出し機能が欲しい

そして、PHP 7.4にて、ようやくシェル経由でないOSコマンド呼び出しが提供されました。

シェルを経由しないOSコマンド呼び出しがPHP7.4で実装された

このため、今後はOSコマンドインジェクション対策としては、エスケープ処理ではなく、proc_openによる「シェル経由でないOSコマンド呼び出し」を用いるべきだと思います。この場合はescapeshellarg等によるエスケープ処理は必要ありません。

正規表現

PHPは正規表現用のエスケープ関数も提供しています。

preg_quote

これはどのような時に用いるかと言うと、正規表現パータン中に外部入力を含める場合です。そんなことあるのかと思ってしまいますが、これが原因でRCE（リモートコード実行）可能な脆弱性が混入した例があります。

phpMyAdmin3.5.8以前に任意のスクリプト実行を許す脆弱性(CVE-2013-3238)

なので、外部入力を正規表現パターンに含める場合はpreg_quoteを使いましょう…とは私は思いません。そんな危険な行為そのものを避けるべきだと思います。現に、上記で紹介したphpMyAdminの脆弱性(CVE-2013-3238)も、当該箇所で正規表現を使わない形で改修しています。詳細は上記ブログ記事を参照ください。

ということで、preg_quoteもよほどのことがない限り使わない関数だと私は思います。

URL

URL中に記号文字やマルチバイト文字を含める場合はパーセントエンコード（URLエンコード）しますが、これも一種のエスケープ処理と考えることができます。PHPで用意されているパーセントエンコードの関数には以下があります。

概ね似たような処理を行う関数が4種類もあるのがPHPらしいですが、通常はrawurlencodeを用いればよいでしょう。urlencodeの方は、空白を%20ではなくプラス記号にエンコードします。こちらはHTMLフォームのapplication/x-www-form-urlencoded形式ということでしょうが、その差が問題になるケースはあまりないと思います。

URL中で記号をエスケープしないとまずい理由は、クエリ文字列では = や & の記号が区切り文字として特別な意味を持つからです。たとえば、a=値という形式で、値が「b&c=d」だとすると、全体ではa=b&c=dとなって、値がbのみで千切れてしまいます。

このように、URLのエスケープ（パーセントエンコード）自体は必要な処理ですが、目的がクエリ文字列の組み立てである場合は、rawurlencode等よりも便利な機能があります。それは、http_build_query です。この関数は配列を引数として、クエリ文字列形式の文字列を返します。この過程でパーセントエンコードもしてくれます。特に、項目数が多い場合に便利ですが、単一の場合でもhttp_build_queryを使うことをお勧めします。一般的に、ミクロな処理の関数を組み合わせて使うよりも、マクロな機能の関数を用いた方がプログラムの意図が分かりやすくなり、バグ、ひいては脆弱性が入る余地が少なくなるからです。

LDAP

古来から知られたLDAPインジェクションという脆弱性があります。私自身は、LDAPを使った検索で「*」を指定したら全件マッチになった例は脆弱性診断で見つけたことがあります。また、LDAPのクエリの式を変更するという、文字通りのインジェクションもありえます。

LDAPのクエリに外部入力を含めることは十分考えられるため、エスケープが必要になる場合があります。PHPでは5.6から下記の関数でLDAPのエスケープを提供しています。

ldap_escape

目的不明なエスケープ関数

以下の3つの関数はPHP4時代からある由緒正しいものですが、利用シーンがよく分かりません。

これらのうち、addcslashesはリファレンスに「C 言語と同様にスラッシュで文字列をクォートする」とありますが、スラッシュ「/」ではなくバックスラッシュ「\」ですよね。PHP言語でC言語のソースコードを生成する時に使うのでしょうか。

もっとわけが分からないのは、addslashesとquotemetaです。

addslashes

エスケープすべき文字の前にバックスラッシュを付けて返します。エスケープすべき文字とは、以下のとおりです。
シングルクォート (')
ダブルクォート (")
バックスラッシュ (\)
NUL (null バイト)
https://www.php.net/manual/ja/function.addslashes.php より引用

なんとなく、MySQLのエスケープルールを思い起こしますが、わざわざ以下のように「SQLインジェクション対策に使うな」と念押しがしてあります。

addslashes() 関数は、 SQLインジェクションを防止しようとして誤った使い方がされることがあります。この関数を使うのではなく、データベース特有のエスケープ関数および/もしくはプリペアドステートメントを使うようにしてください。

quotemetaの説明は以下のとおりで、正規表現のエスケープを連想しますが、

quotemeta

文字列 str について、
. \ + * ? [ ^ ] ( $ )
の前にバックスラッシュ文字 (\) でクォートして返します
https://www.php.net/manual/ja/function.quotemeta.php より引用

正規表現用とするには、ハイフン「-」が抜けていますし、正規表現用にはpreg_quoteがあるので、そちらを使うべきです（そもそも正規表現パターンに外部入力を含めるなということはありますが）。また、Perlにも同名の関数がありますが、こちらは記号類をすべてエスケープするので仕様が異なります。ということで、quotemetaの使い道は謎です。ご存じの方は教えてください。

まとめ

PHPに多数用意されているエスケープ用関数について紹介しました。

エスケープすべき局面でエスケープを怠る、あるいはエスケープ方法が不適切だと脆弱性になります。そして、エスケープ処理はしばしば難しいのです。エスケープをなめてはいけない。そして、本稿を書くにあたってケッサクな例を見かけました。以下は富士通のInterstage Application Server Smart Repository運用ガイドからの引用ですが、

SDK(JNDI)の場合
　JNDIは注意が必要です。
　LDAP、JNDI、Java言語それぞれで、\(エンマーク(バックスラッシュ))文字を特殊文字と扱うためです。いくつか例を示します。
　\を含むcn属性を指定するとします。
a\b
　LDAPの規約により\をエスケープする必要があります。
cn=a\\b
　JNDIの仕様により、この名前を指定するために、それぞれの\をエスケープする必要があります。
cn=a\\\\b
　Java言語の仕様により、この名前を文字列リテラルとして指定するために、それぞれの\をエスケープする必要があります。
String name1 = "cn=a\\\\\\\\b";
　同様に、,(カンマ)、"(ダブルクォーテーション)の場合はそれぞれ次のようになります。
String name2 = "cn=a\\\\,b";
String name3 = "cn=a\\\\\"b";
　最初の例をJNDIで使用する場合は、次のように記述します。
String name = "cn=a\\\\\\\\b,o=Fujitsu\\\\, Inc.,c=jp";

多重のエスケープが必要なために、バックスラッシュを8個重ねる必要が生じています。

実は、私も類似の記事を過去に書いたことがあります。以下の記事ではバックスラッシュを12個重ねています。

「\%foo」から始まる文字列を検索するクエリをハードコーディングする

ということで、まとめは以下の通りです。

エスケープすべき局面でエスケープを忘れると脆弱性になる（前提）
エスケープ処理は意外にややこしい（現実）
エスケープしなくてもよい書き方（SQLのプレースホルダ、シェル経由しないOSコマンド呼び出し等）があればそちらを採用しよう（お勧め）

PHPビルドの楽しみ、あるいはポケモンとしてのPHPについて

2020-12-19T17:21:00.000+09:00

この記事はPHP Advent Calendar 2020の19日目です。18日目は@You-sakuさんのPHPでYoutubeのAPIを利用したいでした。

私は以前、PHPのすべてのバージョンを使う環境として、phpall、phpcgiall、modphpallを紹介してきました。これらは、PHPのすべてのバージョンをそれぞれコマンドライン、CGI、mod_phpの形式で動作させるものです。

現在では、PHPのバージョンを切り替えて動作させる仕組みはphpenv、phpbrew等何種類もありますし、php-buildという、PHPをビルドするというそのものずばりの仕組みも広く使われています。

しかし、短いPHPスクリプトをPHPの全バージョンで試すという私の使用法からは、phpall（およびその派生としてphpcgiall、modphpall）はメリットがあり、私は今もPHPのビルドを続けています。

そう、私は今も、PHPのすべてのバージョンのバイナリをCLI、CGI、Apacheモジュールの形式で持っているのです。そして、元々は目的があって始めたことなのですが、いまや、「PHPのすべてのバージョンをコンプする」こと自体が目的化してしまっています。この感覚、何かに似ているなと思い返したら…そうです。ポケモンを集めるような感覚なのです。いまや、

徳丸にとってPHPはポケモン

と言っても過言ではありません。

PHPがポケモンだという主張は認めていただくとして、PHPにもポケモン同様にレアキャラがあるでしょうか…

あります。ビルドが困難であればあるほど、レアなポケモン（に相当するPHP）と言ってよいでしょう。

経験上、以下の条件を満たすPHPがレアな（ビルドが困難な）ものと言えます。

古いバージョンのPHP（PHP4、PHP5.0、5.1、PHP5.2等）
新しい環境で動く（Ubuntu 20.04等）
できるだけ多くの拡張モジュールを備える
32ビット版よりも64ビット版

以下、その理由を簡単に説明しましょう。

古いバージョンのPHP

次の項と関連しますが、古いPHPはビルドすること自体が困難です。その一端は@hnwさんの以下の記事で読むことができます。

phpallコマンドでPHPの全バージョンの挙動を試す

古いPHPがビルドが困難な理由は以下の通りです。

Cコンパイラの新バージョンでは文法チェックが厳しくなった結果、コンパイルエラーになりコンパイルできない
PHPが利用するライブラリの非互換なバージョンアップ

これらの回避策としては以下が考えられます。

古いコンパイラ（gcc）を使う
コンパイルエラーを緩和するオプションを設定する
古いライブラリを使う
PHPにパッチをあてる

最終的にはPHPにパッチをあてざるを得ない場合もありますが、これはできれば避けたいところです。新しいgccでコンパイルエラーになる箇所を見ていると「これ、単にバグじゃないか」と思うものが多い（それ以外ではライブラリの非互換）のですが、他の方法で回避できるのであれば回避したい…ということで、古いgccを試したりしましたが、今は以下のgccのオプションで回避して、最低限PHPソースにパッチをあてています。

-std=gnu89
-fgnu89-inline

ライブラリも結構ハマるところでして、以下は複数のバージョンを使っています。

zlib（1.1.4、1.2.11）
openssl（0.9.8、1.1.1）
curl（7.15.0、7.16.0、7.68.0、7.72.0）
libxml2（2.7.8、2.9.8、2.9.10）

意外にハマるのがcurl（libcurl）でして、非互換なバージョンアップのため、PHPのバージョンによってcurlのバージョンも変える必要がありました。

新しい環境で動く

前項の裏返しになりますが、新しい環境（OS）であるほど、古いPHPをビルドすることが困難になります。特にライブラリの非互換は避けようのないところで、OS（Linuxディストリビューション）にバンドルされているライブラリでうまくビルドできない場合は、古いライブラリを探してきてビルドすることから始めなければなりません。ライブラリ毎にビルド方法に癖があったりして苦労する場合もありますが、そこがまた楽しいのです。

できるだけ多くの拡張モジュールを備える

前項と関連しますが、できるだけ多くの拡張モジュールを指定した方がビルドの難易度が上がります。OSにバンドルされていないライブラリや、バンドルはされているが非互換のため古いライブラリを別途導入しないケースはなおさらです。

32ビット版よりも64ビット版

意外なことを書くと思われるかもしれませんが、古いPHP（4.1、4.2あたり）はAMD64でのビルドが困難です。ビルド自体はできるのですが、正常に動作しません。この時代はまだAMD64の現物がなかった（AMD64の出荷は2003年4月）からと思われます。PHP 4.0はビルドでき動作もするので、調整すればPHP 4.1や4.2も動作すると思うのですが、私はまだ成功していません。

phpallをUbuntu16.04(32ビット)からUbuntu20.04(64ビット)に移行

さて、著者はphpallの環境を当初Ubuntu12.04(32ビット)に構築し、その後Ubuntu16.04(32ビット)に移行していましたが、PHP 8.0α版が出た際にUbuntu20.04(64ビット)に移行しました。

そのきっかけとなったのは、PHP 8.0から導入されたJITを試そうとして時のことです。どうもx86（32ビット）では、JITは使えないようなのです。下図はphpinfoからの該当部分です。

JITのRFCではx86もサポートされていると書かれていましたが、本番投入は見送られたのでしょうか。私は、phpallを64ビット環境に移す決断をしました。以下はUbuntu20.04(64ビット)でのphpinfoで、JITが有効化できていることがわかります。

残る課題

楽しみとしてのPHPビルドについて紹介しましたが、現状課題が残っています。前述のように、64ビット環境でのPHP4.1と4.2のビルドには成功していないからです。ここは私の技術の至らなさではあるのですが、将来の楽しみにとっておこうと思います。やり方をご存知の方がいれば教えていただけるとありがたいです。

auじぶん銀行のフィッシングSMSが届いた

2020-11-14T21:18:00.001+09:00

3日前に、auじぶん銀行の巧妙な不正出金についてYouTube動画を公開しました。みんな見てねー。

auじぶん銀行アプリに対する不正出金の驚くべき手口

そうしたところ、先程私のiPhoneに以下のようなSMSが届きました。

ふーん、au自分銀行のときは宅配事業者を装ったSMSということでしたが、これはどうなんでしょうね。開いてみると…

詐欺サイトの警告が出ていますが、構わずに開いてみると…

きたきたきたー。これですよ。auじぶん銀行のフィッシング（SMSの場合はスミッシングと言いますが）サイトのようですよー。「閉じる」をタップすると…

うーむ、これがauじぶん銀行の本物のフィッシングサイトですよ。これかー。僕が作った偽サイトよりもきちんと作ってありますねー（笑い）。

ちなみに、本物のauじぶん銀行サイトはこちら。

よく似ていますね。お客様番号とログインパスワードの欄は共通ですが、偽物の方は暗証番号と誕生日を要求しています。私がデモ用に作った偽サイトは、さらにカタカナの氏名を要求していますが、氏名はサイトにログインすると容易にわかるので省略しているのでしょうね。

せっかくの「本物の偽サイト」ですので、少し実験してみましょう。お客様番号等をでたらめな文字列にして、ログインボタンをタップしてみます。

「サーバーに接続中です。このまましばらくお待ち下さい」というダイアログが表示され、しばらくたった後、「入力に誤りがあります。」というダイアログが表示されます。

これは、攻撃者が、入力内容（お客様番号とログインパスワード）を用いて本物サイトにログインを試み失敗したためと考えられます。このように、裏で本物のサイトと中継する形式のフィッシングを中継型フィッシングと呼びます。

ログインパスワードを得るためだけであれば、中継型にする必要はないのですが、オンラインバンキングの多くはパスワードだけでは送金や出金はできず、追加の認証を求めるわけで、その追加の認証を突破する目的で行われます。

ちなみに、au自分銀行の場合は、スマホアプリかカード番号裏の乱数表が用いられますが、こちらのリリースで公表されている手口の場合は、以下を突破していると考えられます。

キャッシュカード暗証番号
キャッシュカードの裏面にある確認番号表の数字
お客さま携帯電話宛てに発行されたワンタイムパスワード

実際にどうなっているかは、本物の会員番号とパスワードを入力すればわかるのですが、さすがにそれはできないので、ここまででやめました。

おそらくは、冒頭に紹介した動画の手口かと思いますので、興味のある方は動画の方を御覧ください。

auじぶん銀行アプリに対する不正出金の驚くべき手口

フィッシングは恐ろしい手口であり、こちらの報道（アーカイブ）では、「警察庁によると、6、7月に同様の被害が全国で32件（約1060万円）確認されている」とあります。くれぐれもご注意下さい。また、中継型フィッシングを想定すると、二段階認証も突破される可能性が高いので、サイト運営者側もそれを想定した対策が求められます。

追記（2020年11月15日11:00）

今朝当該サイトにアクセスしてみたところ、DNSの設定が削除され、当該IPアドレスにもアクセスできない状態になっていました。関係者の皆様ありがとうございました。

PHPの脆弱性CVE-2018-17082はApacheの脆弱性CVE-2015-3183を修正したら発現するようになったというお話

2020-05-30T15:16:00.003+09:00

最近自宅引きこもりで時間ができたので、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-17082は発現しない（2019年以降 …これは当たり前）

これ自体はよくあることです。古いバージョンには脆弱性がなく、途中のバージョンで作り込まれたってことね。でもね、CVE-2018-17082はPHP 5.0.0にもあるんですよ。PHP 5.0.0が出たのは2004年ですからね。これだと辻褄が合わない。

試しに、自宅の環境のmodphpallを使ってPHP 5.0.0でCVE-2018-17082を試すとちゃんと発現するわけですよ。PHPのバージョンは関係ない。

で、次に、自宅の環境のCentOS/Debian/Ubuntuの各バージョン（パッチがまったくあたってないものとすべてのパッチがあたっているもの…LinuxAllという大げさな名前にしているのはくれぐれも内緒だ）で試すと、先の現象になるわけです。あまり古いと脆弱性のあるPHPバージョンなのに発現しない。CentOS6と7なんかひどくて、パッチのあたってない環境だと発現しないのに、すべてのパッチがあたっていると逆に発現する。
でも、ここにヒントがあると思ったわけですね。なぜって、CentOSはそもそもCVE-2018-17082のパッチは出してないわけですよ。ならば、PHP以外に影響があるに違いない。ひょっとすると、Apacheのバージョンが影響しているのかも。考えてみれば、そうだよね。だってCVE-2018-17082は、PHPのApache2handlerの脆弱性だから、相方のApacheの実装に影響を受ける可能性は十分にある。

なので、今度はApache 2.2と2.4のすべてのバージョンを導入した試験環境（1.3や2.0がないのにApacheAllという大げさな名前なのは内緒）で試したわけですよ。さいわい、リファレンス用としてPHP 5.3.3が入れてあるので、脆弱性が動くはずです。
でためしたら、やはり古いApacheだとCVE-2018-17082は発現しなくて、以下のバージョンだと発現する。

Apache 2.2.31以降
Apache 2.4.16以降

で、Apache 2.2.31で修正された脆弱性はなんだろう…と思って調べると、以下ですよ（これだけ）。

low: HTTP request smuggling attack against chunked request parser (CVE-2015-3183)

思わず息を呑みました（誇張じゃないよ）。出た、HRS。これだ。これに違いない。
ちなみに、CVE-2015-3183に対する修正はこちらでして、コミットメッセージに「Limit accepted chunk-size to 2^63-1 and be strict about chunk-ext」とあるように、巨大なチャンクサイズへの対応でしょうね。
でもね、皮肉な話じゃないですか。Apacheのあまり攻撃現実性がない脆弱性に対する修正の影響で、潜在的なPHPの脆弱性が顕在化して、こっちの方がはるかに攻撃の現実性があるわけですよ。別にApacheが悪い訳ではないですけどね。皮肉なもんだなーと思ったわけです。

ということで、全てが綺麗に説明がついたので、安心して動画制作に戻ろうと思います。
このように、私の動画は見えないところに手間をかけて制作していますんで、みんな見てくださいねー、よろしく!

徳丸浩のウェブセキュリティ講座

PHP 7.2以降におけるPDO::PARAM_INTの仕様変更

2020-03-27T14:24:00.000+09:00

サマリ

PHP 7.2以降、PDOの内部実装が変更された。動的プレースホルダ（エミュレーションOFF）にてバインド時にPDO::PARAM_INTを指定した場合、PHP 7.1までは文字列型としてバインドされていたが、PHP 7.2以降では整数型としてバインドされる。
この変更により、従来PDOが内包していた「暗黙の型変換」は解消される一方、integerへの暗黙のキャストにより、整数の最大値を超えた場合に不具合が発生する可能性がある。

この記事を読むのに必要な前提知識

この記事は、以前の記事（下記）の続編のような形になっています。

PDOのサンプルで数値をバインドする際にintにキャストしている理由

この記事では、PDOを用いたサンプルスクリプトでbindValue時にinteger型へのキャストを明示している理由を説明しています。パラメータを文字列として渡した場合、PDO::PARAM_INTにより整数型を指定しても、SQL文生成時に文字列リテラルとしてバインドされるため、「暗黙の型変換」により意図しない動作がおこり得ます。それを避けるために、値をintegerにキャストすることにより、SQL文には数値リテラルとして生成され、暗黙の型変換による不具合を避けることができます。一方、integer型へのキャストすると、整数の範囲を超えた場合にオーバーフローが起こる危険性があり、一長一短ではあります。

PHP 7.2での変更内容

PHP 7.2以降では、bindParamあるいはbindValue時にPDO::PARAM_INTを指定した場合、値はPHPのint型にキャストされます。ここで注意すべきことは、MySQLのINTではなく、PHPのinteger型にキャストされるため、32ビット環境では32ビット符号付き整数、64ビット環境では64ビット符号付き整数にキャストされ、その範囲を超えた場合はintegerの最小値あるいは最大値に変更されることです。

検証

検証のために、先のブログ記事と同じデータを用意します（再掲）。

CREATE TABLE xdecimal (id DECIMAL(20));   -- DECIMAL(20)は10進20桁の数値型
INSERT INTO xdecimal VALUES (18015376320243459);
INSERT INTO xdecimal VALUES (18015376320243460);
INSERT INTO xdecimal VALUES (18015376320243461);

PHPサンプルは下記のとおりですが、暗黙の型変換を起こすために、WHERE句で + 0を追加しています。

<?php
  $db = new PDO("mysql:host=127.0.0.1;dbname=test;charset=utf8", DBUSER, DBPASSWD);
  $ps = $db->prepare("SELECT id FROM xdecimal WHERE id = :id + 0");
  $id = '18015376320243461';
  $ps->bindValue(':id', $id, PDO::PARAM_INT); // intへのキャストはしない
  $ps->execute();
  $row = $ps->fetch();
  echo "$id->${row[0]}\n";

PHP 7.1.33で実行結果（32ビット環境、64ビット環境とも）

【実行結果】18015376320243461 -> 18015376320243459
【実行されるSQL文】SELECT id FROM xdecimal WHERE id = '18015376320243461' + 0

PHP 7.2.0での実行結果（64ビット環境）

【実行結果】18015376320243461 -> 18015376320243461
【実行されるSQL文】SELECT id FROM xdecimal WHERE id = 18015376320243461 + 0

PHP 7.2.0での実行結果（32ビット環境）

【実行結果】18015376320243461 ->
【実行されるSQL文】SELECT id FROM xdecimal WHERE id = 2147483647 + 0

端的な違いは、リテラルがシングルクォートで囲まれているか否か、すなわち、文字列リテラルか数値リテラルかです。PHP 7.2以降ではの変更、バインド時にPDO::PARAM_INTを指定した場合にバインド値が数値リテラルとして生成され、これはSQLの文法として本来の姿になったと考えます。これによる現実的なメリットは、文字列リテラルを数値に変換する際の「暗黙の型変換」が避けられ、正確な数値比較や演算が行えるようになったことです。

この変更による悪影響

PDO::PARAM_INT指定時に、値がいったんPHPのintegerにキャストされることから、integerの上下限を超えた値を指定した場合、強制的にPHP_INT_MAXまたはPHP_INT_MINに値が変更されます。具体例は、前述の「PHP 7.2.0での実行結果（32ビット環境）」を参照ください。integerの取りうる値の範囲は環境依存ですが、現在一般的な環境では以下のようになる場合が多いと思います。

32ビット環境: -2147483648 ～ 2147483647
64ビット環境: -9223372036854775808 ～ 9223372036854775807

PDOはどのように使えばよいか

今どき32ビット版のPHPを本番環境で使っている（かつPHP 7.2以降が動いている）環境はあまりないかもしれませんが、64ビット版であっても、数値の範囲について注意が必要です。PHP_INT_MAXを超える可能性がある値について、PDOはDecimal型のような型を指定する方法がないため、以下のように明示的なキャストを指定する方法などが考えられます。

$ps = $db->prepare("SELECT id FROM xdecimal WHERE id = CAST(:id AS DECIMAL(20))"); // 明示的な型変換
$ps->bindValue(':id', $id, PDO::PARAM_STR); // いったん文字列型でバインドして、CASTで明示的に型変換

まとめ

PHP 7.2におけるPDOの実装変更について紹介しました。この変更はドキュメント化されていないようで、かつ、PHP Internalsメーリングリストでも話題になっていないようです。もしドキュメント等を知っている方がおられたら教えてください。
この変更は非互換かつドキュメント化されていないものであるので、ひょっとすると手違いなどで変更された可能性もあると思っています。

SSRF対策としてAmazonから発表されたIMDSv2の効果と限界

2019-12-09T11:06:00.002+09:00

サマリ

Capital OneからのSSRF攻撃による大規模な情報漏えい等をうけて、Amazonはインスタンスメタデータに対する保護策としてInstance Metadata Service (IMDSv2) を発表した。本稿では、IMDSv2が生まれた背景、使い方、効果、限界を説明した上で、SSRF対策におけるIMDSv2の位置づけについて説明する。

SSRFとは

SSRFは、下図のように「外部から直接アクセスできないエンドポイント」に対して、公開サーバーなどを踏み台としてアクセスする攻撃方法です。SSRF(Server Side Request Forgery)の詳細については過去記事「SSRF(Server Side Request Forgery)徹底入門」を参照ください。

最終的な攻撃目標は多様ですが、近年問題になっているのが、クラウドサービスのインスタンス・メタデータを取得するAPIのエンドポイントです。有名なものがAmazon EC2の169.254.169.254(IMDS)ですが、類似の機能をクラウドサービス各社が提供しています。

cloud-service-metadata-api-list

先の記事でも紹介したSSRF脆弱なサンプルを以下に示します。これは、はてなブックマークのようなソーシャルブックマークアプリの「プレビュー機能」を想定しています。

<?php
  require_once('./htmlpurifier/library/HTMLPurifier.includes.php');
  $purifier = new HTMLPurifier();

  $ch = curl_init();
  $url = $_GET['url'];
  curl_setopt($ch, CURLOPT_URL, $url);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
  $html = curl_exec($ch);
  echo $purifier->purify($html);

このスクリプトをAmazon EC2上においてSSRF攻撃すると、下図のようにIAMのクレデンシャルが表示されます。

SSRF攻撃が一般の方にも話題になったのはCapital Oneからの1億人超の個人情報流出事件で、詳しくは以下の記事にまとめられています。

SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog

また、SSRF攻撃の標準的な対策は、ネットワーク的な対策で、EC2の場合は以下のようなiptablesによる防御が従来から推奨されていました。

sudo iptables --insert FORWARD 1 --in-interface docker+ --destination 169.254.169.254/32 --jump DROP
Amazon ECS コンテナインスタンスの IAM ロール - Amazon Elastic Container Service より引用

ここまでが長い前置き（前提知識の確認）です。

EC2インスタンスメタデータサービスv2(IMDSv2)とは

この状況に対して、Amazonが批判されたり、Amazonの責任ではないという反論があったりしていましたが、Amazonは今年の11月20日オフィシャルブログにて、Instance Metadata Service v2(IMDSv2) を発表しました。以下は、クラスメソッドの臼田さんのブログ記事から要点の引用です。

v2へのアクセスには事前に取得したTokenを必須とする

TokenはPUTで取得する必要がある
Tokenリクエスト時に有効期限(秒)を設定できる
Tokenはヘッダに入れてリクエストする必要がある

v1を無効化できる(デフォルトでは併用可能)
メタデータサービス自体を無効化できる

IMDSv2によるメタデータ取得は以下のようになります。まずは、トークンの取得

$ curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 60"
AQAAAKunSEcqfWQgz1E-ryJ3fdWDoOkbn8Nn4h2C6qN6nP56npog8Q==$

赤字のBASE64っぽいものがトークンです。TTLを60秒としているので、この値は既に無効です。PUTメソッドとX-aws-ec2-metadata-token-ttl-secondsヘッダを要求することで、攻撃難易度を上げています。
続いて、トークンを利用したメタデータの取得です。X-aws-ec2-metadata-tokenヘッダにより、先程取得したトークンを指定します。

$ curl -H "X-aws-ec2-metadata-token: AQAAAKunSEcqfWQgz1E-ryJ3fdWDoOkbn8Nn4h2C6qN6nP56npog8Q==" http://169.254.169.254/latest/meta-data/iam/info/
{
  "Code" : "Success",
  "LastUpdated" : "2019-12-08T02:32:19Z",
  "InstanceProfileArn" : "arn:aws:iam::999999999999:instance-profile/test-role",
  "InstanceProfileId" : "ZZZZZZZZZZZZZZZZZZZZZ"
}$

これだけだと、IMDSv1が有効になっているのでSSRF攻撃は緩和されません。IMDSv1を無効化するには、AWSCLIから以下のように --http-tokens を required に設定します。

$ aws ec2 modify-instance-metadata-options --instance-id i-FFFFFFFFFFFFFFF --http-tokens required --http-endpoint enabled
{
    "InstanceId": "i-FFFFFFFFFFFFFFFFF",
    "InstanceMetadataOptions": {
        "State": "pending",
        "HttpTokens": "required",
        "HttpPutResponseHopLimit": 1,
        "HttpEndpoint": "enabled"
    }
}
$

この状態で先の攻撃をすると、以下のように攻撃は防御されます。

SSRF攻撃の文脈でPUTメソッドやカスタムHTTPリクエストヘッダを指定することは難しそうなので、「これだけでSSRF対策は十分ではないか」と思う人もいそうですが、実は攻撃は可能です。

Gopherプロトコルとは

以前からSSRF界隈ではGopherプロトコルの活用が話題となっていて、はせがわようすけさんが分かりやすいスライドで紹介されています。

SSRF基礎 - Speaker Deck

このスライドの12ページからがGopherを用いた攻撃手法についての説明です…が、このスライドは今年の9月18日の講演のものですので、当時存在しなかったIMDSv2についての言及はありません。このため、はせがわさんのスライドを引き継ぐ形で、GopherによるIMDSv2への攻撃を紹介します。

まず、Gopher自体の紹介はこちらの記事などを参照していただくとして、ここではcurlとnetcatによりgopherプロトコルを簡単に試してみます。

まずはcurlコマンドにより以下のURLをアクセスしてみます。

$ curl gopher://localhost:8888/_Hello%0d%0aHiroshi%20Tokumaru%0d%0a

curlコマンド実行前にnetcatで8888ポートを待ち受けていると、以下のような表示になります。

$ nc -l 8888
Hello
Hiroshi Tokumaru

Response           ← この行はResponse 改行 Ctrl-d を手入力したもの
$

この際の呼び出し側は下記となります。

$ curl gopher://localhost:8888/_Hello%0d%0aHiroshi%20Tokumaru%0d%0a
Response
$

このように、Gopherプロトコルを使うと、任意リクエストをURLで指定でき、そのレスポンスを受け取れることから、HTTPやSMTPその他のプロトコルをエミュレートできることになります。

Gopherプロトコルを用いたIMDSv2に対する攻撃

先程のサンプルプログラムをEC2のIMDSv1を無効化した環境に設置した状態で、Gopherプロトコルを用いて攻撃してみましょう。まずはPUTメソッドによるトークン取り出しです。表示が見やすいようにHTMLソースの形で表示しています。アドレスバーには gopher://169.254.169.254:80/_PUT というURLがちらっと見えていますね。

このトークン（有効時間は60秒…もっと長くすることも可能）を用いて、メタデータを表示させた結果が下記です。

このように、IMDSv1を無効化してIMDSv2のみ有効としても、Gopherプロトコルを用いてSSRF攻撃ができました。

リダイレクトを許可している場合

今までの「脆弱なスクリプト」は、与えられたURLに対してスキーム（プロトコル）もホストのIPアドレスもチェックしていなかったので、これらのチェックを追加してみましょう。これだけだと防御できて当然なので、cURLのオプションとしてCURLOPT_FOLLOWLOCATIONをtrueにします。これは、リダイレクトをcURL内部で自動的に追跡するという意味です。

<?php
  require_once('./htmlpurifier/library/HTMLPurifier.includes.php');
  $purifier = new HTMLPurifier();

  $ch = curl_init();
  $url = $_GET['url'];
  $urlinfo = parse_url($url);  // URLのパース
  $scheme = $urlinfo['scheme'];
  $host = $urlinfo['host'];
  $ip = gethostbyname($host);
  if ($ip === "169.254.169.254") {  // IPアドレスのチェック
    die("Invalid host");
  } elseif ($scheme !== 'http' && $scheme !== 'https') { // スキームのチェック
    die("Invalid scheme");
  }
  curl_setopt($ch, CURLOPT_URL, $url);
  curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);  // リダイレクトを自動追跡
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

  $html = curl_exec($ch);
  echo $purifier->purify($html);

このスクリプトに対して、リダイレクトを用いた攻撃をします。具体的には下記のスクリプト（リダイレクタ）のURLをサンプルスクリプトに指定します。

<?php
  header('Location: gopher://169.254.169.254:80/_PUT%20/latest/api/token...以下悪用防止のため略

実行結果は以下となり、トークンを取得できていることがわかります。

同様に、このトークンを使用してEC2インスタンスのメタデータを取得することができます。

※ はせがわさんのスライドでは、この攻撃にはスクリプト側で明示的に任意プロトコルへのリダイレクトが許可されている必要があるように読めます（P23）が、私が実験により確認した範囲では、任意プロトコルの明示的な許可は必要ないようです。

対策

上記攻撃には以下の対策候補が考えられます。

curlで扱うプロトコルをHTTPおよびHTTPSに限定（常に指定を推奨）

curl_setopt($ch, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS);

リダイレクトの追跡を禁止する（curlのデフォルトに戻す、あるいは以下を設定）

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false);  // リダイレクト追跡しない

CURLINFO_PRIMARY_IPにより「実際にアクセスしたIPアドレス」を求め、169.254.169.254（等ブラックリストのIPアドレス）であれば表示をやめる

$primary_ip = curl_getinfo($ch, CURLINFO_PRIMARY_IP);

URLからホスト名に対応するIPアドレスとスキームを確認する（先のスクリプトでは実施済み）

結局どうすればよいか

IMDSv2はそもそもAmazonからもインスタンスメタデータに対する defense in depth （多層防御）と紹介されており、根本的な解決策ではありません。なので、他の根本的な解決策を実施した上で、予防的な対策（緩和策）として用いるべきです。
では、根本的な解決策はなにかというと、インスタンスメタデータの保護という点では、先に紹介したiptables等を用いたネットワーク的な対策が確実です。あるいは、以下により、HTTPによるインスタンスメタデータ参照そのものを禁止することも有効です。

$aws ec2 modify-instance-metadata-options --instance-id i-FFFFFFFFFFFFFFFF --http-endpoint disabled
{
    "InstanceId": "i-FFFFFFFFFFFFFFFFF",
    "InstanceMetadataOptions": {
        "State": "pending",
        "HttpTokens": "required",
        "HttpPutResponseHopLimit": 1,
        "HttpEndpoint": "disabled"
    }
}

ただし、上記はインスタンスメタデータに対する保護であり、SSRF攻撃全般を防御できるわけではないため、他に守るべきエンドポイントがある場合には他の対策を併用する必要があります。

まとめ

Instance Metadata Service v2 (IMDSv2) について紹介しました。IMDSv2を用いることにより、SSRF攻撃をかなり緩和されることが期待できるものの、根本的な解決策ではなく緩和策の一つとして用いるべきと考えます。これは、Amazon自体がIMDSv2をdefense in depth（多層防御）とうたっていることからも伺えます。
また、SSRF攻撃の対策は難易度が高いため、可能であればSSRF攻撃の影響を受けない仕様（例えば外部から受け取ったURLにアクセスしない）の検討を推奨します。

シェルを経由しないOSコマンド呼び出しがPHP7.4で実装された

2019-12-05T17:54:00.000+09:00

この記事はPHP Advent Calendar 2019の5日目の記事です。

はじめに

私は6年前に、PHP Advent Calendar 2013として「PHPだってシェル経由でないコマンド呼び出し機能が欲しい」という記事を書きました。その中で、OSコマンドインジェクション対策の根本的かつ安全な対策は「シェルを経由しないコマンド呼び出し」であることを指摘した上で、末尾に以下のように書きました。

PHPコミッタのみなさま、PHP5.6の新機能として、シェルを経由しないコマンド呼び出しの機能を追加できませんか?

現実には当時からPCNTL関数にてシェルを経由しないコマンド呼び出しはできたのですが、当関数の使用が難しいことと、CLI版あるいはCGI版（FastCGIは可）のPHPでないとサポートされていないなどの制限があり、popenやproc_openなど使いやすいコマンド呼び出し関数において、シェル呼び出しのないコマンド実行機能が欲しいところでした。

この「私の願い」はPHP 5.6では実現しませんでしたが、PHP 7.4においてproc_open関数の拡張として実現しました。実に6年越しの実現ということになります。

proc_openの従来の問題点

proc_openに限りませんが、PHPの従来のコマンド実行機能（PCNTL関数は例外）の問題として、「常にシェル経由でコマンドを呼び出す」ことがあります。これを確認するための簡単なサンプルを示します。以下は、ps -fコマンドをproc_open関数で呼び出しています。

<?php
$cmd = "ps -f";
$process = proc_open($cmd, [], $pipes);
if (is_resource($process)) {
    $return_value = proc_close($process);
    echo "command returned $return_value\n";
}

呼び出し例は下記となります。赤字で示しているように、シェル（/bin/sh）経由でpsコマンドが実行されています。

UID        PID  PPID  C STIME TTY          TIME CMD
ockeghem 16921 16920  0 16:31 pts/0    00:00:00 -bash
ockeghem 18858 16921  0 17:18 pts/0    00:00:00 php-7.4.0 proc_open4.php
ockeghem 18859 18858  0 17:18 pts/0    00:00:00 sh -c ps -f
ockeghem 18860 18859  0 17:18 pts/0    00:00:00 ps -f
command returned 0

このため、コマンドラインにセミコロンなどにより追加のコマンドを実行できる可能性があり、OSコマンドインジェクション脆弱性の原因になっていました。ここで、psのオプションとして、-fの代わりに、「-f; echo Hello」を指定してみましょう。

<?php
$cmd = "ps -f; echo Hello";
$process = proc_open($cmd, [], $pipes);
// 以下省略

呼び出し例は下記となります。sh -c のパラメータとして; echo Helloが追加されていることと、echoコマンドの実行結果としてHelloが表示されていることがわかります。これがOSコマンドインジェクションの原理です。

UID        PID  PPID  C STIME TTY          TIME CMD
ockeghem 16921 16920  0 16:31 pts/0    00:00:00 -bash
ockeghem 18932 16921  0 17:30 pts/0    00:00:00 php-7.4.0 proc_open4.php
ockeghem 18933 18932  0 17:30 pts/0    00:00:00 sh -c ps -f; echo Hello
ockeghem 18934 18933  0 17:30 pts/0    00:00:00 ps -f
Hello
command returned 0

この対策として、コマンドラインのパラメータをエスケープ処理する方法もありますが、エスケープ処理自体が複雑になる可能性があり、実際にPHPのescapeshellcmd関数には脆弱性（こちらを参照）があるため使用を避けるべき状態でした。

proc_openのPHP 7.4での新しい呼び出し方

この状況に対して、PHP 7.4では、proc_openの第1引数を配列として指定することにより、コマンドとパラメータを明確に分離するとともに、シェルを経由しないコマンド実行ができるようになりました（パチパチパチ）。
先のスクリプトをこの形式で書き換えてみましょう。

<?php
$cmd = ["ps", "-f"];
$process = proc_open($cmd, [], $pipes);
if (is_resource($process)) {
    $return_value = proc_close($process);
    echo "command returned $return_value\n";
}

実行例は以下となります。シェルを経由せずに直接コマンドが実行されていることがわかります。

UID        PID  PPID  C STIME TTY          TIME CMD
ockeghem 16921 16920  0 16:31 pts/0    00:00:00 -bash
ockeghem 18895 16921  0 17:27 pts/0    00:00:00 php-7.4.0 proc_open4.php
ockeghem 18896 18895  0 17:27 pts/0    00:00:00 ps -f
command returned 0

続いて、先程同様に、-f オプションの代わりに -f; echo Hello を指定してみましょう。

<?php
$cmd = ["ps", "-f; echo Hello"];
$process = proc_open($cmd, [], $pipes);
// 以下略

実行結果は以下のとおりです。psコマンドにオプションとして「-f; echo Hello」が渡されたため、「unsupported SysV option」というエラーになっていますが、OSコマンドインジェクションにはならないことがわかります。

error: unsupported SysV option

Usage:
 ps [options]

 Try 'ps --help <simple all="" list="" misc="" output="" threads="">'
  or 'ps --help <s a="" l="" m="" o="" t="">'
 for additional help text.

For more details see ps(1).
command returned 1

この呼出方法（proc_openの第一引数を配列で指定）の場合、シェルを経由しないでコマンドを呼び出すことから、原理的にOSコマンドインジェクション脆弱性を避けることができます。今後PHP 7.4以降にて外部コマンドを呼び出す場合は常に、proc_open関数にて第1引数を配列で指定し、かつ配列の先頭要素（コマンド名）は固定とすることで、OSコマンドインジェクションを避けつつ簡便かつ安全な実装が可能になります。

まとめ

PHP 7.4にて新たに追加されたproc_openの新しい呼び出し方を紹介しました。私個人としても、6年越しの要望がかなえられた結果となり、よいクリスマスを迎えられそうです。

PHPサーバーサイドプログラミングパーフェクトマスターのCSRF対策に脆弱性

2019-07-29T12:51:00.000+09:00

サマリ

PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。

はじめに

古庄親方の以下のツイートを見て驚きました。

CSRF用のトークンの作成
＄token = password_hash(mt_rand(), PASSWORD_DEFAULT);
ってのを書籍で見た………もンのすンげぇなぁ(苦笑
書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。
— がる (@gallu) July 17, 2019

CSRFトークンの生成に、password_hash関数を使うですと?
親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PHPサーバーサイドプログラミングパーフェクトマスター」です。同書では、CSRF対策にpassword_hashを2種類の方法で使っています(!)が、本稿では、セクション10.3 (P726～) にて説明されている方法を取り上げます。

当該コード

当該コードを示します。同書では、認証・入力フォーム・登録の3機能が1つのPHPファイルにまとめられていますが、そこから抜き出す形で、以下は入力フォームです。

<?php
function getToken($rand='') {
    $_SESSION['rand'] = $rand;
    $token = password_hash($rand, PASSWORD_DEFAULT);
    return $token;
}
// セッションスタート
session_start();
$rand = mt_rand();
$token = getToken($rand);
print <<<EOD
<form action="" method="post">
<input type="hidden" name="request" value="reg" />
<input type="hidden" name="token" value="$token" />
<input type="submit" value="登録">
</form>
EOD;

トークンの「素（もと）」としてmt_rand()関数が呼ばれ、その値をセッション変数$_SESSION['rand']に保存しています。その乱数値をpassword_hash関数で処理することで、トークンを生成しています。入力フォームの生成例を以下に示します。

<form action="" method="post">
<input type="hidden" name="request" value="reg" />
<input type="hidden" name="token"
  value="$2y$10$alqDLwZSizuBYpwmBR6pj.WzxI7UeW9YutuxHjb.r2qw9QQOBqbw6" />
<input type="submit" value="登録">
</form>

赤字に示した部分（$2y$...）がトークンですが、これを見ると、「なんでパスワードのハッシュ値をCSRFトークンにしているわけ?」と勘違いする人が続出しそうですね。
そして、このトークンを受け取り、処理するプログラムが下記の部分です。

<?php
function check ($token = '') {
    return (password_verify($_SESSION['rand'], $token));
}
session_start();
if (isset($_POST['request']) === true && $_POST['request'] === 'reg' && isUser() == true) {
    if(isset($_POST['token']) === false || check($_POST['token']) === false) {
        print '不正なアクセスが行われました。';
    } else {
        print '処理が完了しました！';
        unset($_SESSION['rand']);
        $_SESSION = array();
    }

}

$_POST['token']がNULLでないことを確認した上で、check関数で、セッション変数$_SESSION['rand']をパスワードに見立て、パスワードのハッシュ値に相当する$_POST['token']にてpassword_verify関数で照合する形で、トークンを検証しています。

何が問題か

このプログラムには以下の問題があります。

設計上の問題
実装上の問題

以下、順に説明します。

設計上の問題

そもそもpassword_hash関数は、パスワードを安全に保存するための関数なので、CSRFトークンの処理のことはまったく考慮されておらず、一言で言えば「使う場所を間違えている」ことになります。通常トークンの生成には、暗号論的に安全な疑似乱数生成器（CSPRNG）を用います。PHP 7以降ではrandom_bytes関数があるので(*1)、それを素直に使うだけです。さらにハッシュ関数を通すようなことは必要ありません。余計なことをやればやるほど、バグの原因になり、ひいては脆弱性の原因になります。

（追記 2019/7/29 20:36）
*1 当書籍はXAMPP上のPHP5.5を前提としているので、random_bytes関数（PHP 7.0以降）は使えませんが、代わりにopenssl_random_pseudo_bytes関数（PHP 5.3以降）が使えます。当関数はopensslの導入が前提ですが、XAMPPはデフォルトでopenssl関数が使用できます。
（追記終わり）

加えて、mt_rand()の使用も問題です。この関数は、マニュアル（下記引用）にある通り、セキュリティ目的で使うことは適切でありません。

警告この関数が生成する値は、暗号学的に安全ではありません。そのため、これを暗号として使ってはいけません。暗号学的に安全な値が必要な場合は、random_int() か random_bytes() あるいは openssl_random_pseudo_bytes() を使いましょう。

https://php.net/manual/ja/function.mt-rand.php より引用

また、mt_rand関数を引きなしで呼び出すと、0からmt_getrandmax()の戻り値までの値を返しますが、mt_getrandmax()は64ビット環境でも2147483647なので、31ビットの範囲になります。これはトークンに用いる乱数のエントロピーとしては不足しています。
さらに、password_hash関数はパスワードの保護を強化するためにストレッチング（ハッシュ計算を繰り返すこと）を施していますが、そのために、password_hashおよびpassword_verify関数は非常に低速です。CSRF対策のために、わざわざ処理を遅くする必要はありません。

実装上の問題

紹介したプログラムには実装上の問題もあります。使われているトークンはワンタイムのものであり、使用済みになるとunsetされます。すなわち、トークンがNULLとなる時期が存在します。そのタイミングを狙った攻撃ができるのです。
すなわち、以下の関数呼び出しがtrueになるような$tokenを渡せばよいことになりますが…

password_verify(NULL, $token)

実は、password_verifyの第一引数にNULLを渡すと、空文字列を渡したのと同じ結果になります。なので、空文字列に対するpassword_hash関数の結果を使って、攻撃が可能です。空文字列に対するハッシュ値はソルトにより無数に存在しますが、たとえば以下で攻撃ができます。

$2y$10$V3V9iX2iR6ZqaNuFAyUlPeiIvmQrGKDbrJQWdkXWVECGUodZON0Iu

検証例を示します。

<?php
var_dump(password_verify(null, '$2y$10$V3V9iX2iR6ZqaNuFAyUlPeiIvmQrGKDbrJQWdkXWVECGUodZON0Iu'));

// bool(true) が表示される

これは、前述した「余計なことをやればやるほど、バグの原因になり、ひいては脆弱性の原因にな」った例といえます。

まとめ

PHPサーバーサイドプログラミングパーフェクトマスターにおけるCSRF対策の問題を報告しました。実務上でCSRF対策をする場合は、アプリケーションフレームワークの機能を使うか、よく検証されたライブラリを使うべきですが、特別な事情があって独自実装する場合には、定石的な手法を用い、かつできるだけ簡素な、検証のしやすい実装にすべきと考えます。
また、password_hash関数をトークン生成に用いる例が、同書に限らず散見されますが、これは百害あって一利なしですので、トークン生成には単にCSPRNGを使うと覚えておきましょう。

PHPカンファレンス福岡2019のSST社ブースにてPHPクイズ出題を担当しました

2019-07-01T10:31:00.002+09:00

PHPカンファレンス福岡2019のセキュアスカイテクノロジー（SST）社ブースにて、PHPクイズの出題を担当しました。以下は、そのパネルのイメージです。SST社は弊社EGセキュアソリューションズ株式会社のパートナー企業で、私はSST社のEラーラニングコンテンツ（PHP編）の監修を担当しています。

問題はすべて2択で、回答は下の写真のように、赤または青のシールをボードに貼り付ける形になっています。回答がわりとバラけていて、出題者的にはいい感じですね。

以下、出題と解答、解説を記載します。

問題1

以下のPHPスクリプトで、クッキーPHPSESSIDの削除として機能するのはどちら?
PHPのバージョンは7.3.6とする。

A) （正解）31人が選択=正答率 83.8%

<?php
setcookie('PHPSESSID');

B) 6人が選択

<?php
header('Set-Cookie: PHPSESSID=');

解説

setcookie関数の第2引数の省略時の値は '' （空文字列）ですので、A)は setcookie('PHPSESSID', ''); としたのと同じはずです。そして、第2引数が空文字列の場合は、実際にはクッキーの値としてdeletedが指定され、expires属性が過去日時(PHP-7.3.6の場合は、Thu, 01-Jan-1970 00:00:01 GMT)になります。すなわち、setcookie関数の第2引数を省略すると、クッキーの削除として機能します。
B) header関数の方は、クッキーの値が空文字列になりますが、クッキーそのものは削除されません。

参考記事: PHPのsetcookie関数で空文字列を設定しようとするとクッキーが削除される

ところが、出題の確認時にmodphpallで確認したところ、古いPHPでは上記の挙動にはならず、以下のレスポンスヘッダが送信されることがわかりました。この動作は、setcookie関数の第2引数を省略した場合のみで、空文字列またはnullを指定した場合はマニュアルどおりの動作となります。

Set-Cookie: PHPSESSID=

正確に言えば、PHP 4.1.0～PHP 5.6.13までが上記挙動になります。すべてのPHP 4.0と PHP 5.6.14以降、PHP 7以降では、マニュアルどおりの動作となります。この変更は、恐らく以下のバグレポートに対応したものと思われます。

Bug #67131 setcookie() conditional for empty values not met

プログラミング言語のエッジケースの出題をする場合は特に、実環境での動作確認と、処理系の想定バージョンの明記が重要だなとあらためて感じました。

問題2

以下のPHPスクリプトはどちらが表示される? PHPのバージョンは7.3.6とする。

<?php
   $mail = "a@[email protected]";
   var_dump(filter_var($mail, FILTER_SANITIZE_EMAIL));

A) 31人が選択
bool(false)

B) （正解）6人が選択=正答率 16.2%
string(14) "a@[email protected]"

解説

この問題は「ひっかけ」でして、実際に多くの方がひっかかりました。
マニュアルにあるように、filter_var関数に FILTER_SANITIZE_EMAIL を指定した場合は、英字、数字および !#$%&'*+-=?^_`{|}~@.[] 以外のすべての文字を取り除きます。出題の場合は、除去対象の文字がないので、入力値がそのまま出力されます。
メールアドレスの形式を検証するためには、FILTER_SANITIZE_EMAIL ではなく、FILTER_VALIDATE_EMAIL を使用します。

率直に言って、FILTER_SANITIZE_EMAILのユースケースは思いつきません。要らんでしょ、こんなもの。

問題3(PHP考古学)

PHP-5.2.17にてregister_globals=onの環境で、あらかじめ以下のようにセッション変数が設定されている。

$_SESSION['user'] = 'yamada';

クエリ文字列 user=tanaka
を指定して以下のスクリプトを実行した場合の表示はどちら?

<?php
   session_start();
   echo $user;

A)yamada (正解) 23人が選択=正答率 62.2%
B)tanaka 14人が選択

解説

register_globals=on の環境では、session_start()を実行時にセッション変数の値がグローバル変数として初期設定されます。したがって、$_SESSION['user'] = 'yamada'; が設定されている場合、$user の初期値は 'yamada' になります。
仮に、このセッション変数がセットされていない場合、クエリ文字列 user=tanaka の方が使われ、$user の初期値は 'tanaka' になります。セッション変数とクエリ文字列（やPOST変数など）の両方に同じパラメータ名がある場合、セッション変数の方が優先されます。その理由は、セッション変数のグローバル変数へのセットは、起動時ではなく、session_start()の実行時に行われるからです。すなわち、同名のパラメータがあった場合は、セッション変数が上書きします。
したがって、register_globals=on の使用は脆弱性の原因になりやすいことはよく知られていますが、セッション変数をグローバル変数の初期値として用いると、特に脆弱性が混入しやすくなります。

例えば、以下のログインチェックのプログラムについて

session_start();
if (! isset($_SESSION['user']) {
  die('ログインしてください');
}
$user = $_SESSION['user'];

これを register_globals=on を想定して「直訳」すると以下のようになります。

session_start();
if (! isset($user)) {
   die('ログインしてください');
}
// $user = $_SESSION['user'];  // これは不要となる

register_globals=on の場合、session_start()を実行した時点で、セッション変数 $_SESSION['user'] の値はグローバル変数 $user にセットされるため、「これは不要となる」とコメントした行は不要となります。便利ですね!
しかし、$_SESSION['user'] がない場合、$user=nullが実行されるわけではないので、クエリ文字列等にuser=tanakaがあった場合、$userには 'tanaka' がセットされます。すなわち、パスワードを知らなくても誰にでもなりすましできます。これは重大な問題ですね。
register_globals=on を用いて、上記の脆弱性を修正するには以下のように書くべきですが…

$user = null;  // register_globals=onによる初期設定を無効化する
session_start();
// $_SESSION['user'] がある場合、$userにその値がセットされる
if (! isset($user)) {
  die('ログインしてください');
}

上記は著しく直感に反するプログラムですし、それゆえに初期化漏れが盛大に発生しそうです。なので、register_globalsがPHP 5.4で削除されたのは、必然のことと言えましょう。

[PR]
徳丸が代表を務めるEGセキュアソリューションズ株式会社では、ウェブサイトを堅牢にするための各種セキュリティサービスを提供しています。

2019年1月から5月に公表されたウェブサイトからのクレジットカード情報漏えい事件まとめ

2019-05-30T13:37:00.000+09:00

株式会社ヤマダ電機の運営するECサイトから、最大37,832件のクレジットカード情報が漏洩したと昨日発表されました。ヤマダ電機のように日本を代表する家電量販店のサイトからクレジットカード情報が漏洩したことに私自身驚きました。

弊社が運営する「ヤマダウエブコム・ヤマダモール」への不正アクセスによる個人情報流出に関するお詫びとお知らせ

漏洩した情報は以下のように発表されています。

クレジットカード番号
有効期限
セキュリティコード

はてなブックマークやtwitterのコメントを見ていると、「セキュリティコードを保存していたのか」という意見が見えますが、おそらくセキュリティコードは保存されていなかったと推測します。
本稿では、この件を含め、本年の現時点までのウェブサイトからのクレジットカード情報漏えい事件についてまとめました。

事件の一覧

下表に本年(2019年)の現時点までに公表されたウェブサイトからのクレジットカード情報漏洩事件をまとめました。サイト名、漏洩期間、漏洩件数（最大）、セキュリティコードの漏洩有無、漏洩の手口（後述）を記載しています。

サイト名	漏洩期間	漏洩件数	セキュリティコード	漏洩手口
バニーファミリー横浜ネットショップ	2018年6月28日～同年10月25日	241件	漏洩	Type5
オンライン通販サイト（ハセ・プロ）	2018年10月1日～2019年1月24日	1,311件	漏洩	Type5
歯学書ドットコム	2012年11月11日～2018年12月28日	5,689件	漏洩	不明
本味主義	2017年5月22日～2018年10月14日	2,926件	漏洩	Type4?
子供服サーカス	2018年10月1日～2019年1月18日	2,200件	漏洩	Type4
エコレオンラインショップ	2018年5月16日～2018年12月11日	247件	漏洩	Type4
ななつ星 Gallery	2013年10月5日(サイト開設日)～ 2019年3月11日（サイト閉鎖日）	3,086件	漏洩	不明
「ショコラベルアメール」オンラインショップ	2018年8月6日～2019年1月21日	1,045件	漏洩	Type5
エーデルワインオンラインショップ	2015年7月8日～2018年8月5日	1,140件	漏洩	不明
小田垣商店オンラインショップ	2018年4月3日～2018年5月16日及び 2018年9月3日～2019年2月28日	2,415件	漏洩	不明
藤い屋オンラインショップ	2018年10月15日～2019年1月28日	477件		Type5
エンターテインメントホビーショップ　ジャングル	2017年5月2日～2018年11月6日	2,507件	漏洩	Type2
ヤマダウエブコム・ヤマダモール	2019年3月18日～2019年4月26日	37,832件	漏洩	Type4

大半の事件でセキュリティコードが漏洩している

上表からわかるように、藤い屋オンラインショップを除いたすべての事件でセキュリティコードが漏洩しています。昨年のまとめも見ていただくとわかりますが、最近のウェブサイトからのクレジットカード情報漏洩では、セキュリティコードが漏洩する方がむしろ普通です。
昨年10月のブログ記事「クレジットカード情報盗み出しの手口をまとめた」では、クレジットカード情報を窃取する手口をType1～Type5にまとめましたが、この中で、Type4とType5はセキュリティコードを容易に盗むことができます。

Type4の手口とは

ここでType4の手口について説明します。下図のように、カード情報入力画面に細工を施すことがType4の特徴です。

下図はサイト利用者がクレジットカード情報を入力している様子です。入力フォームに仕掛けられたJavaScriptにより、カード情報は攻撃者の管理するサーバーに送信されています。

ヤマダ電機のサイトからの情報漏えいがこのパターンと推測する理由は、リリースの以下の記述からです。

(1)原因
第三者によって「ヤマダウエブコム・ヤマダモール」に不正アクセスされ、ペイメントアプリケーションの改ざんが行われたため
弊社が運営する「ヤマダウエブコム・ヤマダモール」への不正アクセスによる個人情報流出に関するお詫びとお知らせより引用

そして、同じくType4と推測されるサイトとしては下記があります。

Q.子供服サーカス、および子供服ミリバールからクレジットカード情報が流出したのですか？
弊社ではカード情報を保有しておりません。今回は、注文情報入力画面が不正アクセスにより改竄され、カード入力画面で入力されたお客様のカード情報が、流出したと思われます。
【Q&A】クレジットカード情報流出に関するご質問と回答（株式会社サーカス）より引用

2018 年5 月16 日に攻撃者が、データベースへ不正な仕掛けをページ内に埋め込んだとみられます。
その仕掛けは、ページ内の入力フォームに入力されたカード会員情報を正規の処理とは別に外部サイトへ転送する機能を持っていた為、2018年5月16日以降当該サイトのカード利用者のカード会員情報が搾取されていたと考えられる、との事でした。
エコレ通販サイトにおける不正アクセスによるお客さま情報の流出懸念に関するお知らせより引用

Type5の手口も依然活発

一方、昨年から使われた始めたType5も依然として活発です。下図は、バニーファミリー横浜のFAQからの引用です。

【重要】カード情報流出についての、ご質問とご回答バニーファミリー横浜公式オンラインショップより引用

そして、下図が攻撃後の画面遷移で、「偽のカード入力画面」が画面遷移に挿入されています。

【重要】カード情報流出についての、ご質問とご回答バニーファミリー横浜公式オンラインショップより引用

この遷移は、「2018年に公表されたウェブサイトからのクレジットカード情報漏えい事件まとめ」で紹介した伊織の事例と酷似しており、偽画面のドメイン名まで同じです。同一犯人、あるいは同一犯行グループではないでしょうか。

また、以下のように、ハセ・プロ、ショコラベルアメール、藤い屋についてもこの手口であることがリリースからわかります。

フィッシングサイトによるクレジットカード情報不正取得についてのお詫びと注意喚起のお知らせ（株式会社ハセ・プロ）より引用

「ショコラベルアメール」のオンラインショップへの不正アクセスに関するご質問と回答より引用

２０１８年１０月１５日から２０１９年１月２８日までの期間においてシステムが改ざんされた痕跡があり、クレジットカード決済を選択されたお客様が偽の決済画面へ誘導され、そこで入力されたクレジットカード情報が流出し、一部のお客様のクレジットカード情報が不正利用された可能性があることを確認いたしました。
弊社が運営する「藤い屋オンラインショップ」への不正アクセスによる個人情報流出に関するお詫びとお知らせより引用

なぜ入力フォームからクレジットカード情報を盗むのか

ブログ記事「ECサイトからクレジットカード情報を盗み出す新たな手口」にて紹介したように、昨年の6月1日に改正割賦販売法が施行され、クレジットカード情報を扱うECサイト事業者にもカード情報保護が求められるようになりました。そして、この保護についてのガイドラインになるのが、『クレジット取引セキュリティ協議会の「実行計画」』であり、中身はクレジットカード情報番号の非保持化が柱になっています。
具体的には、以下に示す「JavaScript（トークン）型」と「リダイレクト（リンク）型」による決済システムが推進されています。
以下は、JavaScript型の決済の様子です。入力フォームは加盟店（ECサイト）側にありますが、カード情報はECサイトのサーバーを通過せず、JavaScriptにより直接決済代行事業者にカード情報を送信する方式です。

実行計画2019 より引用

JavaScript型の場合、先に説明したType4およびType5でカード情報を盗むことができます。
一方下図はリダイレクト型決済の概念図です。カード情報を入力する際には、決済代行事業者の画面に遷移するため、ECサイト側では一切生のカード情報を扱わず、安全性が高い方法と考えられていました。

実行計画2019 より引用

しかし、前記Type5の攻撃ではリダイレクト型決済でもカード情報を盗むことができます。今年のカード情報窃取事件ではType4とType5が使い分けられていますが、これは決済方式に合わせて適した方法が採用されたものと考えられます。

カード情報非保持化で満足せず基本的な対策を

以上で説明してきたように、経産省およびクレジット取引セキュリティ協議会の進める「カード情報非保持化」では十分にカード情報を保護できる状況ではありません。基本に立ち返って、以下の対策を推奨します（2018年末の記事の再掲）。

ウェブアプリケーションやソフトウェアライブラリ、プラットフォームの脆弱性対策（パッチ適用など）
管理者等のパスワードを強固にする（可能ならばインターネットからは管理者ログインできないよう設定する）

加えて、以下の対策を推奨します。

Web Application Firewall(WAF)の導入
ファイルパーミッションとファイルオーナーの適切な設定
改ざん検知システムの導入

[PR]
徳丸が代表を務めるEGセキュアソリューションズ株式会社では、ECサイトを堅牢にするための各種セキュリティサービスを提供しています。

[書評]噂の学園一美少女な先輩がモブの俺に惚れてるって、これなんのバグですか?

2019-05-07T12:15:00.000+09:00

瓜生聖（うりゅうせい）の近著「噂の学園一美少女な先輩がモブの俺に惚れてるって、これなんのバグですか? 」を読んだので紹介したい。本書は、JNSA（特定非営利活動法人日本ネットワークセキュリティ協会）が主催したサイバーセキュリティ小説コンテストにて大賞を受賞した作品「目つきの悪い女が眼鏡をかけたら美少女だった件」を大幅に加筆したのち、角川スニーカー文庫から出版された。

重要事項説明

著者と評者は知人関係にあり公私共に交流がある
評者が読んだ書籍はご恵贈いただいたものである
この記事のリンクにはアフィリエイトが含まれる

はじめに

著者の瓜生聖は、twitterのプロフィールには「ITmediaで記事を書いてる兼業ライター」とあるが、本業はITエンジニアである。つまり、現役のITエンジニア兼テクニカルライターである人物が、サイバーセキュリティ小説を書いたのが本書ということになる。瓜生聖はライターとしても一流なので技術面と文章力は申し分ないはずだが、小説となるとどうだろうか。評者の興味は、まずそこにあった。

あらすじ

本書は以下の三部構成となっている。

第一話　試験問題漏洩事件

本書の準ヒロイン格で、主人公鷹野祐（たかのたすく）の幼なじみの西村理乃（にしむらりの）が、数学の試験問題漏洩事件の犯人だという噂が流れ、事件が提示される。祐は、美少女衣川マト（ころもがわまと）の力を借りて事件の真相を解明し、理乃を救う。祐は小学生時代に探偵を志していたが、とある事件がトラウマになり、探偵の夢をあきらめていたが、この事件をきっかけに、自分が進むべき道がおぼろげながら見えてくる。

第二話　夏の嵐

祐は区民プールで子供たちと遊ぶマトを見かけ、そこからの流れでマトが幼少期を過ごした施設を訪問、マトの過去を知ることになる。その後マトの自宅を訪問しドキドキの一時を過ごす。
台風の日、買い物を言いつけられた祐は自宅に帰ることができなくなり、愛帝学園を訪れる。そこで第二の事件を解決する。過程で、サイバーセキュリティに詳しい青年鴻上（こうがみ）が登場する。

第三話　最強の武器

マトが高校に来なくなってしまった。鴻上がマトをスカウトして米国に呼んだらしい。マトが遠くに行ってしまう。しかも、米国でのマトの仕事は…
マトを救うべく、祐は第三の事件を三人の少女の力を借りて解決する。そして、はたして祐とマトは結ばれるのか。

重層的な構造

本書はラブコメラノベという分類になっているが、その実複雑な構成になっている。評者の見るところ、以下の要素を併せ持っている。

ラブコメ
サイバーセキュリティ小説
成長譚（さまざまな事件を少女たちの力を借りて解決する過程で主人公は成長する）
自分探し（無目的に生きてきた主人公が自分のやりたいことを見出す）
探偵小説（第一話は探偵小説でもある）
家庭内暴力や児童ポルノ問題

まだ他にもあるかもしれない。
これだけの要素を文庫本300ページに突っ込むとごちゃごちゃしてしまいそうだが、どうか。率直なところ、児童ポルノ問題を扱い探偵小説仕立てにもなっている第一話は、話が少し重くなり、また、筋書きを追うのに苦労する箇所がある。著者の初めての小説ということで張り切ってネタをぶち込みすぎたのかもしれない。その反省からか、第二話と第三話では、材料を少し減らして、著者はすっきりとまとめてみせる。全体としては、重層的な構造にも関わらずラノベらしくすらすら楽しく読むことができる。

エピソード紹介

次に、本書の冒頭からいくつかのエピソードを引用で紹介しよう。

物語は、本書の主人公である愛帝学園の1年生の鷹野祐（たかのたすく）が、ヒロイン衣川マト（ころまがわまと）と邂逅するところから始まる。

　教室に入ろうとした瞬間、突然引き戸が勢いよく開いた。
　突然のことに足が絡まり、思わず尻餅をつく。
「いてて……す、すいません」
　見上げた先にいたのは妖精だつた。
　陽の光をまとい、細く艷やかな銀髪がふわりと舞う。シルバーアッシュの柳眉の下はぱっちりとした大きな翠眼（すいがん）で、真っ白な肌は白磁のようにつるつるだ。
　学年の違う俺でも知っている銀髪の美少女ーー衣川先輩だった。
　遠くから見るのとは全然違う美の暴力をまともに受け、俺はただただ、呆然と見つめるだけだった。目を離すこともできない。もしかしたら呼吸も忘れていたかもしれない。

この後、いったんは「氷のように冷たい目で俺を見下ろしていた」マトは、あるきっかけの後主人公を抱きしめるに至る。その後マトは顔を赤らめて走り去るが、主人公は小さなUSBメモリが落ちていることに気づく。

その後、準ヒロイン格でアイドルを目指している西村理乃（にしむらりの）や、主人公が入り浸っているコンピュータ部（主人公は部員ではない）の部員である嵯峨野亜弥（さがのあや）が次々に登場し、わずか10ページほどの間で主要人物が出揃うことになる。スピーディな展開で手際が良い。

主人公は亜弥にUSBメモリの調査を依頼する。亜弥はアーミーナイフを取り出し、慣れた手つきでガワを開くと、USBメモリのチップがPhison2307であり、ファームウェア改造ツールPsychsonにより改造が可能であると指摘する。

「ちょ、ちょっと待ってくれ。つまりその、ファームウェア? ってのを書き換えるとどうなるんだ?」
「デバイスクラスを偽装できるー」
「俺にもわかるように言ってくれ」
「USBデバイスの挙動をエミュレートできるー」
「俺にもわかるように言ってくれ」
　亜弥は話し足りなそうにしながらも、言葉を選ぶように言った。
「PCを乗っ取れるー」
「まじか」

BadUSBが早くも登場である。このやり取りでもわかるように、主人公はコンピュータには詳しくない。本書は主人公の一人称視点で書かれているので、難しい用語が交わる技術的な説明について、主人公に「わからない、もっと易しく説明してくれ」と言わせることによって、わかりやすく解説したり、詳細を省略して要点のみを説明できることになる。これは、著者の工夫だろう。

この後、なぜか主人公と連れ歩いているマトと、アイドルを目指す理乃が、主人公を巡って張り合う場面がある。そう、なんせラブコメなので主人公はモテモテなのだ。理乃は言う。

「好みは人それぞれだと思いますけどね、衣川先輩。幼なじみでずっと昔から知っていて、お互いに祐、理乃と呼び合う関係のあたしから言わせてもらえれば、今の祐はつまんないやつですよ。普通の人に分かる良さなんて、皆無ですからね」

幼なじみの理乃は、祐は昔と違ってつまらないやつになってしまったと言う。祐は、小学生の頃まではシャーロック・ホームズにあこがれ、将来を探偵になることを目指していたが、ある事件に関わったことがきっかけとなり、探偵を志すことをやめ、できるだけ目立たないように過ごしている。

あらすじで紹介したように、この物語は、愛帝学園に起こるさまざまな事件を主人公が周囲の力を解決することにより成長する、いわばロールプレイングゲーム（成長譚）の形態をとっている。主人公は、過去のトラウマから探偵になる夢を放棄してしまったが、友人のトラブルを解決すべく再び探偵として行動する。その過程で、マトからOSINT（オシント）という方法論を教えてもらい、これが自分の進むべき道だと気づく。

問題を抱えているのは主人公だけではない。マトと理乃は、家族に関するトラブルを抱えていたが、それぞれの方法で過去のトラブルを乗り越えようとしている。それが物語に厚みを加えている。

次に、本書の二大要素であるサイバーセキュリティ小説として、およびラブコメラノベとしての側面を紹介する。

サイバーセキュリティ小説として

本書の「事件」に登場するセキリティ要素を紹介しよう。

第一話: BadUSB、MaaS（Malware-as-a-Service）
第二話: ウェブサイト侵入（クレジットカード情報非保持サイト?）

第三話: 暗号通貨

上記のように、イマドキのセキュリティ要素がふんだんに盛り込まれている。しかも、現役のITエンジニアが書いただけあって、セキュリティ部分のクォリティは非常に高い。先に引用したBadUSBもそうだが、ここでは、評者が思わずニヤリとした箇所を引用しよう。以下は、第二話中に出てくる、侵入されたウェブサイトを巡る会話である。

「なるほど…じゃあコレはニセモノってことなんですか?」
　僕は入力途中になっていた通販サイトのページを示す。アドレスバーには緑色で企業名まで表示されている。これがニセモノならどうやって見分ければいいんだろうか。
「ああ、フィッシングという言い方は正確じゃないか。改ざん、と言った方が正しいのかな。通常だと通信が保護されていなかったり、URLが微妙に違ったりすることが多いけど、これは本物のサーバーに何かあったときの予備サーバだから、それ自体は本物よ。ただ、ファイルが書き換えられているだけ」

これはクレジットカード情報窃取の最新の手口である。評者が以前ブログ記事「クレジットカード情報盗み出しの手口をまとめた」に書いたタイプ4かタイプ5に相当する。おそらく「フィッシング」という言葉があることから、タイプ5、すなわち最新の手口であろう。
このように、著者は細かいクラッキングの手口にまで目配りして、最新の手法が紹介されている。まるで、評者がふだん「これをフィッシングと言うな」と言っているのを意識しているかのような会話だw
細かいようだが、セキュリティはディテールが重要であるし、あまりに荒唐無稽な手口だと（荒唐無稽さを突っ込んで楽しむなら別だが）読者は白けてしまう。その点、本書は、セキュリティに精通した読者でも、存分に楽しむことができる。
また、本書のヒロイン衣川マトは、実在の高名なバグハンターがモデルになっている。評者は予めそれを知っていたが、それを知らない読者でも、途中で実在のモデルを暗示する重要なエピソードが出てくるので、セキュリティに関心のある読者なら「ははーん」と分かるだろう。ここは引用したいところではあるが、ネタバレになるので控えておく。

ラブコメとして

ラブコメラノベなのだから、主人公が「冴えないやつ」であるにも関わらずがモテモテなのは、いくら非現実的でも大目に見てあげるのが大人のたしなみというものだ…そんなふうに考えていた時期が私にもありました。
実際冒頭のくだりでは、「おいおい、それはないだろう」と思いながら読んでいたのであるが、読み進めていくうちに、主人公のモテモテぶりが不自然ではなくなってくる。当初は、「主人公がモテモテなのは在原業平や光源氏以来の我が国の伝統だからな」と思っていたが、そうではなかった。鷹野祐は冴えないように見えて実は魅力的な少年なのだ。そのことを、周囲も、当人も、そして読者も気づいていないが、三人の少女は気づいていた。それは、先に引用した「普通の人に分かる良さなんて、皆無ですからね」という理乃の言葉からも伺える。読者は、物語の進展とともに主人公の魅力がわかってくるわけで、それで「モテモテぶりが自然に思えてくる」のだろう。
評者は、主人公の艶福ぶりをうらやんだり、時には「おいおい、昔から『据え膳食わぬは男の恥』と言ってな…なぜ据え膳を食わぬ」と主人公をけしかたり、さらには、「うーん、この調子でいくと祐はマトとくっつくのではなく、理乃とくっついてしまう、なんてどんでん返しもなくないか?」などと要らぬ心配をしたりした。つまり、評者はラブコメとしての本書も存分に堪能した。

おわりに

瓜生聖のサイバーセキュリティ小説「噂の学園一美少女な先輩がモブの俺に惚れてるって、これなんのバグですか? 」を紹介した。本書は、ラブコメ仕立てのサイバーセキュリティ小説であるのみならず、重層的な構造を持つ意欲的な内容であり、それでいて、ラノベとしてすらすらと読める一流のエンタテインメントである。
著者は「あとがき」の末尾で「本書を読んだラノベ好きの方が『サイバーセキュリティって面白そう』と思っていだたければ、サイバーセキュリティ関係者が『ラノベもなかなか面白いな』と思っていただければ著者冥利につきます」と記している。本書は評者が初めて読んだラノベだが、本当に面白かった。可能ならば、本書の続編で、祐とマトが恋人らしくいちゃついているシーンも読んでみたい。

鈴木常彦先生の「共用レンタルサーバにおけるメールの窃盗」の話を聴講した

2019-04-29T18:10:00.000+09:00

4月23日（火）に開催された「#ssmjp 2019/04 ～DNSの話を聞く会～」に「Outputなら任せてください枠」で参加しましたので、講演内容からとくにやばい(?)内容と思われる@tss_ontap（鈴木常彦=浸透言うな先生）の「黒塗りの DNS (萎縮編)」から、「共用レンタルサーバにおけるメールの窃盗」について紹介します。スライドは公開されています。

サマリ

レンタルサーバーからメールを送信する場合、悪意の第三者に、特定のドメインに対するメールを横取りされるリスクがある

攻撃手法

攻撃者は、レンタルサーバーを契約（お試しなどでも可能）して、攻撃対象のドメイン名（ここではchukyo-u.ac.jp…中京大学のドメイン名を用いる）を登録する
その際に、当該ドメイン名の権利を有している必要はない（権利があれば正当にメールを受信できるので攻撃の必要がない）
これだけ

なぜメールが横取りされるか?

一般にメール送信する場合、サーバー内に送信先ドメインがある場合、そちらを優先して配送する。レンタルサーバー内に攻撃対象のドメイン名（ここではchukyo-u.ac.jp）がメール設定されていると、メール配送の際にDNSを参照することなく、無条件に（ローカル内で）当該のメールボックスにメールを配送してしまう。このchukyo-u.ac.jpのメールボックスは、実際には正規のドメイン名登録者ではなく、悪意の第三者が登録したものなので、メールは悪意の第三者が横取りできることになる。

FAQ

Q1: レンタルサーバー契約時にドメイン名の権利は確認されないのか?
A1: 多くの場合権利確認はないそうですし、まぁ難しそうですね

Q2: レンサバ側でDNS権威サーバーやwhoisとか参照しないのか?
A2: 前述の通り、ローカル配送の際にはDNSやwhoisは参照しません

Q3: ドメイン名の権利者ができる対策はあるか?
A3: すべてのレンタルサーバーに契約すれば防げますが現実的ではありせん

Q4: メール送信者（レンタルサーバー利用者）ができる対策はあるか?
A4: メール以外の方法で「メール送ったよ、届いていないときは連絡して!」とメッセージするとか…というのは冗談で、メール送信者側にとれる対策はなさそうです

Q5: DNS関係ないじゃん
A5: はい。DNSとは無関係の問題ですが、近隣のテーマだとは思います

WordPressのプラグインVisual CSS Style Editorに権限昇格の脆弱性

2019-04-17T08:52:00.001+09:00

最近WordPressのプラグインのアップデート状況を監視しているのですが、Visual CSS Style Editor（別名Yellow pencil visual theme customizer）が公開停止になり、しばらくたって公開が再開されていました。これは、掲題のように権限昇格の脆弱性があったので公開停止になり、修正版が出たことにより公開再開したものです。WordPressのプラグインではよく見る光景です。

注: 公開停止になったまま再開しないプラグインも珍しくありません。最近では、types、google-maps-builder、simple-share-buttons-adder、yuzo-related-post等の人気プラグインが公開停止になりましたが、本稿執筆時点で再開していません。

脆弱性の概要

脆弱性のあるバージョン: 7.1.9以前
脆弱性の種類: 権限昇格
脆弱性による直接の影響: 外部からWordPressの設定をログインなしに変更できる
典型的な攻撃手法: 外部から勝手に管理者ユーザーを登録することで管理者になれる
対策: 最新版（本稿執筆時点では7.2.1）にアップデートする

上記は、以前紹介したWP GDPR Complianceの脆弱性CVE-2018-19207と攻撃手法や影響は似ています。PoC（概念実証コード）は公開されていますが、影響が大きいので紹介はしません。私が逮捕されても困りますしね…

原因

複数の問題が組み合わさって攻撃が可能になっていますが、とくに、yp_remote_get_first()関数内で、特定のGETパラメータを指定すると一時的に管理者になる（厳密にはid=1のユーザになる）機能が実装されていることが原因のようです。この機能の意図はよくわかりませんが、表面上は開発者が仕込んだバックドアのように見えます。以下は7.1.9から7.2.0への差分です。当該箇所は、修正版では単に削除されています。

対策

Visual CSS Style Editorプラグインの7.2.0で改修されています。本稿執筆時点の最新版は7.2.1です。最新版の導入を推奨します。
当脆弱性の攻撃のうち、管理者ユーザーを勝手に作成される経路については、WordPressのログイン機能 wp-login.php のURLを変更し、隠すことで緩和策になります。

宣伝

EGセキュアソリューションズ株式会社では、WordPress利用サイトのセキュリティ強化施策を支援しています。サービス案内はこちら。詳細はお問い合わせください。

EC2上でDNS RebindingによるSSRF攻撃可能性を検証した

2019-03-04T10:48:00.000+09:00

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 Rebinding攻撃についてはインフラ側で対策が取られている場合もあります。そこで、EC2上のウェブサイトにて、DNS RebindingによるSSRF攻撃が可能か検証してみました。
攻撃対象のスクリプトを以下に示します。これは先日の記事のスクリプトを改修したもので、クエリ文字列urlで指定したURLのコンテンツを読み出し、表示するものです。IPアドレスのチェックを追加し、表示系を簡略化しています。

<?php
  header('Content-Type: text/plain');
  $url = $_GET['url'];
  $urlinfo = parse_url($url);
  $host = $urlinfo['host'];     // URLからホスト名を取り出し
  $ip = gethostbyname($host);   // 接続先IPアドレスを取得
  echo "Target IP : $ip\n";     // 接続先のIPアドレスを表示
  if ($ip == "169.254.169.254") {
    die("Invalid host $host");  // IPアドレスが169.254.169.254ならエラー
  }
  $ch = curl_init();
  curl_setopt($ch, CURLOPT_URL, $_GET['url']);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
  $body = curl_exec($ch);
  echo $body;
  $prime_ip = curl_getinfo($ch, CURLINFO_PRIMARY_IP);
  echo "\nActual IP : $prime_ip\n";  // 実際のIPアドレスを表示

このスクリプトは、DNS Rebinding以外にもいろいろ駄目ですが、とりあえず接続先のIPアドレスが169.254.169.254でないことは確認しています。これを以下のIPアドレスで実行すると

http://ホスト名/ssrf.php?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/test-role

以下のようにエラーになります。

Target IP : 169.254.169.254
Invalid host 169.254.169.254

DNS Rebinding

ようやくDNS Rebindingの説明です。攻撃対象が下図のWeb Applicationだとします。図の右側のDNS Contents Server（DNS権威サーバー）は、接続先のドメイン名を管理しているDNSサーバーで、実は攻撃者が管理している想定です（example.jpは例示用のドメイン名です）。

この状態で、先のサンプルスクリプトでurl=http://evil.example.jp/... を指定した場合、通常ケースでは以下のように名前解決されます。

上図のように、gethostbynameとcurl_execの双方で名前解決が発生しますが、DNSキャッシュサーバーのキャッシュが残存していれば、2回目の名前解決の際には、DNSコンテンツサーバーには問い合わせずにDNSキャッシュサーバーがキャッシュの値を返します。
そこで、DNSコンテンツサーバー（権威サーバー）側がTTL=0としてAレコードを返し、Aレコードの要求毎に異なるIPアドレスを返す攻撃がDNS Rebinding攻撃です。その様子を下図に示します。

DNSコンテンツサーバーがTTL=0でAレコードを返すので、DNSキャッシュサーバーは問い合わせがある度にDNSコンテンツサーバーにAレコードを問い合わせます。そして、最初の問い合わせでは無害なIPアドレス（203.0.113.5）を返し、二度目の問い合わせでは169.254.169.254（EC2インスタンスの設定を返すIPアドレス）を返しています。このようにして、IPアドレスのチェックをすり抜ける攻撃手法がDNS Rebinding攻撃です。
上図を見る限りいかにも成功しそうですが、実際にはキャッシュサーバーの仕様などに依存します。DNS Rebinding対策その他を目的として、キャッシュサーバー側でTTLを超えてキャッシュを保持するDNS Pinningを実施している可能性があるからです。

試してみる

簡易的なDNSコンテンツサーバーを書いて、上記攻撃を試してみました。このDNSサーバーは、上図の通り、1回目の応答ではAレコードとして 203.0.113.5 を返し、2回目以降は 169.254.169.254 を返します。その結果、以下のようにSSRF攻撃に成功しました。

Target IP : 203.0.113.5
{
  "Code" : "Success",
  "LastUpdated" : "2019-03-03T08:00:51Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAxxxxxxxxxxxxxxxx",
  "SecretAccessKey" : "zCc1sxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "Token" : "FQoGZXIvYXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
  "Expiration" : "2019-03-03T14:30:31Z"
}
Actual IP : 169.254.169.254

gethostbynameの時点では、アクセス対象のIPアドレスは 203.0.113.5 （Taget IPとして表示）でしたので、事前のIPアドレスチェックはかいくぐっていることがわかります。
Actual IPは、curlが実際にアクセスしたIPアドレスであり、169.254.169.254となっています。

対策

DNS Rebinding攻撃を前提としない条件でも、接続先のURLについて以下のチェックが必要です。

プロトコル（スキーム）が http か https のいずれかである
接続先ホストに紐づくIPアドレスが禁止されたものでない

そして、IPアドレスのチェックがそもそも容易でないことはSSRF徹底入門にも書きました。加えて、DNS Rebinding攻撃の対策もやっかいです。gethostbyname関数の呼び出しに代えてdns_get_record関数等によりDNSクエリを実行して、TTLを確認することは可能ですが、正常系でもTTLが 0 になることはあり得るので、リトライなどの複雑な処理が必要になります。処理が複雑になると、それ自体が脆弱性の原因になるので、ちょっとやりたくない実装です。

先のスクリプトでは、PHPのcurl実装で使用できるCURLINFO_PRIMARY_IPを利用して、「実際に接続したホストのIPアドレス」を表示しています。攻撃によるリスクが情報漏えいのみである場合は、このIPアドレスを検証して、許可されていない場合はエラーにすることで漏洩を回避できます。ただし、これで完全な対策になるかは、徳丸自身は検証していません。

いっそのこと…ということで、外部コンテンツの取得をPROXY経由にするという対策があります。PROXYなら、接続先のホワイトリストやブラックリストによる制限は容易だからです。これだと、DNS Rebinding以外の対策も同時に行えます。

PROXYサーバーを用意するほどでもない…というケースでは、Amazonが推奨しているiptablesによる対策が考えられます。先の記事でも引用しましたが、再掲します。

sudo iptables --insert FORWARD 1 --in-interface docker+ --destination 169.254.169.254/32 --jump DROP
Amazon ECS コンテナインスタンスの IAM ロール - Amazon Elastic Container Service より引用

詳しくは、上記ドキュメントを参照ください。

補足

DNS Rebindingの一般的な対策（アクセスされる側）は以下のいずれかを実装することです（両方でもよい）。

Hostヘッダの検証（参考）
適切な認証とアクセス制御

AWSの 169.254.169.254 は両者のどちらもやっていないことはイケテナイと個人的には思います。仮に Host ヘッダがIPアドレス以外のケースをエラーにしておけば、DNS Rebinding攻撃でここから情報を盗むことはできません。今更変更は難しいかもしれませんが、ここはチェックしていただきたかったですね。

まとめ

DNS RebindingによるSSRF対策回避について説明しました。要約すると、「やってみたらできました」ということです。SSRF脆弱性の対策は難しいので、任意URLを受け取る仕様そのものを見直すか、本稿で紹介したPROXYあるいはiptablesによる対策を推奨します。

徳丸浩の日記

ISO-2022-JP自動判定を用いたHTMLコンテキスト破壊によるXSS

サマリ

はじめに

ダブルクォートを無効化できればXSS攻撃が可能になる

過去の攻撃手法: Shift_JISの先行バイトによるXSS

ISO-2022-JPの自動認識によりダブルクォート等を無効化する

検証用PHPスクリプト

対策

まとめ

ISO-2022-JPの自動判定によるクロスサイト・スクリプティング(XSS)

サマリ

はじめに

ISO-2022-JP とはなにか

ISO-2022-JPによるXSSの基本的な考え方

文字エンコーディングの自動判定

XSSを試す

コンテンツにマルチバイト文字があればどうなるか?

Google Chrome

Firefox

Safari

影響を受けるアプリケーション

対策

まとめ

「はじめて学ぶ最新サイバーセキュリティ講義」の監訳を担当しました

はじめに

意外なところにも「神話」が

徳丸は何をしたか

本書の対象読者

本書の読み方と得られるもの

2023年4月においてクリックジャッキング未対策のサイトはどの条件で被害を受けるか

サマリ

クリックジャッキングとは

検証方法

検証結果

各ブラウザのセキュリティ機能

Chromium系ブラウザの防御はデフォルトSameSite=Lax

Firefoxの防御機能は包括的クッキー保護（Total Cookie Protection）

Safariの防御機能はITP（Intelligent Tracking Prevention）

防御機能を無効化するとどうなるか

Google Chrome、Edgeの場合

Firefoxの場合

Safari

結果

考察

まとめ

[書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法

サマリ

重要事項説明

APIセキュリティテストとは何か

本書の構成

第1部 API セキュリティの原理

第2部 APIテストラボの構築

第3部 APIへの攻撃

第4部 実世界におけるAPI攻撃

本書のすごいところ

本書で扱ってない内容

注意点

本書の眼目は訳者の知見にある

本書の使い方

まとめ

Ruby cgi gemのHTTPヘッダインジェクション脆弱性CVE-2021-33621の概要と発見の経緯

概要

脆弱性発見の経緯

影響を受けるアプリケーション

影響

対策

Ruby本体のバージョンアップ

cgi gemのアップデート

アプリケーションでの対応

まとめ

PHPカンファレンス2022にてSPAセキュリティ超入門の話をします

メタップスペイメント不正アクセス事件の第三者報告書から攻撃の模様を読み解く

システムの概要

時系列の流れ

1. K管理画面 のアカウント情報の窃取、不正ログイン

XSS攻撃の詳細

なぜパスワードが窃取できたか?

社内用決済管理画面はインターネットからアクセスできた

2. SQLインジェクション攻撃によるカード情報とパスワードの窃取

第4部実世界におけるAPI攻撃

1. K管理画面のアカウント情報の窃取、不正ログイン

4. 管理画面への再度の不正アクセス及びカード番号照会開始