PHP7からint/float/arrayの基本的データ型のタイプヒントが導入されます。タイプヒントには困った問題があります。その問題を更に複雑にするjson_decode関数のデータ型変換問題があります。
JSONデータの数値型データ※が特定の型に変換される問題はPHPのjson_decode関数に限った問題ではなく、JSONを利用する処理系を作る全ての開発者が注意すべき問題です。
※正確には数値型データと書くより「数値型リテラル」と記述するべきですが、「数値型データ」とします。
以前にSQLite3のデータ型は基本的には全てテキスト（例外は整数型プライマリーキー ※）である、という解説をしました。
どうもこの問題は強い型を持っている言語には影響がないとの誤解があるようなので解説します。ついでに明らかだとは思いますが、他のリスクも紹介します。
※ 正確にはBLOB型も例外になります。テキストではないデータも保存できます。SQLiteのサイトでは整数型プライマリーキーは例外と記述されていましたが、手元のSQLiteで試すと文字列も保存できてしまいました。
参考：SQLite3のカラム仕様を理解している必要があります。
Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。
Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。
SQLiteはファイルベースのオープンソースRDBMSです。オープンソースとしては珍しいパブリックドメインライセンスを採用しています。SQLiteはファイルベースなのでデータベースサーバーが必要なく手軽に利用できます。SQLiteは組み込みデバイスで広く利用され、Android/iOSなどでは標準的なデータベースとして利用されています。モバイルデバイス以外での利用も広がっており例えば、Drupal8はSQLite3に対応しています。
普通のRDBMSのようにSQLクエリが利用できるのでとても便利ですが、SQLiteの仕様は他のRDBMSと異なるので注意が必要です。
追記：論理的・体系的セキュリティを構築していれば、ここに書かれているようなセキュリティ上問題となる事を自身で分析／対応できるようになります。
昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。
プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。
最近、ファイルアップロード／ダウンロード対策に関する検索が増えているようなので書きました。PHPの場合、スクリプトがアップロードされ実行されてしまうと致命的です。アップロードされたファイルを公開ディレクトリに保存することは好ましくありあせん。しかし、既にそうなっているアプリケーションの場合、改修が困難な時もあります。このような場合もより安全に利用できる設定を紹介します。
参考：「スクリプトアップロード対策」も合わせてどうぞ。
password_hash関数はcrypt関数のラッパーです。パスワードを簡単かつ安全にハッシュ化するための関数です。現在のPHPマニュアルにはpassword_hash関数の重要な制限が未記載であったため追加しました。 もっと読む
先日はActive RecordのSQLインジェクションパターンを紹介しました。今回は脆弱なコードを見つける事を試みようと思います。脆弱とは言っても攻撃可能であることは意味しません。コーディングとして脆弱であるという意味です。実際に攻撃可能であるかどうかまでは確認していません。
以前にJavaScript文字列のエスケープ関数を紹介しました。試しにPhalconのZephirで書いてみました。
Railsで多用されているActiveRecordのインジェクションパターンを簡単に紹介します。出典はrails-sqli.orgなのでより詳しい解説はこちらで確認してください。特に気をつける必要があると思われる物のみをピックアップしました。
Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。
この仕様の違いはデータのバリデーションに大きく影響します。
参考： PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。
HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。
まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。
参考：
PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。
タイミングセーフな文字列比較関数はhash_equalsとして実装されました。
http://php.net/manual/es/function.hash-equals.php
色々やることがあってブログを更新できていませんでした。久々のブログはPHPのOpenSSL関数を使ってAES-256-CBCを使って暗号化する例です。今時のハードウェアとソフトウェアならハードウェアAESが利用できるので普通はAES-256-CBCで構わないでしょう。
もっと読むテキストインターフェース処理の基本でもう書いてしまいましたが、今回はHTTPヘッダーインジェクションの解説です。
もっと読む