2017年版OWASP TOP 10がリリースされました。新しくA4としてXXE、A10としてInsufficient Logging & Monitoringが入りました。今回はXXE対策を紹介ます。XXE対策は簡単です。
XXEは「リクエストのインジェクション」と考えると解りやすく、「リクエストのインジェクション」と理解すれば他の類似攻撃パターンにも応用できます。
自分で直接XMLモジュールのクラス／関数を使ってXML処理している場合は問題箇所は判り易いですが、ライブラリなどを使う場合は知らずにXXEに脆弱になりえます。外部XML文書を処理する場合、XML処理ライブラリは盲信するのではなく、XXEに脆弱でないか検証してから使わないとなりません。
ファイアーウォールで守っている、プロキシも使っている、だからインターネットからローカルネットワークは守られている！
半分あたりですが、半分はずれです。よくあるネットワークシステムではローカルネットワークはインターネットから半分くらいしか守っていません。
まだ対策をしていない場合は実施することを強くお勧めします。
クロスサイト攻撃からローカルネットワークを守ることは簡単です。簡単なので会社、特にシステム開発／運用部門は必ずローカルネットワークへのクロスサイトアクセスを禁止＆検出すべきです。クロスサイト攻撃とはクロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）の事です。基本的な対策ですが、意外に実施されていることが少ないようです。
クロスサイト攻撃はWebシステムに対するよくある攻撃手法です。少しの手間でインターネットからローカルネットワークに対するクロスサイト攻撃を完全に防止することが可能です。
ここ5年ほど（？）行っている岡山大学ビジネスマインドセミナーの講師を本年も担当しています。今年は内容を大幅に更新しています。
席数は十分にあるはずなのでconnpassでも登録できるようにしました。今週末（11月11日土曜）13：00～です。お気軽に受講ください！
本年度のセミナー内容を少しだけ紹介します。
お待ちしています！
私のブログを読んでいる方は技術者が多いと思うので、少し技術よりの部分を紹介します。セミナーはプログラミング知識なしで理解できる内容になっています。
一枚一枚のスライドに紹介・説明すべき内容が多すぎて書ききれません。詳しくは受講をお願いします！
セキュリティ対策には設計図があります。少なくともアーキテクチャー図があります。しかし、何故かソフトウェアの場合は設計図もアーキテクチャー図も書けないセキュリティ対策が当たり前になっています。国際情報セキュリティ標準やセキュリティガイドラインを普通に理解すれば解ること、セキュリティ対策の基礎の基礎にも関わらず、です。
これは一般開発者の問題というより、セキュリティ専門家やセキュリティに詳しい開発者の問題でしょう。セキュリティ問題は十分に複雑な問題であることに異論はないと思います。複雑な問題を解くにはアーキテクチャー（構造化）と適切な設計が重要です。設計どころかアーキテクチャーさえないのは明らかに問題でしょう。設計となると細かな仕様が必要となります。ここではアーキテクチャーだけでも十分なのでこれだけを考慮します。
重要な事なので最初に書いておきます。セキュリティアーキテクチャー作る、は信頼境界線を書くことです。信頼境界の中に入れたモノ（入力やその他のモノ）であっても、普通は”何をしても安全なモノ”ではありません。安全性の為に更に詳細な入力検証が必要だったり、特定の権限を持つモノだけ許可したりするモノ、条件付きで信頼境界の中に入れるモノが普通にあります。また、信頼境界から出る時（出力）のセキュリティ対策は入力対策とは独立した対策です。これはよくある誤解なので注意しましょう。
信頼境界は”防衛線”です。”防衛線”での防御はITセキュリティ対策に限らず、全てのセキュリティ対策共通した防御策です。”防衛線”の”中に在るモノ”は”信頼できるモノ”であることを可能な限り保証します。”防衛線”を越えて”入るモノ”と”出るモノ”は可能な限り安全性を保証します。これが全てのセキュリティ対策共通の基本です。
※ 信頼境界を越えて検証されたモノ（物／人／データなど）が「全面的に信頼できると誤解される」ことがよくあります。検証されたモノであっても、検証された範囲／内容までしか信頼できません。全面的に信頼できるモノはほぼ無い、とゼロトラストで考える必要があります。
アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。
このエントリは不定期にメンテナンスするつもりです。
なぜセキュアなシステムが作れないのか？この問いは
なぜバグフリーのシステムが作れないのか？1
と同類の問いです。一定規模を超えると完全にバグ／問題がないシステムを作るのは非常に困難です。どのような状況でも正常に動作する完全にバグ／問題がないシステムは簡単には作れません。しかし、バグ／問題がないシステムが容易に作れないからといって「体系的な対策を行わない」のは賢明なアプローチではありません。
このエントリではよりセキュリティ問題が少くなるアプローチを紹介します。これはセキュリティ標準やガイドラインに記載されている考え方をまとめたモノです。
ポイントは
です。
ブログで紹介するのを忘れていました。PHP用の入力バリデーションモジュール validateを作りました。
https://github.com/yohgaki/validate-php
PHP開発MLでの議論用に作ったので、作りかけと言える状態ですが、一応動作し使えます。
関数名はvalidate()の方が良いのでは？という意見があったので、名前は変更する予定です。valid()にしていた理由は”validate”だとあまりに一般的過ぎて、同じ名前の関数を定義しているユーザーがいるだろう、と予想したからです。自分のアプリやライブラリには名前空間を使うべきなので、モジュール関数はvalidate()にします。
いろいろ意見があったのですが、やはり入力処理における入力バリデーションとロジック処理の混同がありました。
入力処理における「形式的バリデーション」とロジック処理における「論理的／仕様的バリデーション」は別処理とした方が、構造的に優れています。この理由はまたの機会に書きます。
Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。
Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。
全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション１つとっても本当に完全であるか？検証することは容易ではありません。プログラムが本当に思っているように動作するのか？検証する研究は、まだまだ研究段階です。
しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。
'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col'])
SQLクエリにはプリペアードクエリを使いましょう！と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。
しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか？コードを見れば分かります。
何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。
例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。
$result = pg_query_params('SELECT '.pg_escape_identifier($_GET['col]). ' FROM '.pg_escape_identifier($_GET['table']). ' WHERE id = $1', [$_GET['id']]);
こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。
特定カラムの抽出／ソート（これはエスケープでぼほOK）、テーブル指定をするクエリは当たり前に存在します。
広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。
Slideshareで「ネットワークから学ぶソフトウェアセキュリティの基礎」を公開しました。
ネットワークの世界で”当たり前”のセキュリティアーキテクチャーですが、残念ながらソフトウェアの世界では”当たり前”ではありません。
必要なセキュリティ対策やアーキテクチャーは状況やニーズによって変わります。セキュリティについて様々な考え方を持つことは構わないのですが、基礎中の基礎は”適用しないとしても”普遍です。
https://www.slideshare.net/yohgaki/ss-79410254
ISO 27000（ISMS）をはじめ、セキュアコーディング／セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1
しかし、広く使われているフレームワークでさえセキュアコーディング／セキュアプログラミングをサポートする機能が無かったり／不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも？と言えるのはセキュアコーディング／セキュアプログラミングでは枝葉末節にあたるコーディング技術（ああすべき／こうすべき）くらいではないでしょうか？
なぜセキュアコーディング／セキュアプログラミングが普及していないのか？考えられる理由を挙げます。
セキュアコーディング／セキュアプログラミングとは？という方は以下を参考にしてください。