SQLインジェクション
IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき – その2
IPAは”旧セキュアプログラミング講座は更新しない”とWebサイトに記載していましたが、次のブログで「IPAは旧セキュアプログラミングガイドの基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき」と指摘したところ修正されたので第二弾です。 ※ 2018年3月に指摘し、少なくとも秋頃には修正されていました。因みに現在セキュアプログラミング講座はCER…
コードで学ぶセキュアコーディング 〜 SQLインジェクション編
セキュアコーディング原則において、インジェクション対策の為に重要な原則は 原則1: 全ての入力をバリデーションする原則7: 全ての出力を無害化する の2つです。これらに、一般的なプログラミング原則であるフェイルファースト原則とフェイルセーフ原則、ゼロトラストを適用するとセキュアコーディングになります。 簡単なSQLインジェクション対策コードを使ってセキュアコ…
命令と引数を分離すれば安全、と考えてしまう”とんでもない誤解”はどこから生まれるのか?
SQL文やコマンド実行には命令と引数を分離するAPIがあります。便利なAPIなのですが、安全性について根本的な勘違いが多いです。 プリペアードクエリ系のAPIさえ使っていれば安全 execv系のAPIさえ使っていれば安全 これらは大きな勘違いです。 データ処理の安全性は”出力先”の処理に依存する SQLのデータもコマンド実行のデータも、そのデータ出力の安全性…
SQLクエリと識別子エスケープの話
Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。 テーマは「SQLクエリと識別子エスケープ」です。 とあるブログの結論として "「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり プリペアドクエリでSQL発行は行うこと …
セキュリティ対策が論理的に正しいか検証する方法
全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。 しかし、容易ではないからといって諦める訳にもいきません。不完…
本当にプリペアードクエリだけを使っていますか?
'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col']) SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的…
DBMSの脆弱なAPI仕様は何時まで放置されるのか?
広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。 (さらに…)
SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。 関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。 P…
SQL識別子のエスケープ
SQLの識別子(テーブル名やフィールド名)はプリペアードクエリではエスケープできません。最近の開発者はSQLの"パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。 この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケ…
完全なSQLインジェクション対策
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。 プリペアードクエリ/プレイスホルダを使ったSQLインジェクション対策でOK は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。 簡単な証明:プリペアードクエリ”だけ”では、識別子(カラム/テーブル等)を使うソートクエリ、…
安全なAPI過信症候群 – 普通のRDBMS編
昨日書いた安全なAPI症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎ、さらっと書いたよくあるRDBMSでの「安全なAPI症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。 プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペ…
安全なAPI過信症候群の処方箋 – execv/SQLite3編
またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きました。 安全なAPI過信症候群(同類にプリペアードクエリ過信症候群):「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力…
Rails ActriveRecordとSQLインジェクションと実際のアプリケーション
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
ActiveRecordのSQLインジェクションパターン
Railsで多用されているActiveRecordのインジェクションパターンを簡単に紹介します。出典はrails-sqli.orgなのでより詳しい解説はこちらで確認してください。特に気をつける必要があると思われるもののみをピックアップしました。