タグ: セキュアコーディング技術

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パラメーターを分離して書くので「ついうっかり」が起こりにくい
    • 特に初心者は「ついうっかり」が多い

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

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

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

$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, Development, PHP Security, Programming, Security
Computer, Development, PHP Security, Programming, Security

文字列（ハッシュ）の安全な比較方法 – hash_equals

4月 5, 2017 #PHP, #セキュアコーディング技術, #暗号 投稿者 yohgaki

映画などでPINコードを一桁づつ解析してドアを開錠する、といったシーンがあると思います。こんなのは”映画の世界だけ”と思っている方も多いと思います。しかし、タイミング攻撃を利用すると”実際にこれと全く同じ方法”で鍵となる情報を解析できます。

タイミング攻撃とはサイドチャネル攻撃の一種で、鍵情報を比較的簡単に解析する方法です。PHP 5.6からはタイミング攻撃に脆弱でない比較方法を提供しています。

結論から書くと、秘密の文字列を比較する場合

if ($secret_str !== $user_input) {
  // ユーザー提供の秘密情報不一致
  die('不正なアクセスです');
}

といった通常の文字列は比較は危険です。

if (!hash_equals($secret_st, $user_input)) {
  die('不正なアクセスです');
}

上記のようにhash_equals関数を利用しなければなりません。

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding
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, Development, PHP Security, Programming, Security

HMACを利用した安全なAPIキーの送受信

3月 9, 2017 #PHP, #セキュアコーディング技術, #暗号 投稿者 yohgaki

Webアプリケーションの機能をサービスとして提供する場合、ランダムな値の秘密のAPIキーを鍵とすることが多いです。

// 何らかのAPIを呼び出す
http://example.com/api/v2/get_something?api_key=qwertyuiop

シンプルな方法で使いやすいですが、鍵となるAPIキーをそのまま使っているので鍵が漏洩する可能性があります。HMACやHKDFを使うと鍵となるAPIキーを直接使わないでAPIへのアクセスを認証できます。

もっと読む

Computer, Development, PHP Security, Programming, Security

hash_hmac()の使い方

3月 8, 2017 #PHP, #セキュアコーディング技術, #暗号 投稿者 yohgaki

HMACの応用的な使い方をここ数本のブログで書いてきましたが、HMACの基本的な使い方を紹介していませんでした。リクエストパラメーターを安全に検証／バリデーションする方法を例に紹介します。unserialize()を安全に利用する利用例にもなります。

参考：

HMACハッシュの使い方のまとめ

もっと読む

Computer, Development, PHP Security, Programming, Secure Coding

パスワードのハッシュ化

3月 2, 2017 #PHP, #セキュアコーディング技術, #パスワード 投稿者 yohgaki

HMACを使った鍵の生成（導出）方法を書いているので、念の為にパスワードのハッシュ化方法について書いておきます。一般にユーザー入力のパスワードをアプリケーションデータベース等に保存する場合、HMACやHKDFを使わずに、password_hash()を使うべきです。

参考：

もっと読む

Computer, Development, PHP Security, Security

ハッシュ（HMAC）を使って弱い鍵を強い鍵に変える方法

3月 1, 2017 #PHP, #セキュアコーディング技術, #暗号 投稿者 yohgaki

既存の鍵から別の鍵を導出する方式としてはHKDF（RFC 5869）があります。AES用に弱い鍵から強い鍵を作るにはHKDFでなくてもHMACで十分です。実際、HKDFはHMACを組み合わせて鍵を導出しているだけなので、ここで紹介するHMACのみの鍵導出と同等です。

※ PHP 7.2からHKDFを実装したhash_hkdf()を使えます。hash_hkdf()が利用できる場合はシンプルにhash_hkdf()を使うと良いです。

もっと読む

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

プライベートサイトを作るならPHPのURL Rewriterを使う

10月 25, 2016 #CSRF, #PHP, #セキュアコーディング技術 投稿者 yohgaki

クロスサイト・リクエスト（他のWebサイトから自分のサイトへURLリンクやPOSTでアクセスする）を制限したいWebアプリケーションは結構あります。例えば、ホームルーターの管理ページを作る場合、クロスサイト・リクエストは有用などころか有害です。ホームルーターの管理ページにはクロスサイト・リクエストによる脆弱性が多数報告されています。

PHPの基本機能を使えば、クロスサイト・リクエストを簡単かつ丸ごと拒否することができます。CSRFやXSS1を完全かつ簡単に拒否する仕組みを作れます。

もっと読む

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

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

10月 24, 2016 #SQLインジェクション, #インジェクション, #セキュアコーディング, #セキュアコーディング技術, #セキュアコーディング論理, #セキュアプログラミング, #ベストプラクティス 投稿者 yohgaki

不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。

  • プリペアードクエリ／プレイスホルダを使ったSQLインジェクション対策でOK

は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。

簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）

似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。

出力対策”のみ”のセキュリティはアンチプラクティス

アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。

参考：

もっと読む