書かない日記
SQL文やコマンド実行には命令と引数を分離するAPIがあります。便利なAPIなのですが、安全性について根本的な勘違いが多いです。
これらは大きな勘違いです。
SQLのデータもコマンド実行のデータも、そのデータ出力の安全性は出力先（コンテクスト）でどのように処理されるかに依存します。
SQLインジェクションもコマンドインジェクションも１つでも間違いがあると大問題となる脆弱性ですが、大きな勘違いはかなり広く浸透しています。どこからこんな”とんでもない誤解”が生まれて、広まるのでしょうか？
Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。
テーマは「SQLクエリと識別子エスケープ」です。
とあるブログの結論として
“「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり
- プリペアドクエリでSQL発行は行うこと
この場合変数のバインドは必ずプレースホルダを用いること。SQL文の文字列操作は禁止であり、これほどシンプルなことも無いだろう”
と書かれていました。しかし、私はこの意見に対して
実践的なSQLクエリを書いたことが全くない開発者なのでしょう？？
ソートカラム、抽出カラムを指定するSQLクエリでは「識別子（カラム名）が変数」になります。
初歩的なSQLクエリですが”自分が書いたことないから”といって一般的ではないと勘違いしています。行のソート順、抽出カラムを指定するSQLクエリは業務アプリでは”一般的”です。当たり前ですが。こうやってベストプラクティスもどきのアンチプラクティスが使われて、喜ぶのはサイバー犯罪者とセキュリティ業者だけですよ。
とコメントしました。SQLのテーブルやジョイン結果を「表」として表示した際に、任意のカラムのソート順を指定するUIは、自分で作ったことが無かったとしても、ごく一般的だと分かると思うのですが・・・
全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション１つとっても本当に完全であるか？検証することは容易ではありません。プログラムが本当に思っているように動作するのか？検証する研究は、まだまだ研究段階です。
しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。
SQLクエリにはプリペアードクエリを使いましょう！と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。
しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか？コードを見れば分かります。
何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。
広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
SQLの識別子（テーブル名やフィールド名）はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。
この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。
出力対策はセキュアコーディングの基本の１つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム（ライブラリも含む。特に文字列をパースする正規表現、XML処理など）にデータを送信する場合、完全に無害化する必要があります。
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：
昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。
プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。
またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。
安全なAPI過信症候群（同類にプリペアードクエリ過信症候群など）：「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。
このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。
現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
Railsで多用されているActiveRecordのインジェクションパターンを簡単に紹介します。出典はrails-sqli.orgなのでより詳しい解説はこちらで確認してください。特に気をつける必要があると思われる物のみをピックアップしました。
インジェクション攻撃には様々な手法があります。メモリ管理をプログラマが行うC言語などではメモリにインジェクションするバッファローオーバーフロー／アンダーフロー、テキストベースのインターフェースではテキストインジェクション（JavaScriptインジェクション、SQLインジェクションなど）があります。
これらのインジェクション脆弱性はなぜ発生するのでしょうか？
今回は「インジェクション対策、基礎の基礎」の話です。
ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。この事についてもブログを書くかも知れませんが、今日は「オレオレSQLセキュリティ教育」、言い換えると「自分の環境に特化したSQLセキュリティ教育」について書きます。一般論・基礎としてのセキュリティ教育は、自分の環境に特化したセキュリティ教育では困る、という話です。
このエントリは「貴方が普段言っている事が間違っている」と非難または攻撃しているのではありません。実務で「プリペアードクエリ・プレイスホルダ・ORMを使いましょう」と言うことは全く間違っていません。セキュリティ教育はこういう手順で教えたほうが解りやすいです、と提案しています。
“オレオレSQLセキュリティ教育は論理的に破綻している” の続きを読む
SQLのリテラルはエスケープが必要であることは広く認知されていると思います。しかし、識別子のエスケープはあまり広く認知されていないように思います。
PostgreSQLの場合、識別子のエスケープAPI（libpqのPQescapeIdentifier）が提供されておりPHPでもpg_escape_identifier()として利用できます。PostgreSQLの場合は”（ダブルクオート）で識別子を囲むことにより、ダブルクォート無しでは利用できない文字（例えば日本語）も識別子に利用できるようになります。
“SQL識別子のエスケープ” の続きを読む
第一回 中国地方DB勉強会の講師として参加させて頂きました。
MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。
私の資料もSlideShareにアップロードしました。
データベースセキュリティ
http://www.slideshare.net/yohgaki/ss-25042247
PostgreSQL 9.3
PostgreSQL Advent Calender 2012用のエントリです。
PostgreSQLや他のDBMSを利用していてプリペアードクエリを知らない方は居ないと思いますが、プリペアードクエリを使いこなす為のTIPSです。役に立つかどうか、は多少疑問ですが、内部がどうなっているか知っているとなにかの役に立つかも知れません。時間的制約で多少端折っているところは勘弁してください。
完全なSQLインジェクション対策は以下を参照してください。
PostgreSQL Advent Calender用のエントリです。
エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。
PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、
|
0 1 2 3 4 |
yohgaki@[local] test=# CREATE TABLE user (name text); ERROR: syntax error at or near "user" 行 1: CREATE TABLE user (name text); |
と失敗してしまいます。これはuserがPostgreSQLの予約語であるためSQL文の識別子として使用できないからです。MS Accessからデータベースに入った方には識別子に日本語を使う場合も多いので、PostgreSQLでは日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか？ “PostgreSQL 9.0から使える識別子とリテラルのエスケープ” の続きを読む
明日のOSC東京Fallでは「SQLインジェクション”ゼロ”のPostgreSQL利用法 – 今更聞けないSQLインジェク ションの現実と対策」と題したセッションを日本PostgreSQLユーザ会の講師として話をさせて頂きます。
SQLインジェクションはとうの昔に枯れた話題と思われていますが、古くても今の問題です。何年か前、日本PostgreSQLユーザ会のセミナーで手作業でのブラインドSQLインジェクションのデモをした事がありますが今回はツールを使ったデモもあります。書いている間に当初作ろうと思っていたプレゼンとは異なる物なってしまいました。多少紹介から期待する内容とは異なっているかも知れません。既にSQLインジェクションについては十分知っている方でも、それなりに(?)楽しめる内容になっていると思います。おかげ様で満員だそうですが、飛び込みでも少しは入れるのかな？
45分なのに60枚もスライドがある上、デモもあります。かなりハイペースで話すことになります。ネットで直ぐに見つかるような基本的な事はあまり書かなかったのですが、無いようで書くとSQLインジェクションについて色々在る物です。多少スライドは飛ばす事になります。
ほぼ同じ内容でOSC高知でも話をさせて頂く予定です。
来たくても来れなかった方は是非高知でお会いしましょう。
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：
|
0 1 2 3 4 5 6 7 8 9 10 11 12 |
<?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：
|
0 1 2 |
config.encoding = 文字コード |