Database – ページ 2 – yohgaki's blog

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

本当にプリペアードクエリだけを使っていますか？

9月 7, 2017 #MySQL, #PostgreSQL, #SQLインジェクション, #アンチプラクティス, #エスケープ, #セキュアコーディング技術投稿者 yohgaki

'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col'])

SQLクエリにはプリペアードクエリを使いましょう！と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。

多くの場合、速い
SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい
- 特に初心者は「ついうっかり」が多い

しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか？コードを見れば分かります。

何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。

SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか

例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。

$result = pg_query_params('SELECT '.pg_escape_identifier($_GET['col]). ' FROM '.pg_escape_identifier($_GET['table']). ' WHERE id = $1', [$_GET['id']]);

こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。

特定カラムの抽出／ソート（これはエスケープでぼほOK）、テーブル指定をするクエリは当たり前に存在します。

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

SQLインジェクション対策総”習”編 – 第五回関西DB勉強会

5月 21, 2017 #MySQL, #PostgreSQL, #SQLite, #SQLインジェクション, #インジェクション, #エスケープ, #セキュアコーディング技術, #セキュリティ構造, #プレゼンテーション, #入力バリデーション, #出力対策投稿者 yohgaki

第五回関西DB勉強会でお話しさせて頂いた SQLインジェクション対策総”習”編の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。

関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。

PDFはこちらからダウンロードできます。

https://www.slideshare.net/yohgaki/sql-76168380

勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。

Computer, Database, PHP Security, Programming, Secure Coding, Security

コンピュータは数値さえ正確に扱えない

4月 2, 2017 #JavaScript, #MySQL, #PHP, #PostgreSQL, #Python, #Ruby, #セキュアコーディング論理, #入力バリデーション, #出力対策, #脆弱性投稿者 yohgaki

コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。

Computer, Database, Development, PHP Security, Programming, Secure Coding

SQL識別子のエスケープ

3月 21, 2017 #MySQL, #PostgreSQL, #SQLite, #SQLインジェクション, #エスケープ, #セキュアコーディング技術投稿者 yohgaki

SQLの識別子（テーブル名やフィールド名）はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。

この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。

出力対策はセキュアコーディングの基本の１つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム（ライブラリも含む。特に文字列をパースする正規表現、XML処理など）にデータを送信する場合、完全に無害化する必要があります。

参考： CERTトップ10セキュアコーディング習慣の7. 他のシステムに送信するデータを無害化する

Computer, Database, Development, PHP Security, Programming, Security

StackExchangeが攻撃されたReDoSの効果

7月 23, 2016 #ReDoS, #インジェクション, #正規表現, #脆弱性投稿者 yohgaki

StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。

PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。

参考：正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか？

Computer, Database, Development

PostgreSQLでもカウンター処理を簡単に実装できる！

1月 28, 2016 #PostgreSQL 投稿者 yohgaki

PostgreSQL 9.5がリリースされました。これに含まれるUPSERT機能を使えばPostgreSQLでも簡単にカウンター処理を実装できます。以前でもトリガーやルール、CTE(Common Table Expression)を使って実装できましたが、追加されたUPSERT機能を使った方が簡単です。

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

OWASP Secure Coding Practices – Quick Reference Guide

5月 27, 2015 #セキュアコーディング, #セキュリティ標準投稿者 yohgaki

OWASPのガイドラインはPCI DSSでも参照するように指定されているセキュリティガイドラインです。その中でも比較的簡潔かつ体系的にセキュアプログラミングを解説した資料がOWASP Secure Coding Practices – Quick Reference Guide (v2) です。

日本語訳がないようなので一部未訳ですが訳しました。CC-BY-SAライセンスです。クリエイティブコモンズライセンスに従って自由に配布できます。

チェックリスト形式になっているので、自分のコーディング／開発スタイルがどの程度適合しているのか、簡単にチェックできるようになっています。コーディングスタイルのみでなく、運用はシステム構成に関連する物も含まれています。私が解説／紹介しているセキュリティ対策を行っている開発チームであればこれらの殆どに適合しているはずです。どのくらい適合していたでしょうか？

イントロダクションでは、開発者に対して少々厳しいことが書いてあります。

この技術的不可知論文書は一般的なセキュアコーディングを実践に必要な要素をソフトウェア開発ライフサイクルに統合可能なチェックリストとして定義します。

「技術的不可知論文書」（不可知論：物事の本質は人には認識することが不可能である、とする立場のこと ※ ）としているのは、この文書が取り扱うセキュアコーディングの本質が理解されていない、理解されることがない、と嘆いていることを意味します。セキュアコーディングの本質の解説は諦めて作ったチェックリストであることを示唆しています。私も同じ感覚を共有しています。興味がある方はぜひ以下の参考資料を参照してください。原理と原則を知った方が応用範囲が広がります。

正確な直訳より分かり易さを優先しました。見直しをする時間まではありませんでした。誤り、誤解を招く訳などの指摘を歓迎します。

※ Agnostic（不可知論）について：このガイドは2010年に公開された文書です。最近、agnosticは「〜に依存しない」「〜に関わらず」「〜を問わず」「汎用的」「プラガブル」「詳しく知らなくても使える」といったコンテクストで割と一般的なIT用語として利用されています。2010年頃は哲学的意味が強かったと思いますが、現在は先に書いたような意味で使われているケースが多くあります。

参考資料：

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

不整合が起きてはならない場合、トランザクションはシリアライザブル

5月 8, 2015 #MySQL, #PostgreSQL, #SQLite, #セキュアコーディング技術投稿者 yohgaki

リレーショナルデータベースが優れている点はトランザクションをサポートしている点です。トランザクションは手続きが一貫性ある形で実行されることを保証してくれます。しかし、トランザクションを使えばOK、という物ではありません。

もしトランザクションさえ使っていればOKと思っていた方はトランザクション分離レベルを理解してください。

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

PHP7で追加される整数型、浮動小数点型タイプヒントの問題点

3月 30, 2015 #JSON, #MySQL, #PHP, #PostgreSQL, #SQLite, #セキュアコーディング論理投稿者 yohgaki

PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。

データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。

参考

PHP7のタイプヒントの使い方

Computer, Database, Development, PHP Security, Security

Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能

2月 13, 2015 #インジェクション, #セキュアコーディング技術投稿者 yohgaki

Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。

Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。

Database, Development

知って得するPostgreSQLのRETURNING句

12月 19, 2014 #PostgreSQL 投稿者 yohgaki

速いアプリケーションの作り方でPostgreSQLのRETURNING句に軽く触れましたが、この機能はデータベースチューニングで強力なツールになる場合があります。知って得する、知らなければ損をする、そんな機能がRETURNING句です。

Computer, Database, Development, Security

速いアプリケーションの作り方

12月 18, 2014 #Framework, #Phalcon, #PHP, #Zephir, #ベンチマーク投稿者 yohgaki

Phalcon Adventカレンダー18日目として書いています。

一台のアプリケーションサーバーで10リクエスト/秒で十分というサービスであれば、どんなプラットフォームを選んでも問題ありません。一台のサーバーが10リクエスト/秒しか処理できなくても、ページがキャッシュできるならリバースプロキシで簡単に数千リクエスト/秒以上でサービスできます。このようなサービスであればPhalconのようなフレーワムワークを使わなくても大丈夫です。

しかし、メッセージング系などリアルタイム性の高いサービス、つまりHTTPキャッシュがあまり有効に利用できないシステムでは速度が非常に重要です。

Database

PostgreSQLのJSONB型を利用してタグ検索を行う

12月 12, 2014 #JSON, #PostgreSQL 投稿者 yohgaki

遅れてしまいましたが、PostgreSQL Adventカレンダー2014の9日目です。昨年はタグ検索するならPostgreSQLで決まり！でPostgreSQLの特徴でもある配列型を使ったタグ検索を紹介しました。今年はJSONを使ってみたいと思います。

つい先程、PostgreSQL GitリポジトリからPostgreSQL 9.4のソースを取得＆ビルドして記事を書いています。（記事を書くことを忘れていたので大急ぎで書きました）

Database, Development, PHP Security, Programming, Secure Coding, Security

SQLiteデータ型の仕様とセキュリティ問題

12月 12, 2014 #SQLite, #セキュアコーディング技術, #入力バリデーション投稿者 yohgaki

SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。

普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。

追記：論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析／対応できるようになります。

Database, Development, PHP Security, Programming, Secure Coding, Security

安全なAPI過信症候群 – 普通のRDBMS編

12月 12, 2014 #SQLインジェクション, #アンチプラクティス, #セキュアコーディング技術, #セキュアコーディング論理投稿者 yohgaki

昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。

プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。

カテゴリー: Database