「PHP×セキュリティ ～セキュアなPHPシステム開発テクニック～」の開催
アシアルではPHP開発者の皆様向けに「PHP開発者向け一歩先を先をいくためのテクニカルセミナー」と題して、6月より、押さえておくべき重要なテクニックや、最近話題のテクニックにテーマを絞って、全5回にわけてセミナーを開催していきます。 PHPが普及し始めた頃においては、PHPは手軽に短期間で開発できる言語として注目を集めました。しかし、数年を経てプログラミング言語としても成熟し、昨今では、大規模なシステム開発に取り入れられるようになり、より強固でセキュアなプログラミング・ノウハウや、メンテナンス性やチーム開発の観点からフレームワークを取り入れた開発が必要とされています。 今回のセミナーでは、「セキュリティ」「symfony」「Flex」「iPhone」の4つのキーワードをテーマにセミナーを開催したいと考えます。 ○ 第１回 セミナー 「PHP×セキュリティ ～ セキュアなPHPシステム開発テ
htmlspecialchars()/htmlentities()について - 2009-10-19 - T.Teradaの日記
id:t_komuraさんの、最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容についてを読みました。 見ていて気になったことが１つあります。 2. EUC-JP …（省略）… (2) \x80 - \x8d, \x90 - \xa0, \xff については、そのまま出力される <?php var_dump( bin2hex( htmlspecialchars( "\x80", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x8d", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x90", ENT_QUOTES, "EUC-JP" ) ) ); va
最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容について - t_komuraの日記
前の記事(Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある)で Shift_JIS ではブラウザによっては XSS が発生する可能性があることを書きました。この問題は、PHP の開発版のスナップショット(snaps.php.net)で修正されたことを確認しましたが、それ以外にも、EUC-JP や UTF-8 について修正が行われました。この件で、行動された方に感謝します。どうもありがとうございました。その後、修正内容について調べましたので、メモしておきます。他の修正点など、何か気付いた方がおられましたら、ぜひ教えてください。 この修正は、PHP 5.3.2/PHP 5.2.12 で反映されることになると思います。実際の修正内容の大半は、以下で行われました。 http://svn.php.net/viewvc?view=revision
PHP :: Bug #49785 :: htmlspecialchars() should check byte sequence more strictly
Strings related Bug Reported by hello@... Tue, 06 Oct 2009 11:40:05 +0000 PHP: 5.3.0, OS: * Description: ------------ Suppose htmlspecialchars() should check byte sequence more strictly for security reasons. An XSS exploit code has been unveiled. http://d.hatena.ne.jp/t_komura/20091004/1254665511 [ja] I wrote a primitive patch. http://iwamot.com/misc/html.c.patch.20091006 I don't know whether it i
htmlspecialcharsのShift_JISチェック漏れによるXSS回避策
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ
Supplementation of Bug #49785
Written by Kousuke Ebihara <ebihara@tejimaya.com>. And thanks to Hiroshit Tokumaru and t_komura. 1. Hiroshi Tokumaru Reports About "How level does htmlspecialchars() check invalid encodings?" Original entry is http://www.tokumaru.org/d/20090930.html [ja] He inspected that the following enhancement is really fixed. 08 Nov 2007, PHP 5.2.5 (snip) - Fixed htmlentities/htmlspecialchars not to accept p
PHP: ユーザーが投稿したデータ - Manual
ユーザーが投稿したデータ 多くの PHP のプログラムで最も脆弱な部分は、言語自体に起因するものではなく、 単にセキュリティを考慮して書かれていないコードの問題です。そのため、 指定したコードの部分の意味を常に時間をかけて吟味し、 予想外の変数が投稿された場合に有り得る損害を確かめる必要があります。 <?php // ユーザーのホームディレクトリからファイルを削除します... または他の誰 // かのディレクトリかも? unlink ($evil_var); // 彼らのアクセスのログを書き込む.. または違うかも? fputs ($fp, $evil_var); // 何かちょっとしたことを実行.. または rm -rf *? system ($evil_var); exec ($evil_var); ?> 常に注意してコードをテストし、Webブラウザから投稿された全ての変数 について次
Re:htmlspecialcharsに関する残念なお知らせ - 平々毎々（アーカイブ）
<追記 date="2009/10/10"> 岩本さんはレポートを2つ上げていたのだが http://bugs.php.net/bug.php?id=49785 http://bugs.php.net/bug.php?id=49814 1つ目の方で対応してもらえたようです。よかった。 私はPHPはぜんぜん詳しくないし、OSSへのバグレポートの経験は1回しかないので、はずしているかもしれない。 htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ） 外国語ならなおさら、できる限りのことをしないと伝わらない – 秋元 こんな感じの内容だったらよかったのかな？せっかくいろんな人が検証したりしてたのに無視されるのももったいない。 PHPのhtmlspecialchars関数について、UTF-8以外の文字エンコーディングでは妥当性チェックが不充分であり、場合によっ
PHPの「守護神」Suhosin
PHPは，数え切れないほどのWebサイトで使われている非常に有名なプログラミング言語である。基本的にはスクリプト言語であり，実行時にコンパイルされる。PHPは非常に多くのコミュニティによって支えられており，様々な機能を提供する膨大な数のオープン・ソース・ライブラリが公開されている。「WordPress」といった人気アプリケーションも，PHPで記述されている。ただし，PHPにもセキュリティの問題は存在する。 PHPのセキュリティ問題は，長年にわたって多くの開発者が問題の修正に取り組んできた。しかし，常に迅速な対応が行われてきたわけではなく，被害を受けるユーザーも存在した。2006年末には，PHP開発者のStefan Esser氏が，この状況に嫌気がさして，PHP Security Response Teamを辞任した。 Esser氏は自身のブログで，「（辞任した理由は）いくつかあるが，最も決
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由
(Last Updated On: 2018年8月8日)Rails+Ruby 1.9では不正な文字エンコーディング攻撃で脆弱にならない理由を詳しく解説されたブログエントリをまっちゃさんのブログで知りました。 入力で特には何もしていない事は知っていたので、出力時のどこかで全体をチェックできるような仕組みになっているのでは？と思っていたのですが、ETagの値を生成するコードの正規表現で例外が発生する、という事だそうです。 なぜRuby 1.9でエラーが起きるのか ActionController::Response#etag= メソッドの定義は下記のとおりです。 def etag=(etag) if etag.blank? headers.delete('ETag') else headers['ETag'] = %("#{Digest::MD5.hexdigest(ActiveSupport
文字エンコーディングの妥当性確認(バリデーション)について - t_komuraの日記
大垣さんからコメントをいただきましたので、最後に追記しました(2009.09.22)。 少し時間が経ってしまいましたが、以下のページを読んで、PHP に関連する部分について思ったことを書きたいと思います。 http://blog.ohgaki.net/char_encoding_must_be_validated http://blog.ohgaki.net/is-char-encoding-problem-difficult 私の理解が間違っていなければ、「Web アプリケーションで文字エンコーディングに関連する問題を無くす」ことを目的として、全ての Web アプリケーション開発者が以下を実行しようという主張だと思います。 全ての入力文字列の文字エンコーディングの妥当性を確認する 文字エンコーディングを厳格に取り扱う データベースなどで「バイナリ」に近い文字エンコーディングは利用しない
htmlspecialchars - 第45回PHP勉強会@関東 :: handsOut.jp
スライド1: htmlspecialchars() についてkomura第45回 PHP 勉強会@関東(2009.08.01) スライド2: 自己紹介1. PHP暦(a) PHP 4.0.4 ~(2002年?)(b) 最近はPHPでスクリプトを書くよりPHPのソースを読んでいる時間の方が長い2. Webページ,日記など(a) t_komuraの日記http://d.hatena.ne.jp/t_komura/(b) 個人的なメモと備忘録http://www.asahi-net.or.jp/~wv7y-kmr/(c) PHPとWebアプリケーションのセキュリティについてのメモhttp://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html(d) PHPのmbstringに関するメモhttp://www.asahi-net.or.jp/~
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか？を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏
何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、（2/3）SQLインジェクションを根絶！セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題：ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『￥』は？」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst
PHPの設定をセキュリティの観点から改善·PHP Security Consortium MOONGIFT
PHPは広く数多のWebサーバでインストールされ、使われている。設定ファイルは殆どそのままで使われていることが多いのではないだろうか。だが4.2より前のバージョンではregister_globalsのデフォルトがOnになっていたなど、利便性とセキュアであることとの関係で潜在的な問題はあるかも知れない。 php.iniのセキュリティチェックに 見直すのはPHPの設定ファイルであるphp.iniだが、多数の設定があるのでぱっと見では設定の善し悪しが分かりづらいかも知れない。そこで使うのがPHP Security Consortiumだ。 今回紹介するオープンソース・ソフトウェアはPHP Security Consortium、PHPのセキュリティ設定を見直すソフトウェアだ。 PHP Security ConsortiumはPHPで作られたソフトウェアで、phpinfo()から得られる情報を使っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
'[PHP-DEV] #49785 htmlspecialchars() should check byte sequence more strictly' - MARC
[cvs] Diff of /php-src/ext/standard/html.c
http://twitter.com/i0n1c/status/4705129319
PHPスクール セキュリティ編 アシアル株式会社