「フェイルセーフ」よく聞く言葉です。最近では「フェイルセキュア」1と言われることもありますが、基本概念は同じです。よく聞く言葉＆簡単な概念ですが、割と広く誤解されている概念の１つに見えます。
フェイルセーフを一言で言うと
何かに失敗しても致命的な問題に至らないよう安全に失敗させる
これがフェイルセーフです。可能ならば「失敗／故障しても、失敗／故障の影響を受けないようする」場合もあります。ITシステムならRAID5や失敗時のリトライなどがこのケースです。
フェイルセーフ（フェールセーフ、フェイルセイフ、英語: fail safe）とは、なんらかの装置・システムにおいて、誤操作・誤動作による障害が発生した場合、常に安全側に制御すること。またはそうなるような設計手法で信頼性設計のひとつ。これは装置やシステムが『必ず故障する』ということを前提にしたものである。
となっています。
こんな単純な概念は間違いようがないでしょ？
と思うかも知れません。しかし、ソフトウェア開発では当たり前に誤解されています。
RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。
プログラムが正しく動作する為には
が絶対条件です。どちらが欠けてもプログラムは正しく動作しません。
SQLiteは手軽で良いのですが、組み込み型であるためデータセキュリティを学ぶには機能的に問題があります。SQLiteにはデータ型を保証する機能もデータの内容を検証する機能もありません。1
利用するRDBMSはPostgreSQLを用い、データセキュリティに関連性の強い機能のみを対象とします。
Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。
テーマは「SQLクエリと識別子エスケープ」です。
とあるブログの結論として
“「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり
- プリペアドクエリでSQL発行は行うこと
この場合変数のバインドは必ずプレースホルダを用いること。SQL文の文字列操作は禁止であり、これほどシンプルなことも無いだろう”
と書かれていました。しかし、私はこの意見に対して
実践的なSQLクエリを書いたことが全くない開発者なのでしょう？？
ソートカラム、抽出カラムを指定するSQLクエリでは「識別子（カラム名）が変数」になります。
初歩的なSQLクエリですが”自分が書いたことないから”といって一般的ではないと勘違いしています。行のソート順、抽出カラムを指定するSQLクエリは業務アプリでは”一般的”です。当たり前ですが。こうやってベストプラクティスもどきのアンチプラクティスが使われて、喜ぶのはサイバー犯罪者とセキュリティ業者だけですよ。
とコメントしました。SQLのテーブルやジョイン結果を「表」として表示した際に、任意のカラムのソート順を指定するUIは、自分で作ったことが無かったとしても、ごく一般的だと分かると思うのですが・・・
'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）、テーブル指定をするクエリは当たり前に存在します。
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
https://www.slideshare.net/yohgaki/sql-76168380
勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。
SQLの識別子（テーブル名やフィールド名）はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。
この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。
出力対策はセキュアコーディングの基本の１つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム（ライブラリも含む。特に文字列をパースする正規表現、XML処理など）にデータを送信する場合、完全に無害化する必要があります。
リレーショナルデータベースが優れている点はトランザクションをサポートしている点です。トランザクションは手続きが一貫性ある形で実行されることを保証してくれます。しかし、トランザクションを使えばOK、という物ではありません。
もしトランザクションさえ使っていればOKと思っていた方はトランザクション分離レベルを理解してください。
PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。
データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。
参考
第一回 中国地方DB勉強会の講師として参加させて頂きました。
MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。
私の資料もSlideShareにアップロードしました。
データベースセキュリティ
http://www.slideshare.net/yohgaki/ss-25042247
PostgreSQL 9.3
明日のOSC東京Fallでは「SQLインジェクション”ゼロ”のPostgreSQL利用法 – 今更聞けないSQLインジェク ションの現実と対策」と題したセッションを日本PostgreSQLユーザ会の講師として話をさせて頂きます。
SQLインジェクションはとうの昔に枯れた話題と思われていますが、古くても今の問題です。何年か前、日本PostgreSQLユーザ会のセミナーで手作業でのブラインドSQLインジェクションのデモをした事がありますが今回はツールを使ったデモもあります。書いている間に当初作ろうと思っていたプレゼンとは異なる物なってしまいました。多少紹介から期待する内容とは異なっているかも知れません。既にSQLインジェクションについては十分知っている方でも、それなりに(?)楽しめる内容になっていると思います。おかげ様で満員だそうですが、飛び込みでも少しは入れるのかな？
45分なのに60枚もスライドがある上、デモもあります。かなりハイペースで話すことになります。ネットで直ぐに見つかるような基本的な事はあまり書かなかったのですが、無いようで書くとSQLインジェクションについて色々在る物です。多少スライドは飛ばす事になります。
ほぼ同じ内容でOSC高知でも話をさせて頂く予定です。
来たくても来れなかった方は是非高知でお会いしましょう。
にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。
PostgreSQL 8.2.4 – 11ページ
ピーク性能でおよそ5400transactions/secほど。
MySQL 5.0.45 – 15ページ
ピーク性能でおよそ3800transactions/secほど。
Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速（数値にして数倍）になったようです。
グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル（16ページ）によると
On this benchmark PostgreSQL is 35% – 45% faster thanMySQL at all loads
とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よりもさらに良い性能を期待できると思います。MySQLも5.1や6.0を利用した方が良い性能が期待できるのかも知れません。
このPDFのベンチマークはデータベースの性能を計る為のベンチマークではなく、OSの性能を計る為のベンチマークです。データベースサーバ設定、SQL文やテーブル構成などが不明なのでデータベースの性能のベンチマークとしては参考値くらいでしかありません。MySQLのテストではMyISAMを使っていると思われますが、MyISAMならこれくらいの性能差は普通です。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5968
によるとMySQL 5.1.23には脆弱性ありその概要は以下とされています。
Overview MySQL 5.1.x before 5.1.23 might allow attackers to gain privileges via unspecified use of the BINLOG statement in conjunction with the binlog filename, which is interpreted as an absolute path by some components of the product, and as a relative path by other components. Impact CVSS Severity (version 2.0): CVSS v2 Base score: 10.0 (High) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend) Impact Subscore: 10.0 Exploitability Subscore: 10.0 Access Vector: Network exploitable Access Complexity: Low **NOTE: Access Complexity scored Low due to insufficient information Authentication: Not required to exploit Impact Type: Provides administrator access, Allows complete confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service
MySQL 5.0系の最新版は5.0.51ですが、これには上記の脆弱性の修正が含まれているか気になったので調べてみました。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5969
これは同じ日付のMySQL 5.0.51のCVEエントリです。これにはBINLOGの脆弱性に関する記述がありませんでした。リリースノートのURLがあったので見てみましたが以下のリリースノートにの記述がありませんでした。（現時点で）
5.0.51のリリースノート
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-51.html
5.0.52のリリースノート（現時点では、Enterprise版のユーザしかダウンロード出来ない?）
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-52.html
5.0.54のリリースノート（現時点ではまだダウンロード出来ない）
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-54.html
5.0には影響ない?
5.0.51で修正?
5.0.52で修正?
5.0.54で修正?
どれなのかよく分かりません。分かったのはMySQLはコミュニティ版とエンタープライズ版でセキュリティパッチリリースを差別化している事です。5.0.52にもセキュリティフィックスが記載されています。つまり最新のコミュニティ版の5.0.51では不十分です。探せばダウンロードできるのか?アカウントを取ればダウンロードできるのか?いづれにせよどれが最新で安全なのか分かりづらいです。
リポジトリへのコミットを見ていればセキュリティパッチを見分けてインストールする事も可能ですが、とても一般向けとは言い難いです。
MySQL 6.0のバージョン管理にはBitKeeperを利用しているようです。5.1、5.0はsubversionのようなので今はまだよいですが、BitKeeperも障壁の一つになりそうです。リポジトリ自体にアクセスしてみよう、と思ったのですが少しググっただけではどこへアクセスすればよいのか分かりませんでした…
追記
しばらくしてからまた新しいMySQLのCVEが出ています。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5970
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6303
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6304
新しい方は明確にかいてあるので古い方はどうなの?と思わなくてもよいようになっています。
MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。
Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。
PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。
ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。
脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES（PostgreSQLのSET CLIENT_ENCODING等も)は禁止」です。
PHPのMySQL：
PHPのPostgreSQL：
PHPのPDO：
<?php
// MySQL
$pdo = new PDO(
'mysql:host=yourhost;dbname=yourdb;charset=sjis',
'user', 'password'
);
// PostgreSQL
$pdo = new PDO(
"pgsql:host=yourhost;dbname=yourdb;options='--client_encoding=sjis'"
);
Rails：
config.encoding = 文字コード
hackers-jp@ml.postgresql.jp に掲載されていたメールの話です。
色々興味深いです。
MyISAM -> InnoDBで容量が約10倍。InnoDBとPostgreSQLを比べても約3倍。
キャパシティプランニングはDB設計の重要な要素ですが、知らないと困ったことになりますね。
MySQLであまり大きなDBを取り扱ったことが無かったので知らなかったですがMyISAM->InnoDBで10倍にもなるケースもあるとは…
JPUGのMLに書かれていた以外の理由としては1/3のメモリで3倍速く、データのパーテションニング、パーシャルインデックス等のPostgreSQL機能を近い将来利用する事が出来ることもスイッチする理由だそうです。
For an application like FeedLounge, the faster counting and smaller row size of PostgreSQL are compelling reasons to use it instead of MySQL with InnoDB tables. Add that it runs in 1/3 the time, using 1/3 the memory (making it essentially 10x faster for us) and that we can start taking advantage of other Postgres features, like data partitioning and partial indices in the near future, and you have the reason we decided to make the switch.
軽くて速いPostgreSQLは彼らにとって「10倍速い」と言っています。何だか一般的に言われていること（MySQLは軽くて速い）と反対ですね。
どのDBを選択するか?は利用条件、要求事項によって最適な選択が異なります。MySQLの方が自分にとっては「10倍速い」と考えるユーザも多いと思います。どちらにしてもこの事例は参考になります。
以下、メール本文のコピーです。
—–
寺本＠横須賀 です。
最近メールがないので…
雑談ですが、ちょっと面白いのでご紹介です。(via Planet Postgresql)
FeedLoungeという、RSSフィードのオンラインリーダーを提供している（らしい）サービスがあるのですが、そこがDBをMySQLからPostgreSQLに乗り換えた、という話です。
http://feedlounge.com/blog/2005/11/20/switched-to-postgresql/
何が理由で乗り換えたのかに興味があったので読んでみたんですが、
—-
Some of the reasons we decided to make the switch to PostgreSQL: * Database size - when we switched from MyISAM tables to InnoDB tables in MySQL, the size of our database grew from ~1GB to 10+GB! When we made the switch this weekend, the MySQL InnoDB database was using 34 GB, and the same data in a PostgreSQL database is only 9.6 GB - this should keep our hardware costs down a bit. * Load time - The current MySQL setup takes over a day to restore the current database, the load of the data into the PostgreSQL database took just over 4 hours.
—-
という今まで聞いたことも無い理由で乗り換えたとのことでした。
# PGよりも3倍も容量が多くなっちゃったなんて！
その後にPG派とMy派でいろいろコメントがついてます。
どうもでっかいPrimary Keyがついてるらしく、それがまずいんじゃないのか？的話になっていうように読めました。（斜め読みです）
— Junji Teramoto / teramoto.junji (a) lab.ntt.co.jp Master Yoda : Don’t think…feel…be as one with the Source. Help you, it will.