PHP の脆弱性に関する注意喚起
各位 JPCERT-AT-2012-0016 JPCERT/CC 2012-05-09(初版) 2012-05-10(更新) <<< JPCERT/CC Alert 2012-05-09 >>> PHP の脆弱性に関する注意喚起 https://www.jpcert.or.jp/at/2012/at120016.html PHP Group より php-cgi のリクエスト処理に関する脆弱性が公開されました。 PHP Group によると、Web サーバ上に PHP を CGI モードで動作させている場合、 遠隔の第三者が PHP スクリプトのソースコードを閲覧したり、Web サーバの権 限で任意のコードを実行したりする可能性があるとのことです。 本脆弱性を使用する攻撃手法が公開されています。「III. 確認方法」を参考 に、自身が管理するサーバが本脆弱性の影響を受けるか確認し、影響を受
安全でないPHPプログラムの作り方
このブログの目的は、意識的に、自由自在に、効率的に、安全でない(脆弱性のある) PHPプログラムを作成できるようになることです。 無意識に脆弱性のあるプログラムを作るという状態がなくなることを目指しています。意識的に脆弱性を入れられるようになれば、今までと同じ作業時間でも多くの脆弱性を作れるようになるでしょう。 そのような状態になれれば、脆弱性は、すべて意識されたものとなります。もし望むなら、脆弱性のない安全なプログラムを作ることもできるでしょう。そんなことを望む人がいるかどうかはわかりませんが。(笑) ただし、そのような状態になるのは、正直言って簡単ではありません。 脆弱性のあるログインフォーム の解説です。ソースコードをまだ見られていない方は、まず、脆弱性のあるログインフォーム をご覧ください。 補足ですが、コメントにあったように URL を http://localhost/this
配列データを一気にクロスサイトスクリプティング対策する関数(php) | とりさんのソフト屋さん
福井のソフトウェア会社です。AccessやExcel、.NETソフトウェア開発、WordPress等を使用したホームページのシステム化、PCサポート・メンテナンス、コンサルなどを行っています。 投稿日 2009 年 3 月 28 日 – 3:28 PM カテゴリ: php プログラムを書く上でXSS(クロスサイトスクリプティング)対策はとても面倒であり、また抜けが多いし、確認するのに人を大量投入もしくはツールを導入出来れば良いが納期と予算的な兼ね合いでそうもいかない。 「XSS対策に関しては出力時に処理するのが最善の策。最初期にやるのが次善の策。」とXSS対策に詳しい方が述べている。 いろんなサイトを見ると一気にデータを処理するのではなく変数を出力時に個別にエンティティ化させている。 しかし、出力時に個別に処理するのは、人為的なミスが混入する割合が高いと個人的に考えている。 予算も人も期
PHP: PHPの隠蔽 - Manual
PHPの隠蔽 一般に隠蔽という手段はセキュリティとしては弱いものだと言われています。 しかしこうした手法が望ましい場合もあります。 PHP を隠すための簡単な技法がいくつかあり、 システムの弱点を見つけようとする攻撃を遅延させることができる可能性があります。 php.ini ファイルで expose_php を off と設定すれば、 攻撃者が利用可能な情報を減らすことができます。 他の手段は、ApacheのようなWebサーバーで PHPに異なるファイル形式をパースさせるように設定することです。 これは、.htaccessディレクティブまたは Apacheの設定ファイル自体で指定します。 これにより、紛らわしいファイル拡張子を使用可能です。
"セキュアな PHP アプリケーションを作成するための 7 つの習慣" を全力でDISる - id:k-z-h
セキュアな PHP アプリケーションを作成するための 7 つの習慣まずタイトルからして嫌なにおいがしたんだが、最初の項読んだだけで頭いたくなってきた。こんなクズみたいな記事を「すごい！さすがIBM様やでー！」とか、「感心した！みんなこれをみて学ぶべき！」とか言って有り難がってブクマってる奴らは脳が腐ってるんじゃないのか。 なにがクズかって言うと、全体的に中途半端。それぞれの留意点についてコードを見せて具体的な事例を挙げてるけど例示されてるコードの質が半端なく低いそもそも前提条件からしてずれてる結局具体的な対処法が書かれていない書かれている対処法がダメダメ対処法だけ書いてあってなぜそうするのかの理由が書いていない 特に最後のが重要で、「XXXしちゃいけません！」とか「XXXしましょう！」とだけ書いてると、理由がわからないのでその対処が正しいのかわからない。正しくなければもちろん問題だし、正し
「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - 徳丸浩の日記(2008-10-29)
id:hasegawayosuke氏にそそのかされるような格好で、「はじめてのPHPプログラミング基本編5.3対応」という書籍を購入した。 本書は、ウノウ株式会社の下岡秀幸氏、中村悟氏の共著なので、現役バリバリのPHP開発者が執筆しているということ、下記のようにセキュリティのことも少しは記述されているらしいという期待から購入したものだ。 目次から抜粋引用 07-07 Webアプリケーションのセキュリティ [セキュリティ] 08-04 データベースのセキュリティ [SQLインジェクション] 09-13 セキュリティ対策 [セキュリティ] 本書をざっと眺めた印象は、「ゆるいなぁ」というものであるが、その「ゆるさ」のゆえんはおいおい報告するとして、その経過で致命的な脆弱性を発見したので報告する。 問題の報告 それは、本書P280に登場する「SQLインジェクション対策用の関数(dbescape)」
書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - Do You PHP はてブロ
via. 書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - 徳丸浩の日記(2008-10-29) データベースのセキュリティについて徳丸浩氏に指摘頂きました。ありがとうございます。 問題の報告 それは、本書P280に登場する「SQLインジェクション対策用の関数(dbescape)」だ。 ： そう、この関数にはバグがある。 こちらでも確認しましたが、第9章(p.280)で用意したSQLインジェクション対策用の関数(dbescape)にバグがあり、SQLインジェクション対策が不十分だと分かりました。 あるいは、SQLiteの使用をあきらめ、MySQLを使ってもよかった。本書のカバーには「MySQL(データベース)」とある(これはCD-ROMに MySQLが添付されているということらしい)。WindowsでもMySQLは動作するし、実務でも利用機会はMyS
確認されているだけでも攻撃が毎分1.5件，PHPアプリ狙う攻撃が大量無差別型に
前回，SQLインジェクション攻撃の増加傾向を紹介した。そのほかにも日本IBMの東京セキュリティオペレーションセンター（以下，東京SOC）では，PHPで作成されたWebアプリケーションを狙った攻撃を大量に確認している。特に，リモート・ファイル・インクルード（RFI）攻撃は非常に多く，東京SOCでは1分当たり1.5件の頻度でRFI攻撃を検知している。これらは自動化された攻撃ツールによる大量無差別型の攻撃だと考えられる。今回は，現在のRFI攻撃の動向を紹介する。 RFI攻撃は，Webアプリケーションのぜい弱性を利用して標的とするサーバーに，外部のサーバーから悪意あるファイルを読み込ませる攻撃である。攻撃者は標的サーバー上で当該ファイルに記述された任意のコードを実行させる。
徳丸浩の日記 - 書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性
_書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性 「PHP×携帯サイト デベロッパーズバイブル」という携帯サイト開発のノウハウを解説した書籍が今月初頭に発売され、話題になっている。Amazonの「インターネット・Web開発」カテゴリで1位ということで、たいしたものだ。私も発売前から予約して購入した。 私がこの書籍を購入した動機は大きく二つある。一つは、携帯サイトの最新の開発ノウハウをまとめた書籍に対する期待をしていたということ。もう一つは、セキュリティに対する記述がどの程度あるのかを見てみたいというものだった。 このうち、前者については、期待は叶えられた。非常に盛りだくさんのテーマが手際よくまとめられていて、かつ読みやすい。あまり原理・理屈のことは書いていないが、開発現場では、コピペの情報源として重宝されることだろう。 しかし、問題はセキュリティについての記述である。 本社のサ
session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年08月18日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのsession_set_save_handlerのリファレンスを眺めていて、ふと、これはパス・トラバーサルの脆弱性があるのではないかと思いました。 function read($id) { global $sess_save_path; $sess_file = "$sess_save_path/sess_$id"; // ← ファイル名の組み立て return (string) @file_get_contents($sess_file); } function write($id, $sess_
未修正のPHP脆弱性を募集
(Last Updated On: 2018年8月13日)PHP4のサポート終了に伴い、幾つかの未修正のセキュリティホールについてPHP Security Response Teamとやり取りしています。 ついでなので出来る限り多くの脆弱性が修正されるようにしたいと考えています。PHP4.4.8, PHP 5.2.6で未修正の脆弱性やセキュリティ上の問題をご存知の方は是非教えて下さい。 現時点はどの脆弱性をレポートしているのか書けませんが、もしPHP本体やモジュールで修正されていない脆弱性をご存知の方は教えて頂けると助かります。メールやこのブログのコメント、このブログのContactページ等からご連絡ください。 結果については後日このブログにて公開します。
絶対に公開してはいけないPHPプログラミング
絶対に公開してはいけないPHPプログラミング ネタ元：AjaxMail：Ajaxを活用したフリーPHPメールフォーム これはひどいのに誰もつっこみを入れていないので、ツッコミを入れておきます。 セキュリティーフィックスされたました。 AjaxMailを利用しているサイトはスパムメールの踏み台にされます。 送信プログラムであるsendmail.phpの 150行目でPOSTで受け取ったアドレスをそのまま変数に入れて、 $reto = $_POST['email']; 168行目で直接メール関数に利用している。 if($remail == 1) { mail($reto,$resbj,$rebody,$reheader); } ありえない。 mail関数の第一引数には送信先のメールアドレスを設定できるのですが、カンマ区切りで複数のメールアドレスが指定できます。 リターンメールの性質上、リファラ
今も新規開発され続けるPHP 4アプリケーション - ockeghem's blog
この日記をご覧の方には先刻ご承知のことだろうが、去る7月13日に、PHP 4のEOL(End Of Life)アナウンスが公式に宣言された*1。 これによると、PHP 4のメンテナンスは2007年12月31日まで、重大なセキュリティホールへの対応も2008年8月8日までとなっている。このため、既存の膨大なPHP 4アプリケーションのマイグレーションをどうするかは大きな課題である。 ここまでは皆さんご存知の情報であろう。 しかし、PHP 4アプリケーションは今も開発され続けている。私がそれを知ったのは、Webアプリケーションの脆弱性診断をしているからである。診断にてPHPなどの脆弱性を発見した場合はこれまでも都度報告していたが、2007年7月13日以降は、PHP 4を使っているだけでも、(脆弱性ではないが)上記情報を報告し、PHP 5への移行を推奨してきた。そういうレポートを書く際には、「き
[セキュリティ]画像へのPHPコマンド挿入 ― T.Teradaの日記
だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第1章 総論：より良いWebアプリケーション設計のヒント
ここで述べるのは、脆弱性が生まれにくいWebアプリケーションを構築するために設計段階、あるいはそれ以前の段階で考慮しておくとよい事項の例である。 (1) 開発環境の選択 1) プログラマが脆弱性をつくり易い環境を避ける 今日のWEBアプリケーション開発環境は、プログラミング言語の処理系に加えて、開発フレームワークやコンテンツ管理システム（CMS）、さらに外部のテンプレート言語までを加えた総合的な環境となってきている。 短時日で素早くサイトを立ち上げることを目的として、「軽量言語」と呼ばれる各種スクリプト言語が標準で備えているWEBアプリケーションを手軽に開発するための機能やライブラリをそのまま利用することは悪くない。しかし、その手軽さ故に、セキュリティの観点からは多くの脆弱性を生んできた経緯がある。 例えば、下記の事例が挙げられる。 PHPの4.1以前のバージョンの環境は、「registe
画像ファイルに PHP コードを埋め込む攻撃は既知の問題
(Last Updated On: 2015年9月10日)国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。 典型的な攻撃のシナリオは次の通りです。 追記：Tokenizerを使った例に修正しました。 アバダなどの画像ファイルをアップロードできるサイトを探す ローカルファイルインクルードバグを探す 画像ファイルにサイトが利用している言語のコードを埋め込む 攻撃コードを含んだファイルを画像ファイルとしてアップロードする ローカルファイルインクルードバグを利用して攻撃コードを実行する PHPの場合、リモートインクルードバグを攻撃するための攻撃
Security Entries by Date - (CGISecurity.com)
Looking for something else or having a hard time finding a story? We recently moved things around so please use the search bar on the right!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPでのセキュリティ対策についてのメモ - Liner Note
PHP開発補助製品 | アシアル株式会社
