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