【PHP】下らねぇ質問はここに 9
■ このスレッドは過去ログ倉庫に格納されています
PHPに関する質問スレです
前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 8
http://mevius.5ch.net/test/read.cgi/tech/1489506082/
次スレは>>980以降
本文の1行目に以下を追加すること
!extend:on:vvvvv:1000:512
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured これ以上やっても信仰する宗教のようなのでやめますが
php.netで $_POST変数が非推奨になり、filter_input関数が推奨になったら
その時に考えることにします
今は、いくつかある対策方法の一つとして聞いておきます >>448
書き込めたら密だって？
なんかワケわからんが、お前さんの言う密って何？
ちなみにそれは見たよ。 >>450
複数クラスやモジュールでコミュニケーションしてしまう状態 あなたはそういう風に使いたいのかも知れないが
普通の人はそうは使わない
いつまで自分の信仰に拘るんだろう >>452
グローバル変数の汚染を回避する設計って普通だぞ＾＾；
新興でも何でも無い。 汚染する犯人は自分以外にいないんですが
多重人格者でもなければ心配ないでしょう >>454
3ヶ月目の初心者みたいなこと言うなよ。。。
堅牢なコードを理解してないみたいなんで、これでも見て意識改善するといいよ。
https://youtu.be/17i1EL9pBwA 汚染の原因なんて事前に特定出来るでしょう
それが出来ない人だから、こんなことするの？ >>456
だから動画見ろってｗ
汚染も含めて「影響を受けない/受け付けない」コードの書き方を研究して、公開してくれてるんだから。 一か月前の自分は他人だよ
一年も経てば細部なんて何も覚えてない
俺は自分にそこまで自信を持てないわ 防げるのはせいぜい自分が書く内部バグくらい？
外部からの攻撃については無力
コツコツとバリッドチェックを用意することになるのは変わらない
こんなんでも堅牢なシステムだって言えるんだろうか グローバル変数に対して誤って代入している箇所を見つける事が
そんなに難しいことなんだろうか？ >>456 は結局のところ「注意すれば事足りるでしょ？」ってことを昨日からずっと言い続けてるよね
その注意をかける負担を減らせる手段を一つでも盛り込む事に反発する理由なんて一つもないと思うんだけどな
俺の頭がおかしいのかそうじゃないのかよく分かんなくなってくるじゃん 誤った代入ならローカル変数にだってあり得るが
こういうロジックミスはそれを使っても防ぎようがない
丹念にチェックし潰していくしかない あと宗教だの信仰だの言ってるけど、頑として自分の主張を曲げずにずっと言い続けてるってのは、結局のところそれは「別の宗教(信仰)」なのでは……？ 経験により積み重ねてきた手法を変えるというのは
それだけの説得力が必要なんだと思います
だから布教は大変なんでしょう 堅牢と言っているけども、何から堅牢かと言えば、自分自身が書く記述の誤りから堅牢になると言うこと
プログラムから見たら、グローバル変数だけをガードしてからと言ってバグフリーになるわけじゃない
また、Webサイトとして堅牢をうたうなら、それは外部からの攻撃に対しての話だし
今回提案された関数を使おうと、その点については無力のまま
この辺が改善されたら導入を考えようと思うんですが、如何ですか？ >>466
オマエほんとバカだろ。。。
動画見ても全然理解できないと思うけど、まず見てみ。
会話が成立しないくらいズレたことコメントしてるってだけでも理解したほうがいい。 >>466 の提案を受け入れたら考えます
出来ないなら、これで終わります >>468
なんで交換条件なんだよｗ
そのままズレてろ。どうでもいいわ。 >>461
注意すれば足りるっつうか、$_POST に値を代入しないようにコードを書くのがそんなに大変なの？
わざわざそういう設計をしなけりゃそんなことしないし、そうしてるなら必要だからしたんだろうから仕様に沿って使えばいいんじゃね？
ということなんじゃないの。
いや別に filter_input を使うなと言ってるのではないし使えばいいじゃんと思ってるが、$_POST をそこまで忌み嫌うのが意味分からんてことだよ。
それで疎にするとか持ち出してきて、$_POST の代わりに filter_input 使えば疎になるって何のこっちゃ？って感じだろう？
堅牢になるぜならまだ分かるが、疎って？ってさ。
疎にするって話ならと >>415 みたいな手法を持ち出してみたらそれには同意してもらえてるっぽいが、filter_input 使えば疎って話ではないだろってところは通じてないっぽいんだよな。
なんつうか、意識高い系なんだろうなって感じ。 チームで開発したことないんだろ、きっと
それか、一人で十分な開発規模
あるいはチームでテレパシーｗ スーパーグローバルとfilter_inputに関してはPHP特有だし多少議論があるのは理解する
それでもfilter_inputの方がベターだと思うが
しかしグローバル変数使うなが納得出来ないというのはお話にならない 正直、ここしばらくフレームワークの世話になってたから
$_POSTもfilter_inputも明示的につかったことない
でも、ざっと見た限りではよっぽどトリッキーなことしない限り
filter_inputをつかわない理由はないな >>470
密とか疎に対して「結合」って使ったから良くなかったかもね。
結合というより、関係性かなぁ。
$_POST が変更可能な変数であり、かつどこでも使用できるため、使用箇所の関係性が密になってしまう。
値が変更になれば、当然後続が影響を受けるから密ね。
だから、http から直接値を引っ張ってくる filter_input 使用することで、どこで使用しても一律な値を保証できるよう関係性を疎に保とうよ。
って書きたかったんだわ。
結局、$_POST 使用するたびに、プロジェクト全体を grep するとかアホらしいので、新規にコード書くならまず $_POST は使わん。って程度の決意。 ところで $_FILES や $_SESSION へのアクセスはどうやってるの？ >>475
回避不能だねｗ
基本はフレームワークに閉じ込めて、自分では $_FILES とか $_SESSION は書かない。
で、どうしても自分で書かなきゃいけないときは、念のため grep するぐらいしか対応できない。 追いついた。
単にグローバル変数を使わないようなコードを書きましょうねって話よね。
大昔BASICからCに移行したときに見た話かな。 >>477
同じくくだらない話に今追いついたが
たったそれだけの話だよな
グローバル変数なんか感覚的・直感的に気持ち悪いと感じないようじゃ
いちいち細かい理由を説明しないと理解できない時点で
プログラマとして失格だと思う
趣味でやってて自分1人さえ理解できればよくて
メンテも一生自分1人でやるのなら好きにやりゃいいけどさ >>477,478
追い付いたというからにはそれなりに読んだんだろうに、それで単にグローバル変数を使う話に見えるならプログラマー失格だと思うよ >>479様がマウントを取りたいがために風呂敷を拡げ始めたと聞いてバックネット裏の席を確保しました >>480
PHPの仕様として存在しPHP自体が用意してる参照が非推薦ともされていない情報に対する参照がグローバル（スーパーグローバル）というだけでなぜいけないのか？という話だよ。
自分で勝手グローバルを作ろうって話じゃない。 >>482
>>477と>>478はどのあたりがプログラマ失格なんですか？
>自分で勝手グローバルを作ろうって話じゃない。
彼ら(>>477 >>478)はこれに該当する旨を話してるんですか？
どのあたりがそうなんですか？ 人の話を聞かないまま退散したあのかたが蒸し返しで再登板しただけでした
解散 グローバル変数云々の話以外だと例えば
?foo[]=1&foo[][]=2&foo[][][]=3
の時の
htmlspecialchars($_GET['foo']);
はエラーになるわな
なのにis_set($_GET['foo']) や array_key_exists('foo', $_GET) 程度で満足してるウンココードだらけで
そういうウンココードが書籍にまで書かれててウンコが量産されてるのもphpの問題だな
htmlspecialchars(filter_input(INPUT_GET, 'foo'));
ならエラーにはならないが、現実的にはfilter_input()も直接は使わないわけで
フレームワークを通さずに書きたいなら$_GET['foo']よりはベターってだけ
フレームワークを使わない便利な関数を使わないって人ってのは
大した頭もないくせして車輪の再発明が大好きなんだろうとお察しする
絶対に一緒に仕事をしたくないタイプ register_globalsやmagic_quotes_gpcみたいなPHPの黒歴史や
伝説の名言「例えば、PHPを避ける」なんかを知らない人も
増えてるんだろうなと思う
今から10数年前のPHP4を勉強してた頃の自分なら
$_GETや$_POSTを直接使って何が悪いの？と言ってた筈
プログラミングの世界は1年前の自分ですら赤の他人だし
いつか理解できる日が来るといいね
理解できなくても食うに困らない稼ぎがあるなら
それはそれでいいんじゃない？（周りの人は迷惑だけどｗ） PHPの開発方針がめちゃくちゃ保守的だってことも知らないのだろう
https://externals.io/message/100087
php-internalsでも$_POSTや$_GETをimmutableにしないのはあくまで後方互換性が崩れるからだとしか言われてない($_ENVや$_SERVERはまた別だが)
スーパーグローバルの(スーパーグローバルの書き換えとは独立した)immutable版があればいいのにと思う PHPしか書いた事ないやつだとimmutableという概念を知らない可能性もありそう
そもそもさ
?foo=bar
$_GET['foo'] = 'hage';
var_dump($_GET['foo']); // string(4) "hage"
var_dump(filter_input(INPUT_GET, 'foo')); // string(3) "bar"
↑これ理解できてるんだろうか？
あと素朴な疑問だが
$_GETや$_POSTを直接使ってるやつってユニットテストはどうやってんの？
ブラウザで表示させて実際に値を入力してテストとかやってそうｗ >>489
＞↑これ理解できてるんだろうか？
>>442を見る限りでは勘違いしてるっぽいね
＞ $_GETや$_POSTを直接使ってるやつってユニットテストはどうやってんの？
その例のように
$_GET['foo'] = 'hage';
とかやってるんじゃないかな…
真面目な話
個人開発レベル程度の経験しかない人だと
PHPUnitなんて使った事ない（というかユニットテストという概念を知らない）って人がわりといたりする >>486
そこでちょろっと言ってることが本質なんじゃないの。
一番に検討しなくちゃいけないのは、外とのインタフェースをあちらこちらに書かず特定の機構に閉じ込めるということだろ。
閉じ込めた中で $_GET と filter_input のどちらを使うかなんてことは本質じゃなく、その時の都合でベストチョイスすればいいだけのこと。
どっちもPHPが用意している正当なインタフェースなんだから。
グローバルはいけないんだなんて言ってみても、結局 >>475-476 でしょ。 >>491
> 一番に検討しなくちゃいけないのは、外とのインタフェースをあちらこちらに書かず特定の機構に閉じ込めるということだろ。
このことはだれも否定していない。
> 閉じ込めた中で $_GET と filter_input のどちらを使うかなんてことは本質じゃなく、その時の都合でベストチョイスすればいいだけのこと。
こっちを、スーパーグローバル変数を使用するのはやめようぜ。って言ってる
自前実装だろうが、PHPの仕様だろうが、グローバルな変数ってだけで悪ｗ
> グローバルはいけないんだなんて言ってみても、結局 >>475-476 でしょ。
だから、immutable 版がほしいね。って流れ ざっと見て>>448あたりは結構頑張って理由を書いてると思うし
>>493はワッチョイから判断するに同じ人だと思うのだけど
自分は>>442を見た時点で説明するだけ時間の無駄だと判断した
スーパーグローバル変数（笑）なんてものを直接使う糞コードが少しでも減ってくれたらいいなとは思う ワッチョイで >>448 と >>493 が同じってどうやって判断するの？
>>493 と >>494 は hE18 で同じかなって気がするが、そういう見方じゃないんだっけ。 来週の木曜0:00AMまではワッチョイ末尾4桁「hE18」はJaneStyle4.00をデフォの設定で使ってる人
すなわちUserAgentを現してる（毎週木曜リセット）
じゃぁどこ見て判断してるのかといえば「b3」で
大雑把に回線が同じHostなんだろうって事を確認して
あとは文体で判断してる（リセットされない）
プログラム板の人なんだからそれぐらいの法則性は自力で見つけて欲しいものだが… ちなみにこんなサービスもある
ttps://afi.click/browser/list/
プログラム板の住人なら
どうやればこのサービスを実現できるか
DB設計から考えてみたらいいんじゃないかな 他人に根拠希薄にプログラマー失格とか罵っときながらのオチがこれ 11レスもしながら出だしの>442の時点で間違ってるのは
オチとは言わず「ボケ」と言うんじゃないかと
たくさんのツッコミが貰えて本望だろう この話題の最初に書いたとおり、filter_input の使用に関して、スーパーグローバル回避のためって理由がググっても中々ヒットしない。
ある程度コードかけるようになると自明だし、フレームワーク使うようになると filter_input すら使う機会が少なくなるからだと思うけど、量産型初心者が全部 $_POST で育ってくるのでめんどいｗ
みんなどんどん素敵記事書いて、初心者に広報してくれんかねぇ。 グローバル変数を使わない方がいい理由が分からないって人ってやっばりPHPしか書けない人なのかな？
他の言語では常識な事だけに何が理解できないのかが理解できない ✕PHPしか書けない
◯PHPすら書けない
PHPerが馬鹿にされる理由がよく分かるよな メジャーなフレームワークのコードを読んでみたりはしないのだろうか
全部を確認したわけではないけど流石に$_GET $_POSTを直接ごにょごにょやってるFWは無いと思う ググってみるとteratailに質問してる初心者のやり取りを見つけたからurlを張っとく
https://teratail.com/questions/63786
501の言う量産型初心者が1人でも減ってくれることを願って。。。 >>505
これ、オレがコメントした時に参考にした記事ｗｗｗ
これのせいで、「疎結合」とか、伝わりにくい表現使ってしまった。
ちゃんと理解した奴がまとめて記事書いてくれprz >>504
laravel 5.6.33 の新規プロジェクト作って grep してみたら、filter_input はヒットしなかったよ。
$_GET やら $_POST、$_SERVER なんかを使ってるコードはたくさんあるが、これが FW 本体なのかは知らないから見てるものが違うかもしれんが。
ついでに手元にあった古い cakephp のコードも grep してみたけど、やはり filter_input は使ってないようだね。
最新だとどうなのかは知らないけど。
どのフレームワークのコードを読んだの？ なんで使ってないんだろうな
さすがに何らかの理由があるはずだよな その辺はいろいろなFWのコードを読んだ >>504 がまず解説してくれると思うけど、
>>493 によればグローバルな変数ってだけで悪らしいし、それについての否定コメントも無いことを見れば共通認識なんだろうから、
この流れから言えば量産型初心者が作ってるってことなんじゃない。
スパーグローバルの差し替えなんて密結合(?)な行儀の悪いこともしてるようだから、ゴミがメジャーになった悲劇的なケースなんだろうかね。
おれはそうは思わないけど。
filter_input は多重配列に弱いし $_GET や $_POST も含めて同じパラメタ名が重複することに気付けなかったりするので必要に応じて自前で QUERY_STRING やら STDIN を読む選択もあるだろうと思ってるから、
FW の利用を含めておれはその時一番都合のいい方法を選択するから気楽なもんだ。
選択肢を絞ることを徹底するというのも品質管理の手法の一つとしてあると思ってるけどね。
何にしても解説を待ちたいね。 グローバル変数とユニットテストについて質問です。
ユニットテストで、NULLバイトチェックのため、$_GETにユーザー入力値（ヌルバイト￥０）を
直接代入してテストしていますが、これはまずいのでしょうか？
public function test_checkNullbyte()
{
$_GET['nullbyte'] = "abc\0xyz";
$this->object->checkNullbyte();
} >>510
そのチェックメソッドが $_GET を参照する作りになってるならいいと思うよ。 >>511
ありがとうございます。
プロダクトコードのスーパーグローバル変数の参照部分を見直してみます。 JavaScriptを使わず、PHPだけでフォームの戻るボタンって作れるんですか !? >>513
JavaScriptを使わずと言うことは
<input type="button" value="戻る" onclick="history.back()">
こういうのもだめってことかな？ >>513です
>>514さん
ISO-HTMLなのでイベントハンドラ？も使えないです。 安易だが
ブラウザから返してくる、$_SERVER['HTTP_REFERER']の値を信じて、そこに送り返してあげる
（セットしないブラウザもあるし、嘘も書けるので、オススメはしない）
面倒だが
自分のサイトだけで遷移しているなら、直前のURLをセッションに持たせ、それを参照して戻す
（入力フォームで行ったり来たりする場合は、入力しかけのフォームの値も保持しないと行けなくなる
こういう場合、相当面倒な処理を書かないと行けないと思うが、仕方ないね？） あるいは
フォームでPOSTする要領で直前のURLに遷移すると言う方法もある
その場合はサーバー側で次画面に遷移する際に、
現在の場所をフォームに埋め込む形で出来る >>513です
>>516さん
セッションですか !?
身につけたいので頑張ります！ >>508
$_REQUESTとかってwww-form〜専用だろ。 >>513
よくあるフォームで、入力➡確認➡完了 みたいな流れの中で 確認から入力に戻るような話？ >>513です
>>517さん
お返事が遅れました。
戻る際にもフォームを使うということですか。
ありがとうございます。
>>520さん
お返事が遅れました。
>>確認から入力に戻るような話？
はい。PHPで対応したいので現在勉強中です。
始めはHTMLのtype="heidden"を採用しようと考えていたのですが、いただいたレスやセキュリティを考えた結果、セッション変数を使ってみようかと思い試行錯誤中です。 >>521
そういう遷移ならもっとシンプルに考えた方がいいんじゃね。
submit ボタンに name を設定しておけば、送信時に押されたボタンが分かるよ。
>>520 のような全部の画面は例えば form.php で処理させ、押されたボタンによって画面を出し分けるなんてのが簡単じゃないかな。
確認画面には例えば <button type="submit" name="act" value="back">戻る</button> と <button type="submit" name="act" value="send">送信</button> 置いておく感じ。
入力画面には <button type="submit" name="act" value="check">確認</button> とか。
すると form.php はこんな感じ。
$act=filter_input(INPUT_POST, 'act');
$view=入力画面;
入力値の取得とバリデーション;
if(エラー無し) {
if($act==='check') {
$view=確認画面;
}
elsif($act==='send') {
登録処理;
if(成功) {
$view=完了画面;
}
}
}
$view 表示;
セッション使ってないから、確認画面には入力値を hidden で埋めておく。
入力画面ではエラーメッセージの表示も行う感じ。 >>522
その流れだと初回表示時にバリデーションが走って必須項目未入力のエラーが出ちゃいそうだねw
説明用とは言え雑だったが、submitボタンが取れることが分かればうまいことやれるでしょ。 >>513です
>>522さん
そのような方法もあるんですね。
くださったレスを参考にいろいろと試行錯誤してみます。
ありがとうございました。 hiddenが危険という言葉を鵜呑みにする必要はない
用途による
メールフォームの確認程度なら別にhiddenでいい
そんなの改ざんする意味もなければされたところで問題ないし
最終的に受け取ったデータを通すかはPHPが判断すればいいこと hiddenに限らずチェックはしないとね
さもないと、支払もすんでいない商品を買ったことにされたり
ログイン認証済んでいないのに、内部に入り込まれたりするから 質問投下です。
PHP 2chBBSをphp7.0のサーバーにアップして色々と対応させるよう書き換えましたが、これだけが分かりません。
abon.php,92行目あたり
$line = preg_replace("!<a href=\"\.\./test/read\.php/$_POST[bbs]/$_POST[key]/([\d|\-]+)\" target=\"_blank\">>>([\d|\-]+)</a>!e",
"'<a href=\"../test/read.php/$_POST[bbs]/$_POST[key]/'.res_num('$1',$del).'\" target=\"_blank\">>>'.res_num('$2',$del).'</a>'", $line);
php7ではpreg_replaceのe修飾子が廃止されており、preg_replace_callbackを使う事に
なっているようですが、ググってみても、どのように置き換えれば良いのか分かりません。
お知恵をお借りできれば助かります。よろしくお願いします。 その部分だけ見ててもすげーやべーコードなのが分かるから手直し以前にゼロから作り直した方がいいよ
つか調べたら最終更新2005年(13年前)でかつこのコードとか本格的にやべーのでもっと新しくてまともなもの探さなきゃダメだよ スーパーグローバルのチェックはしてあるんだと思うよ。流石に…w >>528
レスありがとうございます。
これ、ちまちまと手直しして使っておりまして。
このコードは管理機能内の記事削除部分で、管理者しか使えないですし、
第三者が入れないよう認証かけてるのでセキュリティーは多分大丈夫だと思います。
取りあえず使えるようにしたいので手直し出来るのであれば教えて欲しいです。
あと、どういう点がやばいのかご教示いただければ勉強出来るので非常に助かります。 だから、$_POSTをいきなり正規表現の処理に入れてるところがヤバイって言いたいんだと思う。
bbsやkeyに悪意のあるコードを入れてられても、そのままノーチェックで処理を継続していたらヤバイ。
仮にチェック済だとしても、スーパーグローバルを使ってると頭悪そうにみえるしな。 >>527
$line = preg_replace_callback(
"!<a href=\"\.\./test/read\.php/$_POST['bbs']/$_POST['key']/([\d|\-]+)\" target=\"_blank\">>>([\d|\-]+)</a>!",
'callback_hoge', $line);
function callback_hoge($matches)
{
return "<a href=\"../test/read.php/$_POST['bbs']/$_POST['key']/" . res_num($matches[1], $del). '\" target=\"_blank\">>>' . res_num($matches[2], $del) . '</a>';
}
クロージャ使って書くなら
$line = preg_replace_callback(
"!<a href=\"\.\./test/read\.php/$_POST['bbs']/$_POST['key']/([\d|\-]+)\" target=\"_blank\">>>([\d|\-]+)</a>!",
function ($matches) {
return "<a href=\"../test/read.php/$_POST['bbs']/$_POST['key']/" . res_num($matches[1], $del). '\" target=\"_blank\">>>' . res_num($matches[2], $del) . '</a>';
},
$line
);
半角スペース2個を全角スペースにして書いてるので注意 【補足】
他の人も書いてるけど
たった1行のコードから色々とヤバさが伝わってくる代物なので
他の代替手段を使うことを強くおすすめ
少なくとも $_POST[bbs] じゃなく {$_POST['bbs']}
>>530
JVNにXSSの脆弱性がある事が報告されてる
https://jvn.jp/jp/JVN48774168/index.html
コードをざっと斜め読みしたけど他にも色々と駄目すぎてどこから手を入れるべきかアドバイスできないレベルで酷い
2005年のコードでもきちんと書いてればPHP7でも大体問題なく動くものだけど
このコードだと他にも色々と問題が出ると思う >>532訂正
$delって変数があるの見落としてた
$line = preg_replace_callback(
"!<a href=\"\.\./test/read\.php/$_POST['bbs']/$_POST['key']/([\d|\-]+)\" target=\"_blank\">>>([\d|\-]+)</a>!",
'callback_hoge', $line);
function callback_hoge($matches)
{
return "<a href=\"../test/read.php/$_POST['bbs']/$_POST['key']/" . res_num($matches[1], $GLOBALS['del']). '\" target=\"_blank\">>>' . res_num($matches[2], $del) . '</a>';
}
クロージャ使うなら
$line = preg_replace_callback(
"!<a href=\"\.\./test/read\.php/$_POST['bbs']/$_POST['key']/([\d|\-]+)\" target=\"_blank\">>>([\d|\-]+)</a>!",
function ($matches) use ($del) {
return "<a href=\"../test/read.php/$_POST['bbs']/$_POST['key']/" . res_num($matches[1], $del). '\" target=\"_blank\">>>' . res_num($matches[2], $del) . '</a>';
},
$line
); エラーを無視するような感じのエラー処理が適当なコードだから
セキュリティもそれなりなのだろうというのが容易に想像出来るんだわ
なんせPHP4時代のコードだし今ほどそのへん考慮されてないからねえ >>529
コード内に出てくる $_POST[bbs]（本当は $_POST['bbs'] だが）は
まともにチェックされてないっぽい
unlink("../$_POST[bbs]/...");
みたいなコードが散見されるから
NULLバイト攻撃も素通りだと思う
ヤバすぎ >>532
$del を受ける use が必要じゃね
あと細かい話だが、PHPが単なる即時関数もクロージャと言うのにはちょっと違和感ある。
>>532 のケースはクロージャになるけど、クロージャってやっぱスコープが特殊なところに意義があるというか。 >>536
そうなんだ…ワロタ
クローズドな環境で割り切って使う以外はあぶないね。 OSに処理投げる形式のファイルシステム関数についてはnulバイト攻撃はPHP側で対策されてはいる
https://github.com/php/php-src/blob/master/ext/standard/file.c#L1510
https://github.com/php/php-src/blob/master/Zend/zend_API.h#L1011
が, 何れにせよ救いがたいコードで, 管理者しか使えないから問題ないという発想も正直ヤバい
この状態から>>527の質問のレベルで更にツギハギで直してるっていうんだからセキュリティに関しては想像もしたくないというのが正直なところ 敢えて繰り返すけど, もっと新しくてまともなもの探さなきゃダメだよ
そうするのがベターなんじゃなくて, そうしなきゃダメ, SHOULDじゃなくてMUSTだよ >>539
かなり昔に対策されたんだな
知らなかったサンクス
$_POST[bbs]でコード内を検索したら
unlink("../$_POST[bbs]/dat/$_POST[key].dat");
こんなコードが出てきたんでびっくりして脊髄反射してしまったｗｗ ついでに正規表現パターンにPOSTデータ突っ込むのがどうしても我慢ならなかったから直してみた
$line = preg_replace_callback(
'!<a href="\.\./test/read\.php/(?<bbs>[^/]+)/(?<key>[^/]+)/(?<num>[\d|\-]+)" target="_blank">>>\k<num></a>!',
function ($matches) use ($del) {
$bbs = filter_input(INPUT_POST, 'bbs');
$key = filter_input(INPUT_POST, 'key');
if ($matches['bbs'] !== $bbs || $matches['key'] !== $key) {
return $matches[0];
}
return '<a href="../test/read.php/'.$bbs.'/'.$key.'/'.res_num($matches['num'], $del).'" target="_blank">>>'.res_num($matches['num'], $del).'</a>';
},
$line
); Interface用のファイルって基本的にどこに置けばいいの？
それを継承するクラス群と同じディレクトリなのか、
もしくは最初から一箇所(例えばMyApp\Contract等)にまとめていいのか >>532
手直し、ありがとうございます。
勉強させてもらいます。
件の掲示板ですが、社内LANで運用されておりまして、前任者より引き継いだものです。
設置はさらに前の前任者（退職）が行ったようです。
お察しの通り、phpのスキルはそれ程高くはありません。
移行を検討するよう進言してみます。
ありがとうございました。 社内でしかも管理者限定なら急ぐことはないか…
でもコードの品質全てが問題ありそうだから、仲間内で注意喚起はした方がいいな。
JVNで周知されてるのも良い理由になると思う。 >>544
>>532のコードは間違ってるので使うなら>>534か>>542で
お節介ながら
今はSlackみたいな便利なものが色々とあるので
そもそも掲示板を使う必要はあるのか？ってところから検討した方がいいのではと メールヘッダーインジェクションって現バージョンのPHPではどうなんですか？
mail()やmb_send_mail()で対策されたとネット上で見かけたのですが(´・ω・`) >>547
英語版のPHPマニュアルの改変履歴追ってみると7.2.0での対応で一段落って感じだけど
日本語版には書かれてないな
NULLバイトや改行コードを悪用したインジェクションなら
mail()やmb_send_mail()に渡すデータをバリデーションしてたら7.2.0未満でも問題ない筈だが ■ このスレッドは過去ログ倉庫に格納されています
