【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 >>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未満でも問題ない筈だが ttps://blog.ohgaki.net/php-mail-header-injection 例外を投げるとき、Exceptionを投げるのは良くないのでしょうか？
Exception は、すべての例外の基底クラスだからユーザーが投げるのは
良くないという記事を以前に何かで見たので気になります。
ただ、PHPマニュアルでは、普通にExceptionを投げる例が載ってます。
http://php.net/manual/ja/language.exceptions.php
<?php
function inverse($x) {
if (!$x) {
throw new Exception('ゼロによる除算。');
}
return 1/$x;
} 要するにcatchしたいときにExceptionやらThrowableとするしかなくて, 少なくとも例外は全部漏れなく捕捉してしまうのが問題なわけだ >>551
なるほど。例外を個別に場合分けして処理したいときに困るということですね。
ありがとうございます。疑問が晴れました。 最近話題になってたfilter_inputみたいに$_POSTを取得する関数って他にもあるんですか？
http://php.net/manual/ja/ref.filter.php >>553
それは $_POST を取ってるわけじゃない。
POSTされたデータを取る手段として $_POST と filter_input がある。
他の標準的な手段として用意されてるものは無いと思うけど、リクエストを自分で処理するという手段はある。 >>554
詳しく教えてくださりありがとうございます。
勉強になりました。 FILTER_SANITIZE_FULL_SPECIAL_CHARS？
htmlspecialchars？
あばばばば(´・ω・`) 前者は使わなくてもいい。
後者は画面に出すときに必須 mail関数で文字化けするのはどういった状況なんだろうか エンコード関連の設定が間違えているって書いても、
そのくらいは知っているって言われそうだしなあ PHPを初めて間もないので知らなかったです(´・ω・`)
文字化けが自分で作った環境が原因でおこるのか、
ユーザーの環境によっておこるのか、
それすらも現在進行形で勉強中です。 今時はメールもutf-8にしちゃう方が良い？
サイズはともかく。 JIS だと扱えない文字が結構あって面倒なんだよね。
氏名を埋め込もうとするだけでもすぐ問題が起こる。
個人的には結構保守的なんで極力 JIS にしたいが、utf8 も仕方ないかなと思うこともある。 >>559
件名が化けてるの？
本文が化けてるの？ >>559
>>561です
>>564さん
どちらも化けてないです。
ただ文字化けする状況がよくわからなかっただけです。
自分の環境を全てutf8に統一すれば化けないですかね(´・ω・`) どちらかと言えば、送信したサーバー側にあると思うよ。
ヘッダをMIMEエンコードしてないとか、
本文をJISと宣言しておいてSJISとか良く見る。
作る側が理解してない。
それを受信すらメールソフトが何とか正しく表示しようと努力して、
それでもダメだった場合に化ける。
あと稀に、ソースからしてそもそも化けてるという
バカが書いたメールもあるw >>566
たまに磁場消したメール受けとる
解読するのを楽しみにしたりする >>565です
>>566さん
こちらがしっかりと設定すれば大丈夫そうですね。
後は山のように試行錯誤を積み重ねていきたいと思います(´・ω・`)
今はmail($to･･･)の$toに自分のメールアドレスをどのようにして入れるか考えてます。
define関数で定義した方が安全？なんでしょうか。
勉強がんばります。 >>570
メンテナンス性を考慮すれば定数で定義しとく方が好ましい
”ハードコーディング”でググるんだ
あとPHP5.3未満だという理由でもない限りは
定数の定義はdefine()じゃなくconstでいい
define()にしかできない事をやる時だけdefine()を使う
…というかdefine()にしかできないような定数の定義の仕方は
しない方がいいというか >>570
confg.phpとかconfig.iniとか作って、
設定値を書きまくるファイル用意するといいよ。
定数名は大文字にしておけば目立つね。 >>570です
>>571さん
constでも定義できるんですね。
他にも詳しいアドバイスありがとうございます。
>>572さん
設定値を管理するファイルを作る、メモしました。
定数名は大文字がマナー？なんですかね。
お二方、アドバイスありがとうございます。
ずっと画面と見つめ合ってたので頭が痛いです。
体調管理に気を付けます。
ありがとうございました。 >>570の$toって直書きすると外部から参照されたりするん？
そこらへん うちも勉強不足だわ 外部からってどういう意味？
宛先見せないと配達できないでしょ？
そういうことじゃなくて？ web公開ディレクトリに置かないのが基本なんだよ。
hdocs/index.html
lib/php/config.ini 共用のレンタルサーバーだと、
Permissionを0604にするのもありだな。
最初の0は気にしない。
次の6は自分の読み書き権限
次の0は同居してるユーザーに権限剥奪
最後の4はApacheに読み取り権限 >>577
釣りかな？
それApacheにかぎらず誰でもオッケーって意味だよ ほとんどの共用レンタルサーバーは、
webユーザーは同一グループに所属するから、
xx0xで引っ掛けて拒否させるんだよ。
最後の4は付けないとApacheが読めない。
https://www.xserver.ne.jp/manual/man_server_permission.php
グループ設計がどうなってるかとか、
PHPの実行ユーザーが誰になるかとか、
事前に確認しないといけないな。
suEXEC、FastCGIなんかで変わってくる場合もあるし。 ど素人です
質問させてください
cakephp3のwebroot以下にある.htaccessで、mod_rewriteの括弧外にrewritecondやrewriteruleが書かれているものを人様のサイトで拝見しました
括弧外に置かれても、機能するものなのでしょうか <IfModule mod_rewrite.c>
もしかしてこれ？ そうです
すみません、>>583は携帯から書き込んでいたので正確ではありませんでした
質問するにしても良くなかったですね
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
このようなものなのですが それは、そのモジュールが有効化されていたら設定するって意味で、
何のモジュールのディレクティブなのか明確になる以外にメリットない。
だから書かない方が良い。
ifを書かなければ、モジュールが無効なら即500エラーで設定ミスに気付ける。
モジュールが無効なのにエラーにならず、
設定したつもりでいる方が危ないからね。 >>581
怖い(´・ω・`)
>>582
ありがとう >>586
返答ありがとうございます
リファレンスにしていたものが、全てディレクティブを括弧内に書いていたのと
cakephpのインストール直後のプロジェクトに入っていた.htaccessでも
ディレクティブが<ifmodule>で囲まれていたので、
基本的には囲う必要があり、外に出る方がおかしいと思い込みがありました
まさにおっしゃられていた通り、apache2.confを見てみたら
Loadmoduleでmod_rewriteを有効化していたつもりで、実際にはコメントアウトされていたのですが
それにも気付いていませんでした
どうもありがとうございます 読み返してたんだけど>>557の前者って使うことないものなの？ >>587
ネタにマジレスしとくと
dieの発音は「ディエ」じゃなく「ダイ」だし
exitとdieは等価なので、エラーログに残るとかは嘘
exitの方が一般的だとは思うが好きな方を使えばOK
あくまで予想だが、die()はperl言語出身者に配慮して作ったんじゃなかろうか height
align
allow
deny
web系に関わってるのにこういう単語の読み方がおかしな人の言う事は疑ってかかった方がいいという経験則 >>590
すまん。perlの関数と勘違いしてた…
PHPにおいてはexitもdieも同じらしい。
dieの引数も標準出力されたw
プログラムは読み手に意図を伝えた方が良い場合もあるから、
exit(1)よりdieの方が致命的エラーなのかなと思わせることはできるかな。
しかし標準出力されるんじゃあ使えないな。
嘘こいてすまん。 >>591
ヘイト
アリグン
？
デニー
allowを読み違えてる人は見たことない…
あとは、hrefをハーフ、widthをウィドスは稀に。
ウィドスはまだネイティブに近い方かな？ >>591
ハイト
アライン
アラウ
ディナイ
どれも高校入試の時の発音問題頻出単語（要するに中学レベルの単語）だったような遠い20年以上前の記憶
うんざりする程しつこく教えてくれた当時の英語担任に感謝しないといかん アラウか…
何かそこだけ妙にネイティブだな。
アローですまん… 本来ネイティブの発音に合わせて読むべきなんだろうけど、
アラウやディナイと発音しても、日本人相手だと通じなかったりする アラウはちょっとなあ…
それ言い出すとonlyはオウンリイだし。
日頃はカタカナ英語でいいです。 ネタなのかマジなのかわからなくなってきたけど正解はもちろん>>594
allow,denyをアローデニーと読んでいた自称サーバー管理者が設定したウンコみたいなサーバーに泣かされて以来トラウマです
そして今なおallow,denyという単語を目にするという事はそれ即ち、去年末にサポートが終わったApache2.2系をまだ使い続けてるというトラウマの再来になる可能性がががが ウォーニング
まぁ会社によって方言みたいなのはあるよね
内心そうじゃないだろ…（ため息）と思いつつ相手に合わせる事も大事 今の所全問正解っぽくて安心した
falseをファルスと読む人を見る度に
パルスのファルシのルシがコクーンでパージを思い出す アリグンとかデニーとかいってるならヘイグヒトぐらいにしないと あんまりこだわると意識高い系とか嫌味を言われそうだし、
まあわかればいいやね…
ここじゃないかもだかど、どっかのPHPスレで
エチョーと書いたらウケたよ。 allowというかau音はアゥからオゥに寄った側に聞こえるからカタカナ英語的にはアロゥはアリかなと思う
arrowと区別したいときはアラゥと言うべきだと思うけど
デニーとかアリグンは流石にねーなw ini → イニ？ アイエヌアイ？
array → アレイ？ アライ？
あと正直str系の関数が読めない
strlen strpos当たりはわかるけど
stripos strrpos strripos
あたり array：アレイ
ini：initializationの略
stripos：string case-insensitive postionの略だと勝手に思ってる
strrpos：string reverse positionの略だと勝手に思ってる
かっこよく読みたいなら元の単語を略さずに読めばいいんだろうが
実用的にはアルファベットをそのまま読めばいいじゃなかろうか if
イフ
then
ゼン？
else
エルス？
true
トゥルー？
false
フォールス？
ｔｒｙ
トライ？
throw
スロー？
catch
キャッチ？ すみません、>>583で質問したのですが、
再度質問してよろしいでしょうか
サーバのドキュメントルートに置いた
CakePHPプロジェクトフォルダ（仮にCakeとします）
直下の.htaccessを消去しても
http://{hostIP}/cake/
をアドレスバーに打ち込むと、なぜか
https://{hostIP}/cake/webroot/
にリダイレクトされる現象が起きています
.htaccess以外にリダイレクトが起きる原因として考えられるものがあれば
教えていただきたくお願い申し上げます
なお、サーバはapache2.4.10、OSはDebian8.0です routes.phpとかは？
アプリのリダイレクトなのか、
apacheのリダイレクトなのか切り分けていくと良いのでは。 include('/path/file.txt');
include('http://www.example.com/path/file.txt');
って何か違いはありますか？ ■ このスレッドは過去ログ倉庫に格納されています
