第五回 関西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が採用されることになりました。
参考
以前にSQLite3のデータ型は基本的には全てテキスト（例外は整数型プライマリーキー ※）である、という解説をしました。
どうもこの問題は強い型を持っている言語には影響がないとの誤解があるようなので解説します。ついでに明らかだとは思いますが、他のリスクも紹介します。
※ 正確にはBLOB型も例外になります。テキストではないデータも保存できます。SQLiteのサイトでは整数型プライマリーキーは例外と記述されていましたが、手元のSQLiteで試すと文字列も保存できてしまいました。
参考：SQLite3のカラム仕様を理解している必要があります。
https://blog.ohgaki.net/sqlite-data-type-specification
SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。
普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。
追記：論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析／対応できるようになります。
第一回 中国地方DB勉強会の講師として参加させて頂きました。
MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。
私の資料もSlideShareにアップロードしました。
データベースセキュリティ
http://www.slideshare.net/yohgaki/ss-25042247
PostgreSQL 9.3
SQLite 3.3は結構変わりますね。
Alphaなのでデフォルトの仕様は変わるかもしれませんが3.3は3.x系列のファイルは読めるが、3.3より以前のバージョンのSQLiteでは読めない、という点には注意が必要ですね。
* CHECK constraints are now enforced.
* The IF [NOT] EXISTS syntax of MySQL is now recognized on
CREATE/DROP TABLE/INDEX statements.* DESC indices really are descending now. The DESC keyword
on index definitions used to be ignored.* The database file format has changed slightly to more
compactly represent boolean values and to support DESC
indices. Version 3.3.0 will read and write all prior
version 3 databases. But new databases created by
version 3.3.0 will not be readable by older versions
of SQLite. If this is a problem for your application,
compile SQLite using-DSQLITE_DEFAULT_FILE_FORMAT=1
and then version 3.3.0 will create new databases in
the legacy format understood by all prior versions of
SQLite. DESC indices only work in the new format.* SQLite now distinguishes between REAL and INTEGER columns
and attempts to make appropriate conversions.* The OS-interface layer has been modified for greater
flexibility and control of custom ports and implementations.* SQLite now responses better to out-of-memory errors. The
library will recover and reset itself automatically. There
is no longer a need to call sqlite3_global_recover(). The
new sqlite3_enable_memory_management() API can be used to put
SQLite into a mode where it will automatically try to reduce
its database cache size when it comes under memory pressure.* The database cache and parsed schema information can now
optionally be shared between two or more database connections.
This can be used to reduce I/O and to improve concurrency.
On a database using a shared cache, you can specify
READ UNCOMMITTED isolation as an option (the default is
SERIALIZABLE). With READ UNCOMMITTED, a reader will not
block or be blocked by a writer and you will never get
an SQLITE_BUSY error on a read.