PHP文字列のエスケープ

PHP文字列をテキストとして出力したい場合もあります。PHPの文字列型はバイナリセーフなのでどのようなデータでも保存可能ですが、プログラム中でPHP変数をPHPのテキスト(リテラル)として出力するにはaddslashes()によるエスケープ処理が必要です。

【重要】エスケープ/API/バリデーション1は出力先に合った方法でないと意味がないです。一口にHTMLと言っても複数の”コンテクストがあります。

  • JavaScript(識別子、変数など)、CSS、タグ属性名、タグ属性値(URIコンテクストに特に注意。BASE64、JavaScriptを使う場合もある)

があります。
SQLクエリと言っても

  • 引数(更にLIKE、正規表現、JSON、XMLなどに別れる)、識別子、SQL語句

などがあります。全てのテキストインターフェースにコンテクスト2があります。
それぞれの”コンテクスト
に適切なエスケープ/API/バリデーションを利用しなければ意味がありません

“PHP文字列のエスケープ” の続きを読む

フィルター/デコード時のセキュリティ対策の鉄則

ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編 ではバリデーション時の注意点をまとめに書きました。

ホワイトリスト型のバリデーションを行う場合でも以下の項目に注意しなければなりません。

  • 特殊な意味を持つ文字を許可する場合、細心の注意を払う
  • そもそも特殊な意味を持つ文字は許可しない方が良い
  • 絶対の自信が無いのであれば、特殊な意味を持つ文字を許可してはならない

ブラックリスト型(サニタイズ型)のセキュリティ対策クイズ 解答編 でパストラバーサルを禁止するようなフィルター処理(ブラックリスト型サニタイズ処理)は基本的には行うべきではありません。しかし、どうしてのフィルター/デコード処理が必要になる場合があります。
“フィルター/デコード時のセキュリティ対策の鉄則” の続きを読む

JSONのエスケープ

追記:最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。

JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。

PHPにJSON形式のデータに変換するjson_encode関数json_decode関数をサポートしています。

JSON関数がサポートされている話は簡単!となれば良いのですが、 いろいろ考慮しなければならない事があります。

TL;DR;

json_encode()を利用する場合

と利用します。これでもまだ最適なエンコード方式とは言えませんが、デフォルトとして最低限必要なオプションが

JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT

です。

JSONデータの文字エンコーディングは基本UTF-8です。UTF-8文字データは”予めバリデーションしておく”必要があります

“JSONのエスケープ” の続きを読む

RailsのJavaScript文字列エスケープ

RailsはJavaScript文字列エスケープメソッドをサポートしています。JavaScript文字列エスケープのエントリで様々な議論があったようです。弊社ではRailsアプリのソースコードも検査しているので、参考としてRailsのソースコードを確認したことを追記をしたました。Rails開発者に直して頂きたいので独立したエントリにしました。

参考:

“RailsのJavaScript文字列エスケープ” の続きを読む

XPathクエリ(2)

XPathクエリ(1)の続きです。

現在のPHPのXPathクエリの問題はXPath 1.0である事です。通常の仕様書であれば特殊文字のある文字列の場合はエスケープ方法やエスケープAPIが定義されています。エスケープ方法が定義されていなければ「特殊文字を入力することができない」からです。エスケープ方法が無い場合は「エスケープが必要ないAPI」を用意すべきです。
“XPathクエリ(2)” の続きを読む

SQL識別子のエスケープ

SQLのリテラルはエスケープが必要であることは広く認知されていると思います。しかし、識別子のエスケープはあまり広く認知されていないように思います。

PostgreSQLの場合、識別子のエスケープAPI(libpqのPQescapeIdentifier)が提供されておりPHPでもpg_escape_identifier()として利用できます。PostgreSQLの場合は”(ダブルクオート)で識別子を囲むことにより、ダブルクォート無しでは利用できない文字(例えば日本語)も識別子に利用できるようになります。
“SQL識別子のエスケープ” の続きを読む

LDAPエスケープ – PHPのldap_escape関数

OWASP TOP10の1位のセキュリティ脅威はインジェクションです。

https://www.owasp.org/index.php/Top_10_2013-A1-Injection

SQLインジェクション、コマンドインジェクションはリファレンスとして掲載されていますが、何故かLDAPインジェクションは掲載されていません。しかし、OWASPの別の文書では簡単に解説されています。

“LDAPエスケープ – PHPのldap_escape関数” の続きを読む

セッションID管理は結局どうすれば良いのか?

脆弱性やセキュリティ対策について技術的な話ばかりしていたので「それで結局PHPのセッション管理どうすれば良いの?」と思われた方も多いと思います。簡単にまとめます。漏れや追記した方が良い事などがあったらご指摘ください。

“セッションID管理は結局どうすれば良いのか?” の続きを読む

プログラミングではホワイトリスティングが基本

ホワイトリスト方式の優位は神話」と題するエントリに私のブログホワイトリストはどう作る? が引用されている事を教えていただきました。

ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

誤解されないように書こうとすると、どうしても長文になります。暇な方だけお付き合いください。

参考: セキュリティを論理的に構築する方法 (こちらは科学的なセキュリティの基本構造の作り方の話です。ぜひどうぞ) “プログラミングではホワイトリスティングが基本” の続きを読む

ホワイトリストはどう作る?

まずホワイトリストの基本中の基本は”デフォルトで全て拒否するであることに注意してください。全て拒否した上で許可するモノを指定しないとホワイトリストになりません

例えば、CSPはホワイトリストで不正なJavaScriptの実行を防止する仕組みです。2016年のGoolgeの調査によると95%のCSP定義が、実際にはJavaScriptインジェクション脆弱性の防止に役立っていない、との調査結果を発表しています。原因はホワイトリストの作り方の基本、全て拒否した上で許可するモノを指定する、を理解していないことにあると考えられます。1

私はいつも基本的に能動的なセキュリティ対策2を選択するようにお勧めしています。能動的なセキュリティ対策とは全ての入力値の厳格なバリデーション処理であり、出力時に過剰とも言えるエスケープ処理です。入力/出力の両方にホワイトリスティング対策をお勧めしています。3

“ホワイトリストはどう作る?” の続きを読む

SET NAMESは禁止

MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。(PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります)この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。

Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。

PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。

ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。

脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES(PostgreSQLのSET CLIENT_ENCODING等も)は禁止」です。

PHPのMySQL:

PHPのPostgreSQL:

PHPのPDO:

Rails: