シェルを経由しないOSコマンド呼び出しがPHP7.4で実装された
この記事はPHP Advent Calendar 2019の5日目の記事です。 はじめに 私は6年前に、PHP Advent Calendar 2013として「PHPだってシェル経由でないコマンド呼び出し機能が欲しい」という記事を書きました。その中で、OSコマンドインジェクション対策の根本的かつ安全な対策は「シェルを経由しないコマンド呼び出し」であることを指摘した上で、末尾に以下のように書きました。 PHPコミッタのみなさま、PHP5.6の新機能として、シェルを経由しないコマンド呼び出しの機能を追加できませんか? 現実には当時からPCNTL関数にてシェルを経由しないコマンド呼び出しはできたのですが、当関数の使用が難しいことと、CLI版あるいはCGI版（FastCGIは可）のPHPでないとサポートされていないなどの制限があり、popenやproc_openなど使いやすいコマンド呼び出し関数に
脆弱性は誰のせい? �PHP、MySQL、Joomla! の責任やいかに
11. コードの差分から diff -r -u joomla-3.4.5/libraries/joomla/session/session.php joomla-3.4.6/libraries/joomla/session/session.php --- joomla-3.4.5/libraries/joomla/session/session.php 2015-10-21 17:48:16.000000000 +0900 +++ joomla-3.4.6/libraries/joomla/session/session.php 2015-12-14 14:42:12.000000000 +0900 - - // Check for clients browser - if (in_array('fix_browser', $this->_security) && isset($_SERV
「ケータイキット for Movable Type」のOSコマンドインジェクションの修正 | 水無月ばけらのえび日記
更新: 2016年4月27日11時5分頃 Movable Typeのプラグイン「ケータイキット for Movable Type」にOSコマンドインジェクションの脆弱性があったという話が出ており、J-WAVEの64万件の個人情報流出はこれが原因だったとされています。 J-WAVEでも64万件の個人情報流出の可能性、原因ソフトの利用者は至急パッチ適用を (itpro.nikkeibp.co.jp)「ケータイキット for Movable Type」にOSコマンドインジェクションの脆弱性、利用者は修正バージョンへアップデートを、すでにJ-WAVEへの攻撃で悪用 (internet.watch.impress.co.jp)ケータイキット for Movable Type の脆弱性についてまとめてみた (d.hatena.ne.jp)配布元のアイデアマンズからは、4月22日にまず「緊急パッチファイ
Joomla!の「ゼロデイコード実行脆弱性」はPHPの既知の脆弱性が原因
Joomla!にコード実行脆弱性(CVE-2015-8562)があり、パッチ公開前から攻撃が観測されていたと話題になっています。 Joomlaに深刻な脆弱性、パッチ公開2日前から攻撃横行 「Joomla!」に再び深刻な脆弱性、3.4.6への速やかなアップデートを推奨 パッチ公開の前に攻撃が始まる状態を「ゼロデイ脆弱性」と言いますが、それでは、この脆弱性のメカニズムはどんなものだろうかと思い、調べてみました。 結論から言えば、この問題はJoomla!側に重大な脆弱性はなく、PHPの既知の脆弱性(CVE-2015-6835)が原因でしたので報告します。 exploitを調べてみる 既にこの問題のexploitは公開されていますが、悪い子が真似するといけないのでURL等は割愛します。以下のページでは攻撃の原理が説明されています。 Vulnerability Details: Joomla! Re
PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になる
既にいくつかの記事で指摘がありますが、PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になります。 しかし、ブログ記事等を見ていると、外部由来の値をunserialize関数に処理させているケースが多くあります。 ユースケースの一例としては、「複数の値をクッキーにセットする方法」として用いる場合です。 PHP クッキーに複数の値を一括登録する方法という記事では、以下の方法で複数の値をクッキーにセットしています。 $status = array( "height" => 167, "weight" => 50, "sight" => 1.2 ); setcookie("status", serialize($status)); クッキーの受け取り側は以下のコードです。 print_r(unserialize($_COOKIE['status'])); 出力結果は以下
PHPにないセキュリティ機能
PHPカンファレンス関西2015での私のセッション「PHPに無いセキュリティ機能」のスライドです。 何が無いのか、知っていれば対応できます。 何が問題になっているのか、知っていれば対応できます。 セキュリティ対策は職人技敵（脆弱性対策をコード中に散りばめ、全体を把握しないと安全にできない作り方）ではなく、CERT/SANS/OWASPが推奨するセキュリティ対策を行い、エンジニアリング的（科学的、体系的な作り方）を行う方が簡単かつより安全、高品質なアプリケーションを作れます。 PDFをダウンロードしたい方はブログをご覧ください。 http://blog.ohgaki.net/missing-security-related-parts-of-phpRead less
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
PHPのsetcookie関数で空文字列を設定しようとするとクッキーが削除される
PHPでスクリプトを書いていて、setcookieの第2パラメータ(クッキーの値)の変数をタイプミスしたところ、以下のレスポンスヘッダが送信されていました。 setcookie('A', $misspelled_variable); ↓ 結果 Set-Cookie: A=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT 日付が大昔になっているし、クッキーの値に「deleted」は指定していません。これは、クッキーを削除する時の書き方ですが、PHPでクッキーの削除というと、expiresに過去日付を明示する方法をよく見かけますが、単に第2パラメータを空文字列にすればよかったのか…と思いマニュアルを見たら、一応書いてありました。 http://php.net/manual/ja/function.setcookie.php 陥りやすい失敗 クッキーは
ブラインドSQLインジェクションのスクリプトをPHPで書いたよ #phpadvent2012
この記事はPHP Advent Calendar 2012の20日目です。昨日はTakayuki Miwaさんの「ComposerとHerokuではじめる！PHPクラウド生活」でした。 以前、「『よくわかるPHPの教科書』のSQLインジェクション脆弱性」というタイトルで、同書のSQLインジェクション脆弱性について説明しましたが、SQLインジェクション脆弱性のあるSQL文がDELETE FROMだったので、先のエントリでは、脆弱性の悪用方法としてはデータ（ミニブログの記事）の削除を説明しました。簡単に「全ての記事を削除できる」ので重大な脆弱性ではありますが、個人情報などが漏洩する例ではありませんでした。 このエントリでは、ブラインドSQLインジェクションという技法により、DELETE FROM文の脆弱性から、個人情報を得る手法を説明します。 脆弱性のおさらい ここで、脆弱性のおさらいをしまし
JVN#63650108: Smarty におけるクロスサイトスクリプティングの脆弱性
Smarty は、PHP 用のテンプレートエンジンです。Smarty には、エラーメッセージを出力する際の処理に起因する、クロスサイトスクリプティングの脆弱性が存在します。
PHPのis_a関数における任意のコードを実行される脆弱性(CVE-2011-3379)とは何だったか
少し古いバージョンになりますが、PHP5.3.7および5.3.8のis_a関数には「任意のコードを実行される脆弱性(CVE-2011-3379)」があります。 任意のコードが実行されるとはただならぬ感じですが、このCVE-2011-3379はほとんど話題になっていません。なぜでしょうか。それは、この脆弱性が発現する条件が、レアなケースに限られるからです。 このエントリでは、CVE-2011-3379について少し詳しく説明することを通して、脆弱性情報の見方について考えてみます。 is_a関数とis_subclass_of関数 PHPにはis_a関数とis_subclass_of関数というよく似た関数があります。以下PHP5.3.6までの「元々の」仕様について説明します。 is_a関数は、2つの引数をとり、第1引数のクラス（インスタンスで指定）が、第2引数のクラス（クラス名で指定）またはそのサ
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
2. 本日お話しする内容 • 鉄則1: PHP自体の脆弱性対処をしよう • 鉄則2: Ajaxの脆弱性対処をしよう • 鉄則3: 競合条件の脆弱性対処をしよう • 鉄則4: htmlspecialcharsの使い方2012 • 鉄則5: escapashellcmdは使わないこと • 鉄則6: SQLインジェクションの対処 • 鉄則7: クロスサイト･スクリプティングの対処 • 鉄則8: クロスサイト・リクエスト・フォージェリの対処 • 鉄則9: パスワードの保存はソルトつきハッシュ、できればスト レッチングも • 鉄則10: 他にもたくさんある脆弱性の対処 Copyright © 2012 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍
PHP 5.3.9 の脆弱性に関する注意喚起
各位 JPCERT-AT-2012-0004 JPCERT/CC 2012-02-06 <<< JPCERT/CC Alert 2012-02-06 >>> PHP 5.3.9 の脆弱性に関する注意喚起 https://www.jpcert.or.jp/at/2012/at120004.html I. 概要 PHP 5.3.9 の脆弱性情報が 2012年2月2日に公開されました。この脆弱性を 使用された場合、結果として遠隔の第三者によって任意のコードを実行される 可能性があります。 JPCERT/CC では本脆弱性を使用する実証コードが公開されていることを確認 していますので、管理するサーバにおいて PHP を使用している場合は、 PHP Group が提供する修正済みバージョン (PHP 5.3.10) へアップデートする ことをお勧めします。 PHP 5.3.10 Released!
Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策
28C3(28th Chaos Communication Congress)において、Effective Denial of Service attacks against web application platforms（Webプラットフォームに対する効果的なサービス妨害攻撃）と題する発表がありました（タイムスケジュール、講演スライド）。 これによると、PHPをはじめとする多くのWebアプリケーション開発プラットフォームに対して、CPU資源を枯渇させるサービス妨害攻撃(DoS攻撃)が可能な手法が見つかったということです。この攻撃は、hashdos と呼ばれています。 概要PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。 連想配列の実装には
【緊急リリース】すべてのバージョンの OpenPNE に存在する、クライアント側キャッシュを経由した非公開情報漏洩の問題への対応のお知らせ (OPSA-2011-004)｜OpenPNE
OpenPNE 2 および OpenPNE 3 には、認証後のページをクライアントに送出する際に、キャッシュ制御に関する指示をおこなっていなかったため、ユーザの利用する環境によっては、非公開情報を含むページの情報がキャッシュ経由で他人に表示されてしまう問題が存在します。 本日 9 月 15 日 (木)、この問題の対策版リリースをおこないましたので、内容を確認のうえ、バージョンアップまたはパッチの適用をお願いいたします。 なお、 OpenPNE 2 については、設定によりこの問題を回避することが可能ですので、本エントリで併せて回避方法を解説していきます。 本問題について 影響を受けるシステム 以下のいずれかの条件に当てはまる場合、本問題の影響を受けます。 OpenPNE 3.0.8.4 以下、 3.2.7.5 以下、 3.4.15 以下、 3.6beta13 以下を利用しているサイト Ope
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
Smarty3で$smarty->default_modifiers[] = ‘escape:”html”‘;指定時のnl2brの書き方 | ユメーディア blog
Smarty3で$smarty->default_modifiers[] = ‘escape:”html”‘;を指定した上で、 textareaから登録されたデータを画面表示させる際に、 textareaでの改行に合わせて<br />を出力させようとしたら、ちょっとハマったのでメモ。 入力されたデータ($textarea_data)は 「明日 晴れると いいなぁ・・・」 とします。 {$textarea_data|nl2br} とした時は 『明日<br /> 晴れると<br /> いいなぁ・・・ 』 と<br />までエスケープされて出力されます。 かと言って、 {$textarea_data|nl2br nofilter} とした時は 『明日 晴れると いいなぁ・・・ 』 と<br />がタグとして出力され見た目的にはOKなのですが、これだとtextarea
PHP unserialize()が__destruct()を実行する？
CakePHPのセキュリティホール（まだの方はご対応を！）から、unserialize()が話題になっています。 このセキュリティホールは、外部から送信された値をチェックせずにunserialize()したことが引き金になっており、安全でない値をunserialize()することの危険性が指摘されています。 下記エントリでは、コードを交えてunserialize()から__destruct()が実行される過程が解説されています。 PHP5 __destruct() and unserialize() function – TokuLog 改メ tokuhirom’s blog 念のための補足なのですが、unserialize()から__destruct()が呼ばれるわけではありません。 下記コードは、PHP5.3.3で実行しています。 unserialize()から実行される関数 unse
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/webtech/20130315/2.html