ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション 〜 ただし出力対策も必須です 〜
(Last Updated On: 2019年2月18日)入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？ ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。 厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。 重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。ど
徳丸浩氏との長年の議論に終止符 – 論理的／体系的セキュリティとそれ以外
(Last Updated On: 2018年8月4日)私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。 徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「ア
間違いだらけのHTTPセッション管理とその対策
(Last Updated On: 2018年10月12日)HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。 まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。 参考： 知らないと勘違いする「合成の誤謬」の罠 開発者は必修、SANS TOP 25の怪物的なセキュリ
PHP本体でタイミング攻撃を防御できるようになります
(Last Updated On: 2021年3月25日) PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。 タイミングセーフな文字列比較関数はhash_equalsとして実装されました。 http://php.net/manual/es/function.hash-equals.php タイミング攻撃とは タイミング攻撃とは、コンピュータが動作する時間の違いを測って攻撃する、サイドチャネル攻撃（副作用攻撃）と呼ばれる攻撃手法の１つです。HTTPSの圧縮の副作用を利用したサイドチャネル攻撃が有名です。 コンピュータの動作時間、温度、音、電子ノイズ、電力使用量など、アルゴリズム自体の脆弱性を攻撃するのではなく副産物を利用する攻撃方法でサイドチャネル攻撃の一種です。
PHP最速フレームワークPhalconのインストール
Framework / Memory Usage (mean, megabytes per request) [lessis better]Memory Usage(MB)ZendSymfonyYiiLaravelKohanaCodeIgniterFuelPhalcon0.40.81.21.62.0 参考 Phalcon PHPとSails Node.jsのベンチマーク Phalcon 1.3 と 2.0のベンチマーク Phalconモジュールのインストール ここではCentOS/Scientific Linuxでのインストール例を紹介しますが、マニュアルにはWindows/OSXなどのインストール手順も記載されています。PhalconはC言語で記載されているのでPHPがビルドできる環境でなければなりません。つまり、CentOSなどであればgccなどのビルドツール、php-develなどの
Rails4セキュリティ リローデッド（仮）
(Last Updated On: 2018年8月8日)前回公開したRails4セキュリティのスライドは誤解をされる可能性があるのでは？と指摘される方も居たので「Rails4セキュリティ リローデッド」として追加情報を加えたスライドを作ろうかと思っていました。確かに、今見直したら肝心な所で追加し忘れてる部分があって誤解しやすい、というか言いたい事が分からないかも知れません。 入力パラメータをバリデーションするとは、バリデーションするメソッドを作ってバリデーションする、ことです。必須・許可設定だけだとモデルに渡すデータがどれかしか分かりません。許可設定と同時にバリデーションする事が良い、という事です。少なくともここだけは直した方が良さそうです。 あまり時間が取れなかったのでスライドを作るために作ったメモを取り敢えず公開します。スライドにして欲しいという方が多ければスライドにするかも知れません
RealIP Module for PHP
(Last Updated On: 2018年8月14日)リバースプロキシの背後にあるPHP用に$_SERVER[‘REMOTE_ADDR’]をX-Real-IPやX-Forwarded-Forヘッダに設定されたIPアドレスに書き換えるRealIPを書きました。 https://github.com/yohgaki/realip 少しGoogleで検索しても見つからなかったので作ったのですが、既にありそうな気がします。 PHPスクリプトで書き換えても良いのですが、アプリをバージョンアップした時に忘れる可能性があります。プロキシ・Webサーバで何とかする方法もありますが、プロキシ・Webサーバの仕様に合わせた設定が必要だったり、と不便な所もありモジュールの方が便利なので書きました。同じ事をするには他の方法がありますが、必要な方はどうぞ。 多分、PHP5.2でもコンパイルできると思います。コン
PHPのSession Adoption脆弱性
(Last Updated On: 2018年8月13日)PHPのセッションモジュールはセッションアダプションに脆弱なのですが、開発者の理解が得られず何年間も放置されています。 セッションアダプション脆弱性： 未初期化のセッションIDを受け入れてセッションを確立する脆弱性。 PHPのセッションIDはデフォルトでドメイン指定無し、パスは/に設定されています。専用サイトならこれであまり困ることは無いのですが、複数のアプリケーションやユーザが利用するようなサイトでは問題になります。 例えば、Chromeはパスよりドメインが優先されるのでドメインを利用したセッションIDの固定化などが起きます。IEではドメインよりパスが優先されるのでパスを利用したセッションIDの固定化などが起きます。 session_regenerate_id()を使えばOK、と考えている人も多いようですが既に設定済みのクッキーの
もうバージョンアップで困らない – PROVE for PHP
(Last Updated On: 2018年8月14日)昨年のPHPカンファレンスで紹介したPORVE for PHP 開発版の公開を始めました。PROVE for PHPはこんなテストが出来ます。 PHPをアップデートしてアプリに影響が無い事を検証する PHPアプリをアップデートしても以前と同じように動作する事を検証する 使い方もとても簡単です。 テストケースの作成はブラウザからアプリを利用するだけ ロードバランサを用いて実運用サーバからのテストケースも作成可能 テストの実行はプログラムを実行するだけ 違いが在った場所はプログラムの何処か確実＆簡単に判明 http://www.provephp.com/ 現状 CUIとコマンドツールでの管理のみ GUI（Web、GTK）は順次整備予定 PROVEを利用すればPHPのセキュリティパッチがリリースされた場合に、アプリケーションの動作チェック
phpのescapeshellcmdの余計なお世話を無くすパッチ
(Last Updated On: 2018年8月13日)徳丸さんのブログでescapeshellcmdの余計なお世話の件が指摘されていたのでパッチを作りました。これmagic quoteと同じレベルの余計なお世話なのですが放置されています。個人的にはどのような関数にも全てバリデーション済みの文字列しか渡さないのでセキュリティ問題は発生しないのですが、UNIX系OSではペアとなる”と’はエスケープしない仕様に気が付いていないプログラマも多いかもしれません。 先ほど「UNIX系OSでは」と書きましたがWindowsでは異なる動作をします。この関数は仕様がいい加減でWindowsの場合は”と’も問答無用でエスケープします。（加えて%もエスケープします）ですから、徳丸さんが指摘された問題はWindowsを使っていれば発生しません。UNIX系とWindowsで動作が異なる、という厄介な関数でもあり
Mac PortでApache/PostgreSQL/MySQL/PHPを使えるように設定する
(Last Updated On: 2018年8月14日)OSX標準のApache/PHPでPostgreSQLやMySQLを使えるようにしても良いのですが、いろいろカスタマイズしたい場合はMacPortsの方が便利だったりします。インストール手順が古かったりするブログもあったので（手順が抜けているかも知れませんが）最初から書きます。 MacPortsのインストール MacPortsをインストールにはXcode (OSXの開発環境）が必要です。DVDに付属しているXcodeより、Webサイトから最新版のXcodeをダウンロードした方が良いでしょう。 http://developer.apple.com/technologies/tools/xcode.html MacPortsはパッケージまたはソースからインストールできます。 http://www.macports.org/install
PHPが文字エンコーディング攻撃に強い理由 – HTMLエスケープ
(Last Updated On: 2018年8月13日)PHPが文字エンコーディング攻撃に比較的強い理由は入出力の文字エンコーディングのバリデーション（サニタイズ）が行えるだけではありません。PHPが提供するHTMLエスケープ関数が文字エンコーディング攻撃に対して強い事も理由の一つです。 PerlでHTMLエスケープと言えば、<,>,&,”,’をエンティティ変換するコードが一番に見つかります。 「perl html escape」でググると一番に見つかったページは次のページです。このページではまだ3バイトEUCの場合の例、CGIモジュールを使った例も載っているので良い方でしょう。 http://saboten009.blogspot.com/2008/04/perlhtml-xss.html 少し前にPerl, Ruby,Pythonユーザは検索で有用なセキュリティ情報を得られるのか？と
#PHP でもutf8_decodeは使ってはならない
(Last Updated On: 2009年9月22日)Twitterで書いた方が良いようなエントリですが、たまには良いでしょう。 #perl – utf8::decode()ではなくEncode::decode_utf8()を使うべき理由 という記事がありました。PHPにも似た関数、utf8_decodeがあります。PHPでも使ってはなりません。日本人というよりマルチバイト圏で使っている人はほとんどいないはずです。理由はコードを見れば一目瞭然です。 /* All the encoding functions are set to NULL right now, since all * the encoding is currently done internally by expat/xmltok. */ xml_encoding xml_encodings[] = { { "ISO-
セキュリティ対策を行うべき部分 – 自分が作っている部分
(Last Updated On: 2018年8月8日)アプリケーション開発者がセキュリティ対策を行うべき部分とはどこか?当たり前ですがアプリケーションです。アプリケーションとは広い意味でのアプリケーションです。Webアプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。 すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。 例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。 何故、セキュリティが分かり辛いのか?その一つ理由が「セ
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
PHP:既知のセキュリティ脆弱性 – Session Adoption
(Last Updated On: 2018年8月13日)追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。 PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。 セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
PHP開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理
(Last Updated On: 2018年8月13日)これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。 PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。 この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。 escapeshellcmd/escapeshellarg関数ではC99で定義されてるmblen関数を利用しています。一般的なUNIX系システムではmblen関数は利用可能でると考えられるので、問題となる事は少ないと思いますが、PHPではphp_mblenマクロが以下のように定義されています。 #ifndef HAVE_MBLEN # define php_mblen(ptr,
mod rewriteを使用した簡易WAF
(Last Updated On: 2018年8月8日)http://www.0x000000.com/?i=567 にmod rewriteを利用した簡易WAF(Web Application Firewall)の定義例が掲載されています。同じようなアイデアをお持ちの方、既に似たような設定を使われている方も多いとは思います。 簡単なWAFですが、実用性も高いです。例えば、ヌル文字やHTML特殊文字のインジェクションは様々な攻撃で利用されます。アプリケーションで対処が忘れられがちなCOOOKIEやREFER、USER_AGENT等に特殊文字が入っていた場合にアクセスを拒否する部分だけもで導入する価値は十分にあると思います。 元ネタのサイトは英語ですが、解説付きです。 これを入れると問題となる場合もあるので、内容を理解してから利用しなければなりません。 RewriteEngine On Op
PostgreSQL 8.3の全文検索機能（TSearch2）を日本語で利用する
(Last Updated On: 2018年8月13日)PostgreSQL 8.3.0から、ユーザから提供されている追加機能（contrib）として利用できた全文検索機能（TSearch2）が本体に取り込まれました。 本体に取り込まれたため、PostgreSQL 8.3.0以降ではソースから構築する場合に ./configure make make install と実行するだけで全文検索機能が利用できるようになりました。 TSearch2は単語単位で全文検索できます。しかし、日本語のように単語に区切りがない場合、単語に分解（形態素解析）してからインデックス化する必要があります。 # N-gramは使えません。 残念ながら日本語をそのまま扱える機能はPostgreSQL 8.3では実装されていません.しかし、TSearch2(textsearch)を日本語で利用するための追加機能がpg
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
