SQLインジェクション – ページ 2

インジェクション対策、基礎の基礎

12月 20, 2013 #SQLインジェクション, #インジェクション, #セキュアコーディング技術投稿者 yohgaki

インジェクション攻撃には様々な手法があります。メモリ管理をプログラマが行うC言語などではメモリにインジェクションするバッファローオーバーフロー／アンダーフロー、テキストベースのインターフェースではテキストインジェクション（JavaScriptインジェクション、SQLインジェクションなど）があります。

これらのインジェクション脆弱性はなぜ発生するのでしょうか？

今回は「インジェクション対策、基礎の基礎」の話です。

Security

オレオレSQLセキュリティ教育は論理的に破綻している

12月 11, 2013 #SQLインジェクション, #アンチプラクティス投稿者 yohgaki

ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。この事についてもブログを書くかも知れませんが、今日は「オレオレSQLセキュリティ教育」、言い換えると「自分の環境に特化したSQLセキュリティ教育」について書きます。一般論・基礎としてのセキュリティ教育は、自分の環境に特化したセキュリティ教育では困る、という話です。

このエントリは「貴方が普段言っている事が間違っている」と非難または攻撃しているのではありません。実務で「プリペアードクエリ・プレイスホルダ・ORMを使いましょう」と言うことは全く間違っていません。セキュリティ教育はこういう手順で教えたほうが解りやすいです、と提案しています。
もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

SQL識別子のエスケープ

10月 28, 2013 #PHP, #SQLインジェクション, #エスケープ, #セキュアコーディング技術投稿者 yohgaki

SQLのリテラルはエスケープが必要であることは広く認知されていると思います。しかし、識別子のエスケープはあまり広く認知されていないように思います。

PostgreSQLの場合、識別子のエスケープAPI（libpqのPQescapeIdentifier）が提供されておりPHPでもpg_escape_identifier()として利用できます。PostgreSQLの場合は”（ダブルクオート）で識別子を囲むことにより、ダブルクォート無しでは利用できない文字（例えば日本語）も識別子に利用できるようになります。
もっと読む

Database, Security

第一回中国地方DB勉強会の資料

8月 8, 2013 #MySQL, #PostgreSQL, #SQLite, #SQLインジェクション, #プレゼンテーション投稿者 yohgaki

第一回中国地方DB勉強会の講師として参加させて頂きました。

MySQLも使っていますが奥野さんの発表は普段気にしていなかったことも多く、とても参考になりました。

私の資料もSlideShareにアップロードしました。

データベースセキュリティ

http://www.slideshare.net/yohgaki/ss-25042247

PostgreSQL 9.3

http://www.slideshare.net/yohgaki/postgre-sql-93

Computer, Database, Secure Coding

知っているようで知らないプリペアードクエリ

12月 7, 2012 #PostgreSQL, #SQLインジェクション, #エスケープ投稿者 yohgaki

PostgreSQL Advent Calender 2012用のエントリです。

PostgreSQLや他のDBMSを利用していてプリペアードクエリを知らない方は居ないと思いますが、プリペアードクエリを使いこなす為のTIPSです。役に立つかどうか、は多少疑問ですが、内部がどうなっているか知っているとなにかの役に立つかも知れません。時間的制約で多少端折っているところは勘弁してください。

完全なSQLインジェクション対策は以下を参照してください。

完全なSQLインジェクション対策

Computer, Database, PHP Security, Programming, Secure Coding

PostgreSQL 9.0から使える識別子とリテラルのエスケープ

11月 29, 2011 #PostgreSQL, #SQLインジェクション, #エスケープ投稿者 yohgaki

PostgreSQL Advent Calender用のエントリです。

エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエスケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべきです。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。

PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、

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では日本語のテーブル名やフィールド名はそのままでは使えない事に気が付いた方も多いのではないでしょうか？もっと読む

Computer, Database, Programming, Secure Coding, Security

OSC Tokyo – 今更聞けないSQLインジェクションの現実と対策

10月 29, 2009 #MySQL, #PostgreSQL, #SQLインジェクション, #プレゼンテーション投稿者 yohgaki

明日のOSC東京Fallでは「SQLインジェクション”ゼロ”のPostgreSQL利用法 – 今更聞けないSQLインジェクションの現実と対策」と題したセッションを日本PostgreSQLユーザ会の講師として話をさせて頂きます。

SQLインジェクションはとうの昔に枯れた話題と思われていますが、古くても今の問題です。何年か前、日本PostgreSQLユーザ会のセミナーで手作業でのブラインドSQLインジェクションのデモをした事がありますが今回はツールを使ったデモもあります。書いている間に当初作ろうと思っていたプレゼンとは異なる物なってしまいました。多少紹介から期待する内容とは異なっているかも知れません。既にSQLインジェクションについては十分知っている方でも、それなりに(?)楽しめる内容になっていると思います。おかげ様で満員だそうですが、飛び込みでも少しは入れるのかな？

45分なのに60枚もスライドがある上、デモもあります。かなりハイペースで話すことになります。ネットで直ぐに見つかるような基本的な事はあまり書かなかったのですが、無いようで書くとSQLインジェクションについて色々在る物です。多少スライドは飛ばす事になります。

ほぼ同じ内容でOSC高知でも話をさせて頂く予定です。
来たくても来れなかった方は是非高知でお会いしましょう。

Computer, Database, Programming, Secure Coding

SET NAMESは禁止

8月 22, 2007 #MySQL, #PHP, #PostgreSQL, #Rails, #SQLインジェクション, #セキュアコーディング技術, #文字エンコーディング, #脆弱性投稿者 yohgaki

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：

mysqli_set_charset

PHPのPostgreSQL：

pg_set_client_encoding

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'"
);

http://php.net/manual/ja/ref.pdo-mysql.connection.php
http://php.net/manual/ja/ref.pdo-pgsql.connection.php (マニュアルには記載されていません。。）

Rails：

http://railsdoc.com/config

config.encoding = 文字コード

Development, Security

SQLインジェクションカンニングシート

3月 18, 2007 #SQLインジェクション, #脆弱性投稿者 yohgaki

XSSに比べSQLインジェクションは非常に簡単に防げる脆弱性ですが、まだまだなくなりません。

SQL Injection Cheat Sheetが公開されています。

http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

追記：上記ページはもう無いようです。以下のURLをご覧ください。

http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

XSS Cheat Sheatと同じような形式になっています。PostgreSQL、MySQL、MS SQL Server、Oracle、その他と攻撃可能なDBMSもわかるようになっています。

OWASPの資料：

https://www.owasp.org/index.php/SQL_Injection

参考：

完全なSQLインジェクション対策

CWE-20は知られているか？〜開発者必修のNo.1脆弱性のハズが知られていない〜

タグ: SQLインジェクション