だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ
(Last Updated On: 2015年9月10日)国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。 典型的な攻撃のシナリオは次の通りです。 追記：Tokenizerを使った例に修正しました。 アバダなどの画像ファイルをアップロードできるサイトを探す ローカルファイルインクルードバグを探す 画像ファイルにサイトが利用している言語のコードを埋め込む 攻撃コードを含んだファイルを画像ファイルとしてアップロードする ローカルファイルインクルードバグを利用して攻撃コードを実行する PHPの場合、リモートインクルードバグを攻撃するための攻撃
PHP本体のセキュリティ関連バグは多い? PHP本体のバグはほかの言語（Perl、Ruby、Pythonなど）に比べ体感的に多いと思いませんか? 実際にPHP本体のセキュリティ問題は突出して多くレポートされています。今回はPHP本体にセキュリティ関連バグが多いとされる理由を考察してみます。 セーフモード（safe_mode）機能 safe_mode関連のバグは、PHP本体のセキュリティ問題として最も多くレポートされる問題です。しかし、実際にはsafe_modeは確実なセキュリティ対策を行うための機能ではありません。よくある誤解はsafe_modeについて「共有サーバ環境でユーザがほかのユーザのファイルを参照できなくする機能」であるという勘違いです。safe_modeは同じサーバ上のほかのユーザファイルを盗み見ようとする悪意があるスクリプトから「防御」するための機能ではなく、善良なスクリプト
Webアプリケーションでは、外部からの変数に対して、形式チェック（Validation）を行ないます。PHPでこれを行なう場合に、ありがちなミスをいくつか挙げてみました。 この日記は、がるさんの日記に触発されて書いたもので、いくつかの例を引用しています。 がるの健忘録(2006/11/08) - 素晴らしき自動的な世界〜或いは「型のない」世界〜 型の問題 数値と文字列の比較 <?php $input = "2'; DELETE FROM hoge; --"; if ($input == 2) { // ↑TRUEと評価される がるさんの日記で紹介されていた例に、手を加えたものです。 if文中の式がTRUEになるのは、PHPの「==」演算子が、数値型と文字列型変数を比較する際に、文字列を（かなり強引なやり方で）数値型に変換するからです。変数の比較は、同じ型同士で行なうのが無難だと思います。
PHPで使えるCAPTCHA画像作成ライブラリはいろいろあって分かりにくいので以下にまとめてみました。 最近ではスパムが多すぎて、掲示板等へのCAPTCHA実装は必須のように思えます^^; CAPTCHA (GPLライセンス) サンプル利用方法 1. パッケージダウンロード 2. パッケージ解凍後、同じディレクトリにフォント(*.ttf)ファイルを設置 3. captcha.class.php を開く (2)で配置したフォントのファイル名を変数に設定 $this->Font = './〜.ttf'; 4. example.php にアクセス CAPTCHA 2 (GPLライセンス) サンプル利用方法 1. パッケージダウンロード 2. パッケージ解凍後、同じディレクトリにフォント(*.ttf)ファイルを設置 3. captcha.class.php を開く (2)で配置したフォントのファイ
元々の掲載が日経ソフトウェアのようなので,ほとんどプログラミングなどの知識が無い方への記事だと思います. だから書かなければいけないこと,書くと本質を見失うことなどあり難しいのですが,この記事のバランスには非常に疑問符です. 実際にはコマンドラインで使用するスクリプト言語環境です PHPというと「Webアプリケーション開発の専用言語」と思い込んでいる方がいるかもしれません。しかし,実際にはコマンドラインで使用するスクリプト言語環境です。 「コマンドラインでも使用できる」程度じゃないのかと. PHPのmbstringを使う php.netで配布されているWindows用PHPバイナリは標準でmbstringは使用できません. しかしそれらについてまったく触れられていないので,下記サンプルはぜんぜん動きません, リスト1 mb_language,mb_internal_encodingの指定が
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く