！【緊急】開発言語PHPに“最悪”のセキュリティ・ホール，全ユーザーは今すぐ対処を

　Hardened-PHP Projectは10月31日（現地時間），
オープンソースWebアプリケーション開発言語PHPの
深刻なセキュリティ・ホールを警告した。

リモートからPHPスクリプトを実行される
「今まで見つかった中でも最悪のセキュリティ・ホール。
全てのPHPユーザは今すぐ対処を行う必要がある」（日本PHPユーザー会 大垣靖男氏）。
PHP4の4.4.0以前のバージョン，PHP5の5.0.5以前のバージョンが影響を受ける。
対策はパッチを適用することなど。

　このセキュリティ・ホールは，ファイル・アップロードでグローバル・シンボル・テーブル$GLOBALSが
書き換えられることにより，リモートからPHPのスクリプトを実行される可能性があるというもの。
PHPの標準ライブラリであるPEARなどがこのセキュリティ・ホールにより攻撃される可能性がある。
そのほか「影響を付けるシステムやアプリケーションは数え切れないほど多い」
（Hardened-PHP Project）。
PHP 4.3.10以下は$_GET，$_POST，$_COOKIEのセキュリティ・ホールが存在しておりさらに危険という。

　対策は，PHPの場合4.4.1以上にアップグレードすること。PHP5の場合
「日本時間11月2日時点ではPHP5用のパッチまたは対策済みリリースは公開されていない」（大垣氏）。
大垣氏がPHP 5.0.4またはPHP 5.0.5用のセキュリティ・パッチを公開している。

　ただし，PHP4.4.xではソースコード埋め込み定数参照の仕様が変更されているため，
プログラムが動作しなくなる場合がある。大垣氏がPHP 4.3.11用のセキュリティ・パッチを公開している。

http://itpro.nikkeibp.co.jp/article/NEWS/20051102/223939/

２

一等自営業阻止

また松下幸之助か！

ソニー、シマンテックと共謀しウィルス散布、F-Secure社員が感染し発覚
http://news19.2ch.net/test/read.cgi/news/1130905571/

PHPってんなに？

>5

PHPってパナソニックのことか？

自鯖のPHPアップデートしなきゃ駄目か。万度草。
CMS使ってれば、自動的にアップデートしてくれないのかな。

ありゃ、こりゃ明日は忙しくなりそうだな。

こんどはPHPか

Ｐ　ペニス
Ｈ　ヒップ
Ｐ　ペニス

PHP？
自己啓発のやつ？

文句あるなら新しい言語でも作ってみろ下手くそ。

>6
PHP Hypertext Preprocessorの略だよ
↑のPHPもPHP Hypertext Preprocessorの略
　　　　　　　　↑のPHPもPHP Hypertext Preprocessorの略
　　　　　　　　　　　　　　　　↑のPHPもPHP Hypertext Preprocessorの略
　　　　　　　　　　　　　　　　　　　　　　　　↑のPHPもPHP Hypertext Preprocessorの略
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　↑のPHPもPHP Hypertext Preprocessorの略
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　↑のPHPもPHP Hypertext Preprocessorの略
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　

鯖管がんばれ〜
おれの会社は開発だけで鯖はタッチしないから見てるだけ〜
でも動作テストは依頼されそうだな〜
まんどくせ〜
糞忙しい時期に〜
まんどくせ〜

だからASPにしろとあれほど

これはプログラマーにはどうしようもないわな

>>15
GNUは？

isapiつかえ

http://snapshot.publog.net/dat.php?url=http://news10.2ch.net/test/read.cgi/news5plus/1082033222/2-n#19

住所を書き込むのはやめろ

休出してPHP開発してる最中だったのに･･･orz

やっぱ、開発者人口が多いソフトの方がいいな。

インターネット時代においては、ソフトウエアクライシスの発生率は一年ごとに倍増し
それに比例して対応コストも増大する。

　　　　　　　　　　　　　　　　　　　　　　　　　　　――　ノースウエストの法則　――

研究所の編集者のオツムに、セキュリティ・ホールがあったって話し？

研究所ネタはもういいよ

416:09/01(木) 00:05 PyDOJVgL0 [sage]
なんか大量削除されてるけど
アレって間違いなく本人だよね！
背の高さ、肩幅（肩甲骨、鎖骨）、鼻・耳の形、八の字眉…
一つだけ気になる点があるけど、それを除けば同一人物と
断定できるよ！
見かけに反して情熱的なところが(･∀･)ｲｲ!!
http://whatever.say.jp/program/snap_shot/site/11295967618453/index.html
zeppin17/001.html
zeppin17/car.mpg

マ板じゃなくてニュー速に立ったのが災いしてるな･･･

↓↓↓↓↓↓↓以下PHP研究所・松下幸之助禁止↓↓↓↓↓↓↓

>>19
GNU is Not Unix
↑ (ry

4.4以前って、4.4も含まれるってことだよね?　念のためだけど。

なんてこった！！！！！！！！！！！１

あらま

Ｐ・Ｈ・Ｐ！
Ｐ・Ｈ・Ｐ！

自鯖でPHPビルドすると余裕で1時間かかるお（；＾ω＾）

また富士通か！

PSPなら知ってる。

言語仕様がころころ変わるPHPか

>>1

禿同。もってて良かったPHP

>>34
おいらも今ビルド始めたお

未確認情報ですが、

PHPUsers-MLによると、

register_globals = off
変数$GLOBALSを使っていない

を満たせば、問題無いとの話が出ています。

とりあえず続報を待ちましょう

4.4.*には色々と問題があるようです
（mb_send_mailとかに）

正直、無駄に騒ぎすぎ。

>>3
（-@∀@）＜だが、心配のしすぎではないか

PHPなんてダサい言語つかってるからだよ。時代はPerlだろｗ

register_globals = on　じゃなきゃ動かない
OSCommerceとか死亡だな

.NETなんか使ってゲイシへの献金に禿げんでる香具師らは、フリーの
開発言語やDBのことわからんだろ。　だからPHPも知らない。

何を言っているのか全く分からない。

pukiwikiのためだけにphpを使ってる

>>44
たしかに、どこから引数が来てるのかわからないようなプログラムは
恐いな。getでもpostでもごっちゃになってるから。

Red Hat のRPMがまだ出ねえ
困るんだよ実に　さっさとしてくれ

register_globals = offだけど、書き換えるの面倒だから
全部
extract($_REQUEST);
extract($_SERVER);
ってなってる。
ヤバイ？

PEAR.php使ってたらアウト！

Perlは偉大なり

うわ悲惨。

ＰＨＰって飯食えるの？
鯖管でいい転職先ないかなぁ。
Perlのほうが好きなんだけど。

>>54
食えるよ
現にフリーで食ってるよ

>>40
mb_send_mailに不具合あるってマジ？
4.4.1にしたから気になる
テストした限りでは問題なく動作してるけど

>>56
ttp://ns1.php.gr.jp/pipermail/php-users/2005-November/027873.html

よくやるsendmailの-tで送信元を指定して
エラーメールの受け取り先を設定ってのができないよね

ちなみに今日の問題には4.3.11用のパッチも出てるので、
問題があるならバージョンダウンすると良いよ

>>57
ありがとん
第五引数が無効になったのね
ニュー速で技術情報拾えるとは思わなかったw

被害甚大だな。

>>15
それってPHPの意味ないじゃん。
AHPでもBHPでもCHPでも一緒・・・

マジかよーーーーーーーーー！！！！！！！！




で、PHPて何や？

PHPの最初のPは
もともとPersonalかなんかだったような…
実際のとこエロい人教えて

昔はPersonal Home Pageというださい名前だったよ

http://www.itmedia.co.jp/enterprise/0405/21/epn01.html

これか…

Perl6はまだかいねー
PHPなんて使わんよ。

うわ、こりゃ大変だな

楽天とかヤフーもつかってるよPHP

ＰＨＰなんてまだ使われてるのか？
時代は．ＮＥＴだぜ

結局困るのは顧客ってことか・・

よくわからんが、
ＰＨＰでファイルアップロードの処理をしてなかったら
大丈夫？

>>40
でも,昔のBBSなんかで動的にオンにしてる場合があるから
そいつらは気をつけれ。鯖管の職域外だから。

>>71
よくわからんが、
ダメじゃね？

4.3.2でregister_globals=onで
ファイルのアップロード処理はないんだけど大丈夫だよね？
5.0.5でregister_globals=offで
ファイルのアップロード処理はないんだけど大丈夫だよね？

>>74
>>73

>69
社内システムならねｗ

調べたけど
大丈夫だった。
ID:r4ZexmgP0は嘘をつくな。

調べたけど。
ダメだった。
ID:HFO+DlPe0は嘘をつくな。

そろそろ全世界のPHPなウェブサイトというウェブサイトがジェノサイト食らってる?

file_uploads=Off ではダメなのか？

拡張子が.phpとかいうファイルがまんま見えてると、言語に穴があった場合に
攻撃受けやすくて危険な場合もあるということか

独自拡張子で言語が分からないようにしておけば、bot収集で無差別アタックとか
来づらくていいかもな

>>81
頭悪過ぎてﾜﾛﾀ

とりあえずファイルアップロードしてくると思うよ。
そしたらグローバル汚染だろ。
PEAR使ってたら即死。
ていうか俺即死しそう。誰かmojaviのパッチ当て手伝って。
サーバー多くて糞面倒くせえ。

グーグルもこれで攻撃されたのか

うわー、自分は社内でＰＨＰを押してたから明日会社行きたくないな。もう、みんなこの事知ってるんだろうな…。

>85
そりゃ仕方ないじゃん
ガンガッて会社行け

一瞬HSPかとｵﾓﾀ

PHP って、PHP/FI だった時代から、こんな話題ばっかりだな。

汎用性が高いから、以前はあちこちに導入した覚えがあるけど、
計算機管理が存分に出来なくなったから、数年前にリスクを回避
するために、その時点で立ち上がっていた計算機からは取り外し
た記憶がある。

これを見ると、再開の時期は、まだまだ遠いな。

>>80
ttp://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/11.html#20051102_PHP
を読む限り大丈夫な気がするなぁ

また週刊マイクソソフトか？

register_globalsをoffにすれば済むのに大げさな

>>91
register_globalsがoffでも$GLOBALS使ってたらアウト
PEAR.phpが使ってる。だからPEAR使ってる奴はアウト。
つーかregister_globalsは最近デフォルトでoffでしょ？

これからはPythonの時代だな

register_globals=off　　だったら平気だろ

今 4.3.7から4.4.1にあげた
php.ini保存し忘れてあせった

慌てるほどのモンぢゃないな♪

>>92
これってホント？
嫌がらせとかじゃなくて大事なことなので、ソースきぼんぬ

ttp://blog.ohgaki.net/index.php/yohgaki/2005/11/03/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp_1
ttp://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/11.html#20051102_PHP

これらのサイトを見る限りでは「register_globals=on の場合に」となっている。

このＰＨＰの、どこにセキュリティホールが？？

http://research.php.co.jp/

だから、2ちゃんねる全体がアクセスできなかったのか。

あちゃー，こらデカいわな…。

つーかPHPは昔からセキュリティホールになりそうな爆弾抱えすぎな
希ガス。

例：httpリクエストパラメータと同名の変数を内部的に勝手にこさえてしまう
　　→　スクリプト上の変数名とかちあっても意に介さず。

>>100
いつの話だ…

これからの流行はC++でApacheモジュール灘

>>101
あっしも古いヤツでござ（ｒｙ

Apache Version: Apache/1.3.29 (Unix) PHP/5.0.1

＿|￣|○

具体的にどういうコードがやばいか分かるしといませんか？
アップロード処理しつつ、$GLOBALS使うとやばいの？
それとも、アップロード処理してなくても、$GLOBALS使うとやばいの？
$GLOBALを呼び出した時点でやばいのか、サニタイズすればOKなのですか？

まいったな、Perlから全部PHPに乗り換えてるところなのに。

しかし-某国のサイバーテロ集団のサイトをいじるのには使えるか

1 register_globals=on
2 parse_str関数を1つの引数のみでリクエストデータに使用した場合
3 import_request_variablesを使って（foreachで$_POSTとか$$keyで初期化しても）スコープ内にリクエストデータを使用した場合

>>95
make installしても、php.iniは上書きされないよ。
明示的に php.ini-distをコピーしないとダメ。

ファイルアップさせる機能がなければ大丈夫なのかな
明日出社したらまずは全部点検か
この忙しい時期になんてこった

多分大丈夫かな・・・(´・ω・)

$GLOBALなんて使うなよ
手を抜きすぎだ

だがPearでもOsCommerceやXOOPSでも使われまくってる

だが心配のしすぎではないか





のレスがないのは，システム屋さんがたくさんいるスレだからだとおもた。

またどこかのプロジェクトで
PGが死ぬことになるのか・・・
(´･ω･`)ｶﾜｲｿｽ

早速被害にあった

4.2以下でも動作する様に下位互換性を持った配布スクリプトはほぼ全滅ではないだろうか

>>115
くわしく

明日が月曜日になるひと続出ですね

詳しく書いたら被害がでかくなっちゃう希ガス
早くパッチあてれっつかバージョンアップしてくれ

>>1
住基ネットか公的個人認証か電子申請や電子登記に使われているのなら大騒ぎなの？

http://blog.ohgaki.net/index.php/yohgaki/2005/11/03/phpa_rc_fei_a_oa_oa_fa_sa_le_acsa_oe_afp_1

>>121
ざっと見た感じだと、アップデートしたから終わりっていうわけにはいかないようだな。
アップデート終了の一年後になんらかの問題が出てくる可能性すらあるような気がするが…。

>>97
違ったようだな。すまん。

perlで書いてる俺は勝ち組

これからはRubyの時代だな。うぇうぇｗｗｗｗ

>>121
�dユーザー側でも注意が必要なんだな。やってみる

盛り上がってないけどみんな結構どうでもいいの？

どうでも良くない人はすでにこんなところに書き込んでいる場合じゃないのかと

パッチって、どうやってあてればいいですか？

perlを使えばいいじゃない。

作業が終わったんだよ

過去ログサイトを運営しているけど、php4.3.10だったよ。orz
pukiwikiのアップデートしようと思ったけど、事故覚悟で見送りしとこ。

そういやwikiでglobalsってページ作るとどうなるんだろうな
これは別になんともならないか？

Fedoraのパッケージもまだでてないよな
ソースから4.4.1入れるしかないのか

パッケージで構築してるのかよ・・・
そういう香具師はApacheもパッケージだったりするのか。。。

PHSなんかもう使ってないし

はいはいﾜﾛｽﾜﾛｽ

PHP 4.3.11のパッチは要検証と成っているが使えるのか？
結構死活問題

一応俺の管理下のサーバは全部対応した。
でも、セキュリティパッチとか全く当ててないからそもそも問題外だな。

CGTalkが昨日だったかメンテナンスしてかが、これだったのかな？

PHPって携帯電話のことか？

うわぁ！！！
うちの会社のサーバのうち、PHP使ってんの何台あったかな？
当分の間デスマーチ決定だな・・・　　　＿|￣|○

無知は黙ってろ

松下か！

PEAR駄目なのかよ、おれ即死ｗｗｗｗｗ





だからPHPなんて使うなと…

PHPってセキュリティ絡みのアップデートはよく有ると思うけど、
普段はどうしてるの？

ほんの数年前、緊急雇用対策で神奈川県立高校のコンピュータ講師募集は軒並み、面接になって
PerlやPHPを駆使できる人で無いと困るなんて言い出して軒並み不採用になったけど

今頃大変だね。

PHPってこんなんばっか
ちょっとした掲示板やカウンター組むならいいけど
デカいプログラムには向いてないな

レンタルサーバは4.3.8使ってるみたいだが、肝心のスクリプトの方はテキスト投稿受付機能はあるが
ファイルアップロード機能は無いので大丈夫っぽいな。

ああ、予想通りてんてこまい

FMはIMを使っているという話はありですか。

日本総本家やスラッシュドットにも載りだしたね
ttp://www.php.gr.jp/
ttp://slashdot.jp/security/article.pl?sid=05/11/03/2157229&from=rss

エロDVD再生と2chにしかPC使わない漏れには関係のない話しだな。

fastcgiやlighttpdがあるから、PHPまじいらね。

勘違いしてる奴多いが
「ファイルアップロード機能の有無」は何の意味もねーぞ
機能の有無に関わらず送りつけられたらPHPは受け取るんだ

未だに、3.0.18の国際版使ってるんだが、PHP4に未だにバージョンアップしてねー。

Content-Type: multipart/form-data, boundary=_BOUNDARY_20051104_035409_TjfpCKMTAP_

--_BOUNDARY_20051104_035409_TjfpCKMTAP_
content-disposition: form-data; name="test"

value
--_BOUNDARY_20051104_035409_TjfpCKMTAP_
content-disposition: form-data; name="file"; filename="test.txt"
Content-Type: plain/text
Content-Transfer-Encoding: binary

dGVzdA==
--_BOUNDARY_20051104_035409_TjfpCKMTAP_--

この問題なんだけどさぁ、multipart/form-dataで、POSTされたリクエストを
Apacheで排除するって方法とかはできないんかねぇ。
そもそも、Apacheでそんなフィルターできるか知らんが・・・。

なんとか、パッチ以外の別の方法を探さねば・・・

>>158
こんなんでどお？
ちゃんと動くか確認してない＆これで今回の問題がほんとに回避できるのかわからないけど。

RewriteEngine On
RewriteCond %{REQUEST_METHOD} "^POST$"
RewriteCond %{HTTP:Content-Type} "^multipart/form-data"
RewriteRule ^/path/to/php/scripts/ - [F]

mod_rewriteでそんなことできるのか・・・
たんなるURL書き換えにしか使ってなかった。

ちょっと、試してみる・・・
>>159
ありがとー。

なんかwebprog板のPHPスレより有益な情報が多い気がする
色んな人がいるからか

ぐはー、うち、register_globals=onだよー。
orz

だって書いた当時はデフォでonだったし…。
その当時の遺産が10サイト程…。
しぬる

>>163
( ;´･ω･`)人(´･ω･`; ) ﾅｶｰﾏ

おとといぐらいから修正中・・・　　orz

>>164
いや、まだ会社としての方針が決まってないから修正作業は始まってないけど
register_globals=onってのはさっき書いたとおりだけど
$GLOBALSは使ってないんだよね…。
$HTTP_*_VARSは使ってるけど。←($_*のバージョンより前w)
だから本体のVer上げたらソースの書き換えはもちろん、管理画面(コバルト)使ってるからそれも
おそらくぶっ壊れるw
なんかやりきれない思いであげとくわw

自宅鯖でp2使ってるんだけど対処したほうがいいのかな

またPHP出版か！！！

>>165
コバルトRaQ550(PHP4.0.6)なら下記の手順でアップグレード可能っぽい

[RAQ550の場合下記の準備をする]
・/usr/lib/apache/libphp4.soをlibphp4.0.6.soにリネームする
・/etc/admserv/conf/httpd.conf内のlibphp4.soの記述をlibphp4.0.6.soに書き換える

・/usr/local/src/ に最新のPHPのtarをダウンロードする
・php-4.3.11フォルダを作成し解凍する

・configureコマンドを実行
・make install
・/etc/rc.d/init.d/httpd restart

(念のためphp.iniを確認する)
完了

うちのRaQサーバーで4.3.11にしたときはこれでいけました

常時age

漏まいら、そんなに心配ならhttpd chrootしれ

>>166
踏み台にされてしまうかもしれんから
直すのがよいと思われ。

特にp2はPEAR使ってるし

なんか違う気もするけどソースはたぶんこれだな
ttp://www.cobaltqube.org/ml/archive/coba-d/20030202.week/5107.html

共用サーバーで開発している方々はどうするんかね・・

age

共用サーバ（WebARENA）でregister_globals=onなんだが、$GLOBALSは使ってない。
これってどう対処したらいいんだ？

>>174
suite2ならPHP自体をアップデートするらしいから放っておけば。
さっき案内が来たよ。

xoopsはどうすれば？

>>175
それで安心してしまうとｱｶﾝような気がするね
次のセキュリティホールが見つかったとき・・

>>175
ほんとだ、ｻﾝｷｭ

>>178
でも、どのみち新バージョンに合わせて全スクリプトの精査しなきゃならんけど…orz

>>159
試したよ。
望みどおり、multipart/form-dataなRequestだけ排除できたよん。
これで、ソース書き換えの間の時間稼ぎになればと。
ありがとうございました。

>>168

うわっ、こんなに懇切丁寧なレス頂くとは。
現実逃避の為に一日中開発に没頭してましたが重い腰あげてみます。
でもうちってテスト環境もねーからとりあえずraQ550もう一台確保するところからっス。
orz
でも情報感謝です。
ほうとに(・∀・) ありがとう!!

age

うちのとこは今日はソースの書き換えを行って、明日から二日間でテスト。
まあ、半日もあれば終わるだろうけど。ちょうど休みの間の平日で通常業務も少なかったから
運がよかったみたい。

出版社じゃないのか

age

けっこういるんだな。
おれはバージョン上げたときに全部書き直しておいた。
メンテが楽だからと当然のように主張したぞ。あり組自慢。

だいぶ落ち着いてきたかな？

この土日がなくなった人、手を上げて〜　　ﾉｼ

(´・ェ・｀)ﾉｼ

t

意味わからん。
俺にはきっと関係ない。
１しか読んでないけど

こういうのってここに載せるような記事なわけなんだろうか?
しかも下がってるのを>>1がアゲるのもどうかと思うよ。

redhat9用にrpm作ってくれないかな。

Java の方が扱いやすいよ。PHPって生産性よくない希ガス。

PHP文庫でﾊｧﾊｧしながらオナホでフィニッシュする俺は最悪ですかそうですか。

セキュリティに対する危機感持ってるヤツ少ないな
みんな個人情報とかは扱ってないのかな？

>>193
JDKビルドの際になぜか必ずコンパイルエラーが出る。

CPUがP54C-133なのが問題なのかっ！

うちのサイトのアクセスログみるとp2から来てるのが
結構居るんだよな。
おまいらちゃんと対策しておけよ

とりあえず、PHP 4.4.1にあげた。
でもregister_globals=onなので、スクリプトもなおしていかないとな〜

これってOSX標準のPHPも影響あるんだよ・・・ね？

3.3.11パッチあてるか4.4.1にまで上げたのならregister_globals=onでも良いんじゃねーの？

>>200
そうね、でも4.4.1はメール周り（mb_send_mail, mb_encode_mimeheader）がダメ
4.3.11用patchは未検証と、悩ましいよね

今のところ問題は出てないようなので4.3.11+patchが正解かな？
誰か当てて問題なく運用しているっていう人いる？

確かPHP 4.3.11 には mb_detect_encoding/mb_convert_encoding に問題があったはず。

[PHP-users 25298]
ttp://ns1.php.gr.jp/pipermail/php-users/2005-April/025814.html

PHP 4.3.11にするなら、ついでにこの問題に対するpatchを適用しておいた方が安全かも。
ttp://cvs.php.net/diff.php/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c?r1=1.1.2.6&r2=1.1.2.7&ty=u

>>202
はぁ、複雑すぎよね。安心して使えるバージョンはまだかな。。。

じゃあ4.3.11を利用するときには、
今回のセキュリティホール用パッチとmb_(detect|convert)_encodingパッチを当てて利用ってことで。

4.4.1まで上げて、mb_send_mailまわりは自力変換かjcode.phpあたりでラッパー関数作るか。
4.4.0から定数参照の仕様が変わったとかもあるんだっけな、参照引数に直接値渡してないか
全部調べるのめんどくせーなぁ…
標準関数なんてどれが参照渡しなのか把握してねーよ…

mb_send_mail 、うちでは大丈夫だったなぁ。

これがだめだった。
$subject = i18n_mime_header_encode(mb_convert_encoding($subject "JIS", "EUC-JP"));
mail($mail_to, $subject $honbun, $mail_from);

なぜか subject が ISO-2022-JP じゃなく UTF-8 になってた。

4がでても、mbまわり不安だったので、今だに3.0.18-ja のままです。

4.4.2 Devってどこにある？

初心者向けで分かりやすい
http://www.pahoo.org/e-soul/webtech/php01/php02-01.shtm

しかしなんだな、
ニュー速にはプログラマが多いと言うことか？

逆にWebProg板はこっちに誘導するようなクズばっかなんだよな

まずいバージョンでregister_globals=onで、
複数の企業がユーザのサイトだけど、
こんな問題放置だよ。
だって修正費用安いから。
一度全データハッキングされねえかな？と思ってるんだけどな。

(ﾉ∀`)ｱﾁｬ-今知った
register_globalsはOffだったけど、
本家だけじゃなく日本PHPユーザ会もお参りしないとダメですね。
Cの頃は結構グローバル使ってたよ。

オープンソースとか、名が知れたスクリプトを使ってないサイトじゃ、攻撃するにしても変数名一つ探り当てるにも膨大な手間と推理が必要じゃね？
実際のとこ、自分で書いたスクリプトだったらまず安心だな。

http://ns1.php.gr.jp/pipermail/php-users/2005-November/027861.html
これに対してエラい人が「間違ってる」って言わないってことは

>この結果を見る限り、（register_globals=offを前提で）プログラム
>中で$GLOBALS配列を使っていない限り、影響は受けないのかなぁ。。。

これは的を得てるってことなんかな？

大垣氏が公開してるって･･･
会長がパッチ作るユーザ会って廃れてる印象すら受けるな