Webアプリは基本的にテキストインターフェースを利用して構築します。HTML、JSON、SQL、XML、XPath/LDAPクエリ、HTTP、SMTP、これら全てテキストインターフェースです。 今日はインターフェースとテキストインターフェースの基本を紹介します。

インジェクション攻撃には様々な手法があります。メモリ管理をプログラマが行うC言語などではメモリにインジェクションするバッファローオーバーフロー／アンダーフロー、テキストベースのインターフェースではテキストインジェクション（JavaScriptインジェクション、SQLインジェクションなど）があります。 これらのインジェクション脆弱性はなぜ発生するのでしょうか？…

SANS TOP 25 の解説はもっと後で行うつもりでした。しかし、現在のアプリケーション開発者向け教育に対する疑念のエントリへの反響が大きいようなので書くことにしました。 やるべきセキュリティ対策には優先順位があります。効果が大きい対策から行うべきです。セキュリティ対策は全体的に行うべきものですが、最も効果的な対策を除いて対策を行うようでは全体的な対策など…

OSコマンドインジェクションを防ぐための、OSコマンドのエスケープはSQLのエスケープに比べるとかなり難しいです。 難しくなる理由は多くの不定となる条件に依存する事にあります。

プログラムからOSコマンドを実行する場合、エスケープ処理を行わないと任意コマンドが実行される危険性があります。 今回はOSコマンドのエスケープについてです。

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

昨日のブログでは.NETにはSQLのエスケープAPIが無いので、セキュリティ対策として本末転倒な状態になっている事を紹介しました。もう一つXPath 1.0の失敗例を紹介します。

ブラックリスト型（サニタイズ型）のセキュリティ対策クイズ 解答編 ではバリデーション時の注意点をまとめに書きました。 ホワイトリスト型のバリデーションを行う場合でも以下の項目に注意しなければなりません。 特殊な意味を持つ文字を許可する場合、細心の注意を払う そもそも特殊な意味を持つ文字は許可しない方が良い 絶対の自信が無いのであれば、特殊な意味を持…

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

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

出力先のシステムが同じでも、出力先が異なる場合はよくあります。これを意識していないとセキュリティ問題の原因になります。 (さらに…)

JavaScript文字列のエスケープの解説というか補足です。 (さらに…)

サーバー側のプログラムでJavaScriptの文字列にデータを出力するケースはよくあります。このような場合、エスケープ処理を行うことが必須です。JavaScript文字リテラルは次のように定義されています。（ECMAScript 5.1） (さらに…)

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

XPathはXML文書をクエリして要素を取り出す仕組みです。XML文書を検索して結果を返します。 SimpleXMLにはxpathメソッドが用意されています。