【PHP】下らねぇ質問はID出して書き込みやがれ 81
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2009/02/18(水) 21:09:16ID:xNLzAD7T過去スレ、関連スレ、FAQなどは>>2-10辺り
次スレは>>980が立てる。10分以内に立たない場合、宣言してから立てたい人が立てること。
◆前スレ
【PHP】下らねぇ質問はID出して書き込みやがれ 80
http://pc11.2ch.net/test/read.cgi/php/1233479457/
◆質問用テンプレ
【OS名】vine linux
【PHPのバージョン】php5.26
【連携ソフトウェア】mysql
【質問内容】
◆質問する時の注意
・ スレを上げて自分のIDを表示させること。（メール欄に何も記述しない。専ブラのsageチェックを外す）
・ 己の行った操作、変更などを詳しく明記すること。
・ エラーメッセージはそのまま表記すること。「エラーが出ます」だけでは回答不可。
・ 質問者として、態度をわきまえること。
・ 事前に関連リンクの公式マニュアル、リファレンス本くらいはちゃんと目を通しておくこと。
（PHPで最良の教本はこの公式マニュアル。市販の書籍は嘘が多いので鵜呑みにしない。）
◆質問後の注意
・2回目以降は最初に質問した際のレス番号を入れて、偽者防止に必ずIDを表示させること。
・解決しなくても回答をもらった場合はお礼を言うこと。
（荒らし、煽りは除く。煽られたときも、無闇に反論せずスルーすること。）
◆回答者への注意
・誰にレスしているのか分からないと困るので、>>(アンカー)をつけて回答すること。
0158nobodyさん
2009/02/20(金) 22:27:27ID:???0159nobodyさん
2009/02/20(金) 22:37:43ID:???世の中にはいくらやっても報われないことが二つある
ひとつは賽の河原の石積み
もうひとつはお前のPHPの勉強だ
0160nobodyさん
2009/02/20(金) 23:27:51ID:r16tK4jF基本的に外部入力値をhtmlspecialcharsしていれば良い
って考えは間違い？
0162nobodyさん
2009/02/20(金) 23:34:48ID:???>>161はhtmlspecialcharsを使用しても抜けられる穴について説明よろ
0163nobodyさん
2009/02/20(金) 23:39:40ID:???htmlspecialchars(,ENT_QUOTES)で防げるのは「Script Injection」。
Javascript埋め込みとかそんなヤツ。
「SQLインジェクション」は別問題。
「PHPサイバーテロの技法」を買って読んどけ。
0164nobodyさん
2009/02/20(金) 23:47:18ID:???LIKEのとこに%とか*突っ込んでみるとか。
select * from table where name like '%' ;
0165nobodyさん
2009/02/21(土) 00:28:20ID:???$str = '<font size="10">でっかい</font>';
$smarty->assign('tag', $str);
$smarty->display('hoge.tpl');
---hoge.tpl---
<body>
{$tag}
</body>
とかいう意味だったら笑う。
>162
>164の変数名のところに「' OR 1=1」と入れるとレコードが全件変数に入り個人情報大暴露大会。
「'; DROP なんたらかんたら」と書くとテーブルがぶっ飛ぶ。レプリケーション先も全部死ぬからサービス復旧不能で店じまい、会社は倒産。
MySQLの設定が甘いと、管理テーブルを書き換えられてroot奪われるとかもあるな。
0166nobodyさん
2009/02/21(土) 00:32:30ID:???0169nobodyさん
2009/02/21(土) 01:19:11ID:???0171nobodyさん
2009/02/21(土) 01:47:18ID:???クエリの9割以上はカバーできるはずだ
0172nobodyさん
2009/02/21(土) 02:05:10ID:???0173nobodyさん
2009/02/21(土) 02:17:42ID:???ありえねーな
likeを使ってなかったらだいじょうぶ？
0174nobodyさん
2009/02/21(土) 02:35:53ID:60WB0UqAある本にmysql_escape_stringより良いって書いてあったのに、早いって。。
純朴な素人をバカにしやがって
0175nobodyさん
2009/02/21(土) 02:37:42ID:???本にWebに書いてあることを鵜呑みにすることが「勉強」じゃないぞ？
0176nobodyさん
2009/02/21(土) 02:44:35ID:???だいたいこの関数はSQLステートメントとして成立する文字列リテラルを作るためのものだ
%を勝手に殺したりする用途に使うもんじゃない
0177nobodyさん
2009/02/21(土) 02:45:52ID:???エスケープする必要ない
0178nobodyさん
2009/02/21(土) 02:46:31ID:???0180nobodyさん
2009/02/21(土) 02:49:17ID:RWcdEiGuprintしているのですが、これってもしreadonlyに対応していない
ブラウザとかだったら変更可能ですかね？ブラウザとか関係なく、
もし確実じゃなければ、それに代わる確実な方法を実現したいのですが
何か方法があれば教えてください。
0183nobodyさん
2009/02/21(土) 12:05:11ID:???そもそも、ブラウザなんぞ無くともデータは送受信可能だ。
HTTPなんて、テキストデータを送受信してるだけだからな。
クライアントに渡した全ての値は改竄され得るし、クライアントから送信される値は全て信用ならない。
input type="select"の中に、選択肢にない文字列が入ってくるなんてのはよくある事だ。
0184nobodyさん
2009/02/21(土) 12:05:51ID:???0185nobodyさん
2009/02/21(土) 13:04:41ID:???SELECT * FROM test WHERE name='".htmlspecialchars($_POST["name"],ENTQUOTES)."'
としていれば大丈夫なんじゃないのか？
「%」の件もlike使わなければいいわけだし。
like使う用途って「検索」が多いだろうから、表示されても良いデータだろうし。
0187nobodyさん
2009/02/21(土) 13:10:58ID:???そのセンス、感服するわ。
htmlspecialcharsで変換される文字君たちは検索にかからなくなるわけだが、
SQLにlikeを使わなきゃいいって制約を追加するわけだが、
0188nobodyさん
2009/02/21(土) 13:14:04ID:???mysqlなら何も考えずmysql_real_excape_stringが一番安全確実簡単だろ。
htmlspecialchars使うと、<や>、&のような文字が全部変換されてDBに入力されてしまう。
検索なら対象がうまくヒットしなくなるし、画面表示文字列だとエスケープ/アンエスケープのタイミングを考慮しないといけない。
DBからCSVに書き出したくなったらどう変換すればいいんだ？JavaScriptに渡す時は？
mlsql_real以下略なら、入力データはそのままの形でDBに格納されるし、そのままの形で検索される。この上なく分かりやすい。
0189nobodyさん
2009/02/21(土) 13:16:13ID:???うん？クラスの処理とかすべて書けば良かったか？
単純かしたことに「こいつ馬鹿だwww」と感服したのかもしれないが。
そもそも、出力する時もフィールド指定するだろ。
だから、like使ってもパスワードが漏れないよな。
全件出力されるとか書いてたけど、普通limit指定するし。
>htmlspecialcharsで変換される文字君たちは検索にかからなくなるわけだが
かからなくていいんじゃないか？検索させない場合は、変換入れるだろうが。
0190nobodyさん
2009/02/21(土) 13:16:27ID:???基本的には「'」と「\」だけでいいんだぜ
0191nobodyさん
2009/02/21(土) 13:19:03ID:???「そのままの形で格納されると困る」んだよ。
お前、WEBアプリケーション作ったことあるか？
または、会員制サイト作って誰かに利用させたことあるか？
その際、htmlspecialcharsで変換されない文字があるとどうなるかわかるだろ。
それに、htmlspecialcharsだけでも、CSV出力やJavascript（AJAX）の利用は出来る。
0193nobodyさん
2009/02/21(土) 13:26:33ID:???人柱だれかよろ
ttp://sourceforge.jp/magazine/09/02/19/2316221
0195nobodyさん
2009/02/21(土) 13:27:36ID:???よく開発続けられるよなｗｗｗｗｗ不人気なのにｗｗｗｗｗｗｗ
0196nobodyさん
2009/02/21(土) 13:29:18ID:???後輩とかに指摘されて恥かくまでずっとやってろ
0197nobodyさん
2009/02/21(土) 13:30:31ID:???先輩は「フォー・イーチ」って読んでた
別に恥ずかしくないんだからねっ！これからも「フォレーチ」って読むわ
0198nobodyさん
2009/02/21(土) 13:32:44ID:???なぁ、ちょっと確認していいか？
入力->フィルター->エスケープ->DB -> 取り出し-> フィルター -> html適合化 -> 表示
おまえこの流れは理解してるってことでいいんだよな？
0199nobodyさん
2009/02/21(土) 13:34:46ID:???0200nobodyさん
2009/02/21(土) 13:35:45ID:???ネーミングが悪かったかもしれない
XAMPPは初心者もなじみやすい名前だから、暫くはそっちが流行ると思うな
0201nobodyさん
2009/02/21(土) 13:36:24ID:???会員制の課金の発生する、バックエンドでCSVとTSVでレポートを吐くwebアプリを仕事で書いてるが、
・DBに渡す際にPDOのプレースホルダで渡す、あるいはmysql_real_escape_stringなどでクエリを構成する
・画面表示する際にはビューに渡す時点で原則全ての値をhtmlspecialcharsでエスケープ
（タグを書き出さないといけない箇所や、HTML以外の箇所などの例外は慎重に検討したうえでエスケープせず渡す）
・DBには、例えばフォームからの入力なら入力値がそのままの形で格納される
このルールが一番分かりやすいし、安全だし、汎用性がある。
出力部で「この文字列はDBから来た値だからhtmlspecialcharsは不要、こっちはクライアントからの入力値だから必須…」とかやってると、絶対変換ミスが発生する。
何も考えずルールにさえ従ってさえいれば脆弱性が発生しない事をシステムが担保してくれる形にするのが一番安全なんだよ。
俺はMySQLでの危険文字を全て列挙すら出来ない低能だし、職場には俺以下の屑が溢れているが、このルールに従う限り絶対安全だとシステム側で保障できるコードを組める。
0203nobodyさん
2009/02/21(土) 13:41:54ID:???それでOKなんだけど、>>191はフィルターやバリデーターとDB登録時のエスケープを混同してるらしいからｗ
0204nobodyさん
2009/02/21(土) 14:03:40ID:???俺が使ってるサービスで
↓を混同してるプログラマがコード書いてませんように・・・
・DB入力時(SQLインジェクション)
・画面出力時(Scriptインジェクション)
0205nobodyさん
2009/02/21(土) 14:14:16ID:???雑談はネタ不足気味な雑談スレで。
http://pc11.2ch.net/test/read.cgi/php/1200314111/
0206nobodyさん
2009/02/21(土) 14:20:49ID:???ああ。実際に>>201が書いているようなことはしているよ。
例として>>185みたいな簡単な1行ソース出したから
「こいつ何も知らない馬鹿だなwww」と煽りたい気持ちも分かる。
だが、1から10までここに書けないだろ。
入力時、出力時にそれぞれ適切に変換するのは、初歩中の初歩だと思う。
201がああだこうだ書いてるが、俺は自作クラス作ってDB処理をしているから
変換ミスがどうのこうのはない。
ま、そういう自分の事はどうでも良くて、>>185の意見を出しただけなんだが
なぜか俺自身を煽りたい馬鹿がいるな。そんな事しても無駄だろ
0208nobodyさん
2009/02/21(土) 14:26:20ID:???>だが、1から10までここに書けないだろ。
ちゃんと読めよ・・・わかりやすいように簡単に書いたって言ってるだろ
それに、htmlspecialcharsで変換しないでそのまま格納したとする
その場合、phpMyAdminなどで管理する時。どうなるかわかるよな？
0209nobodyさん
2009/02/21(土) 14:27:37ID:???こんだけ書かれてまだわかんないのか。
そこでhtmlspecialcharsはおかしいってことだろ。
代わりに何を使うべきか考えてみろ
0211nobodyさん
2009/02/21(土) 14:28:10ID:???>>206が仕事ではなく趣味でPHPいじってるだけであることを祈る
0212nobodyさん
2009/02/21(土) 14:28:18ID:???うん、あれはhtmlspecialcharsで変換されて出力されるね
ってかphpMyAdminなんか使ってるのかよ
0213nobodyさん
2009/02/21(土) 14:28:48ID:???わかる・わかんないの、俺に対しての批判はどうでも良いんだよ。
「なぜhtmlspecialcharsは駄目なんだ」って事だ
0214nobodyさん
2009/02/21(土) 14:29:08ID:???phpMyAdminをなめてんの？
別にスクリプトが混入したって何もおきないよ。
もし、そこでスクリプトインジェクションされんならIPA行きだお
0216nobodyさん
2009/02/21(土) 14:30:27ID:???「phpMyAdminなんて使ってるの？」って言葉がここで出てくると思わなかったぜw
ここのスレの役割考えろや。どうせ個人叩きしかできないくせに。
0217nobodyさん
2009/02/21(土) 14:30:31ID:???全部わかったうえで一部分だけ簡単に書いてます、って言ってるやつの文章じゃないよそれ
結局DB格納時にhtmlspecialchars使ってるんじゃん
0219nobodyさん
2009/02/21(土) 14:32:07ID:???> 俺は自作クラス作ってDB処理をしているから変換ミスがどうのこうのはない。
変換とか言ってる段階で、その自作クラスが穴だらけに1000カノッサ
0220nobodyさん
2009/02/21(土) 14:36:47ID:???> その場合、phpMyAdminなどで管理する時。どうなるかわかるよな？
phpMyAdminは出力時サニタイズをすっかり忘れてる、ってこと？
0221nobodyさん
2009/02/21(土) 14:38:07ID:???0222nobodyさん
2009/02/21(土) 14:38:47ID:???ENTQUOTES
ENTQUOTES
ENTQUOTES
ENTQUOTES
ENTQUOTES
ENTQUOTES
ENTQUOTES
ENTQUOTES
0223nobodyさん
2009/02/21(土) 14:40:08ID:???0224nobodyさん
2009/02/21(土) 14:40:18ID:???>>201が「俺はMySQLでの危険文字を全て列挙すら出来ない低能」と
言ってる意味を理解できていない、に1000カノッサ上乗せ
0226nobodyさん
2009/02/21(土) 15:07:41ID:???http://www.yahoo.xxco.jp/
0227nobodyさん
2009/02/21(土) 15:11:56ID:???SQLとHTMLでは、特殊な扱いになる文字が違うよってことだけど。
htmlspecialchar()でも問題なく見えるのは、たまたま、だと思ったほうがいいよ。
偶然にも、置き換え対象になる文字がSQLでエスケープが必要な文字と同じだったってこと。
ついでに言えば、エスケープの仕方は実際はDB依存だから
addslashes()じゃなく、DB専用の関数を使ったほうがいい。
0228nobodyさん
2009/02/21(土) 15:13:44ID:???・DBに渡す際にPDOのプレースホルダで渡す、または専用関数(mysql_real_escape_string)でクエリを構成。
・html出力時にhtmlspecialchars(,ENT_QUOTES)をする。
※DBに渡す際にhtmlspecialcharsするのは間違い。
→ 理由 >>188
→ それでも分からない。 >>163の本を読め。
0229nobodyさん
2009/02/21(土) 15:18:48ID:???GET / HTTP/1.1
Host: www.yahoo.xxco.jp
(略)
HTTP/1.x 302 Found
Date: Sat, 21 Feb 2009 06:15:31 GMT
Server: Apache/2.2.9 (Fedora)
X-Powered-By: PHP/5.2.6
Location: http://www.google.co.jp/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
0230nobodyさん
2009/02/21(土) 16:10:53ID:???0231nobodyさん
2009/02/21(土) 16:11:49ID:???xxco.jpの管理人が、
www.yahooo.xxco.jpへアクセスした場合に
「Location: http://www.google.co.jp/」へリダイレクト(302)するようにしているだけ。
<?php
header('Location: http://www.google.co.jp/', True, 302);
?>
0233nobodyさん
2009/02/21(土) 16:35:25ID:???僕レンタルサーバー使ってるからね！
エスケープしなくても安全よっ！
0234nobodyさん
2009/02/21(土) 19:59:23ID:230PJjNE【PHPのバージョン】php5.2.5
【連携ソフトウェア】mysql
【質問内容】
Webアプリケーションで、ウィンドウ毎に違う情報を引き継いで処理をしていく物を作っています。
uniqid()でセッションIDを割り振って、formのhiddenに入れると引き継げるのは分かりました。
しかしこれだと、link（aタグ）で機能を選択した場合に、セッションIDが引き継げないように
思います。ですよね？？何か良い方法はありませんか？
リンクのパラメータに追加するとなると、全部のリンクに書き足す必要があって大変だし、
POSTとGETの両方の評価が必要になると煩雑だし、そもそもurlにセッションIDを出すのが
微妙に避けたいので・・・。
お知恵を拝借したいです。よろしくお願いいたします。
0235教えて
2009/02/21(土) 20:15:36ID:1h/i9qY8<?php
$numbers = range(1, 20);
shuffle($numbers);
for($i = 0; $i < 20; $i++) {
echo $numbers[$i]."<br>\n";
}
?>
0236nobodyさん
2009/02/21(土) 20:16:32ID:???ケータイの場合はGET渡ししかない
0238nobodyさん
2009/02/21(土) 20:21:23ID:???モバゲーではこの程度の言語障害者珍しくも無い
マジ日本はどこへ向かうんだ
$numbers = range(1, 20);
shuffle($numbers);
echo array_pop($number);
// なんか処理
echo array_pop($number);
// なんか処理
echo array_pop($number);
…
1ページ内の処理ならこれでいける。
2枚以上の画面にわたって変数を持って行きたいならセッションを使うしかない。
0239234
2009/02/21(土) 20:33:28ID:230PJjNECOOKIEですか・・・ちょっと調べてみます。ありがとうございます。
クライアントはパソコンなので、GETでもPOSTでも使えます。
COOKIEでもウィンドウ毎って可能なんですか？
0240nobodyさん
2009/02/21(土) 20:38:24ID:???パソコンならhiddenを使う必要ない。セッションはクッキーが勝手に確立してくれる
GETやらPOSTも意識する必要ない。セッションに少し慣れればすべて解決する
別ウインドウのことを言ってるのだとしても
リンクやフォームから作成された別ウインドウは同一セッションとなる
0243242
2009/02/21(土) 20:58:18ID:???同一セッションで別ID発行してもセッションが上書きされるだけだからダメか
0244nobodyさん
2009/02/21(土) 20:59:36ID:???で質問。
入力->フィルター->エスケープ->DB -> 取り出し->
ここまではわかるが。
その後なんでまたフィルタにかけるの？
while文でたとえば
<? while ( $item = mysql_fetch_array( $result ) ) { ?>
<tr>
<td><?= $item['item_id'] ?><?= $item['item_id2'] ?></td>
<td><?= $item['item_name'] ?></td>
<td><?= $item['author_name'] ?></td>
<td><?= $item['publisher_name'] ?></td>
<td><?= date( 'Y年m月d日', strtotime( $item['release_date'] ) ) ?></td>
<td><?= $item['list_price'] ?></td>
<td><?= $item['sale_price'] ?></td>
<td><?= get_category_name( $link, $item['category_id'] ) ?></td>
<td><?= $item['quantity'] ?></td>
<td><?= $item['state'] ?></td>
<td>
<nobr>[<a href="admin_edit_item.php?item_id=<?= $item['item_id'] ?>">編集</a>]</nobr>
<nobr>[<a href="admin_del_item1.php?item_id=<?= $item['item_id'] ?>" onClick="return confirm( '完全に削除されます。よろしいですか？' )">削除</a>]</nobr>
</td>
<? $n ++; } ?>
でまわしてはいかんのかね？
0245nobodyさん
2009/02/21(土) 21:09:52ID:???俺も取り出しのあとのフィルターってのはよくわからん
DBには正しいものが入ってるはずだしな
でもhtml適合化は必要だろ。そのコードだとScript実行されるよ
0246234
2009/02/21(土) 21:10:06ID:???そうなんです。>234の様にformかurlに入れれば、
とりあえずウィンドウ毎に別の情報を引き継げます。
だけど、formとurlの両立が難しい。
何か、簡単にウィンドウ毎を識別する方法があれば・・・
0247244です。
2009/02/21(土) 21:15:34ID:???0248nobodyさん
2009/02/21(土) 21:17:49ID:???まったく同一のページを2ウィンドウ開くのならば、URLかPOST値にセッション情報を含めないとダメだな。
手を抜くならセッションキーGET渡しで
・Smarty使ってるならポストフィルタで全サイト内リンクにセッションキーを追加する
・JavaScript経由で全リンクをセッションキー付きに書き換える
辺りか。
リンクを書き換えないなら、複数ウィンドウシステムに入った時点で
index.php/hogehoge/
index.php/fugafuga/
のような固有URLを割り振り、これをセッションキーにするのも手。
index.php/hogehoge/menu から <a href="./information">で
index.php/hogehoge/information に遷移させられるから記述が多少楽になる。
ただし、セッション情報がリクエストヘッダでだだ漏れだし、外部リンクに気を払う必要も出てくる（REFERERで漏れる）。
0249nobodyさん
2009/02/21(土) 21:20:12ID:???>入力->フィルター->エスケープ->DB -> 取り出し-> フィルター -> html適合化 -> 表示
どこにそんなことが書いてある？
入力 -> エスケープ -> DB -> 取り出し -> サニタイズ -> 表示
これでいい
0250nobodyさん
2009/02/21(土) 21:26:33ID:???サニタイズってのは、入力値に不正な値や壊れた文字列が入っていないかをチェックするもの。
やるなら、入力の直後だが、サニタイズって言うと、>>249みたいな誤解をするやつがいるから、
入力後にやるのが、バリデート＋フィルター。
0251nobodyさん
2009/02/21(土) 21:28:51ID:???DBってのはデータストア。
収録されたデータをすべて出力していいとは限らないし、
形式によってはフィルターをかける必要がある。jk
0252nobodyさん
2009/02/21(土) 21:33:13ID:???入力段階でチェックするのはvalidate
sanitizeは表示段階で、浄化、つまり悪意のあるスクリプトやタグを無効にするもの
0253nobodyさん
2009/02/21(土) 21:43:54ID:???エスケープやサニタイズとは別の話題。
0254nobodyさん
2009/02/21(土) 21:44:23ID:???まぁ、そう思っててもいいけどな。
それは、htmlspecialcharsをサニタイズだと思っている子たちの誤解
悪意と善意を確実に識別できるのはどこかを考えれば正解はどっちかわかるはずだが、
困ったことに、サニタイズ≒出力フィルタだと書いちまってるサイトやら本があるからなぁ。
要するに、サニタイズなんて曖昧なメタファーでプログラムを語るなってことだ。
0258234
2009/02/21(土) 21:48:33ID:???そうですよね。ありがとうございます。
固有URLの実装方法は分かりませんし、
そもそもフレームワークにCakePHPを使うので、そういうURLなのです。
リンクじゃなくて、全てformのボタンにするのも手ですかねぇ・・・。
■ このスレッドは過去ログ倉庫に格納されています