【PHP】下らねぇ質問はID出して書き込みやがれ 77
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/12/08(月) 01:27:39ID:???過去スレ、関連スレ、FAQなどは>>2-10辺り
次スレは>>980が立てる。10分以内に立たない場合、宣言してから立てたい人が立てること。
◆前スレ
【PHP】下らねぇ質問はID出して書き込みやがれ 76
http://pc11.2ch.net/test/read.cgi/php/1226517332/
◆質問用テンプレ
【OS名】vine linux
【PHPのバージョン】php5.26
【連携ソフトウェア】mysql
【質問内容】
◆質問する時の注意
・ スレを上げて自分のIDを表示させること。（メール欄に何も記述しない。専ブラのsageチェックを外す）
・ 己の行った操作、変更などを詳しく明記すること。
・ エラーメッセージはそのまま表記すること。「エラーが出ます」だけでは回答不可。
・ 質問者として、態度をわきまえること。
・ 事前に関連リンクの公式マニュアル、リファレンス本くらいはちゃんと目を通しておくこと。
（PHPで最良の教本はこの公式マニュアル。市販の書籍は嘘が多いので鵜呑みにしない。）
◆質問後の注意
・2回目以降は最初に質問した際のレス番号を入れて、偽者防止に必ずIDを表示させること。
・解決しなくても回答をもらった場合はお礼を言うこと。
（荒らし、煽りは除く。煽られたときも、無闇に反論せずスルーすること。）
◆回答者への注意
・誰にレスしているのか分からないと困るので、>>(アンカー)をつけて回答すること。
【その他諸注意】
・SQL・正規表現・PEAR・テンプレート(Smarty等)・フレームワークは各該当スレへ
0696nobodyさん
2008/12/20(土) 23:30:47ID:???0699nobodyさん
2008/12/21(日) 00:02:39ID:???if($hen != "")ってあるんですけど、これって＝の時？それとも＝で無い時？どっち？
!って良く解らないです。ビックリしてるわけじゃないと思いますが。
0703nobodyさん
2008/12/21(日) 00:19:31ID:???詳しく教えて欲しい。
0704nobodyさん
2008/12/21(日) 00:22:14ID:???0705nobodyさん
2008/12/21(日) 00:26:01ID:???処理のパフォーマンスを重視するなら、あり得ない選択。
0706nobodyさん
2008/12/21(日) 00:39:16ID:???0708nobodyさん
2008/12/21(日) 01:24:50ID:???ＰＣユーザの何割がWindowsを使ってると思ってるんだ。↑
0709nobodyさん
2008/12/21(日) 04:20:18ID:???0710nobodyさん
2008/12/21(日) 04:21:40ID:???0712nobodyさん
2008/12/21(日) 05:40:08ID:???0713nobodyさん
2008/12/21(日) 05:53:02ID:???a=b これは代入
0714nobodyさん
2008/12/21(日) 06:10:13ID:???* セキュリティに関する大切な警告なのに、マニュア
ルの後ろの方に書かれている。サンプルコードより前
じゃないと気がつかない人が多そう
* 「なぜ使用してはいけないか」が書かれていない。
なので、対策を読んでも OK の場合と NG の場合の
区別がつかない
0715nobodyさん
2008/12/21(日) 06:25:36ID:???これ結局、どっちなの？
PHPでは、一部のマルチバイトエンコーディングにお
いて、addslashes()を使っているとSQLインジェクション
が発生しかねないよ、はてどうしましょう、というお話。
Chris Shiflett 氏が仰ることでは、addslashes()は使わず
に、mysql_real_escape_string()を使いましょうと。そこへ I
lia Alshanetsky 氏が、いやいや、mysql_real_escape_stri
ng()でも駄目で、Prepared Statements を使いましょう、
と言っているような気がします。一方日本でもこの現象
について触れている文書があります。
0716nobodyさん
2008/12/21(日) 06:28:44ID:???Shift_JISを素直に使っている限り、
addslashes()は駄目(Chris Shiflett氏)、
mysql_real_escape_string() は駄目(Ilia Alshanetsky氏)、
一部のPrepared Statements すらも駄目(id:jrofbyrsさん)、
ということらしいです。
0717nobodyさん
2008/12/21(日) 08:40:48ID:???大手のケータイサイトでさえEUCで作って鯖でシフトジスに変換して出力してんのに
貧乏鯖でしか借りれない人達はがんばってシフトジス（笑）で年越してくださいな
0718nobodyさん
2008/12/21(日) 10:34:46ID:???SET NAMES sjis;等を実行した後に使うと
2バイト目の0x5C文字がエスケープされない
0719nobodyさん
2008/12/21(日) 10:35:19ID:???わけではない」というものがあるが、これは断定できない
ことを言うときの逃げ口上だってことを知っておいたほう
がよい。マスコミには許されるが、技術文書には許されな
い。技術文書なら、前提を明らかにした上でその前提の
上で何が言えるかを書くのであって、例外があるなら例
外を書くようにする。
セキュリティの解説で「どれも完全じゃないからいろいろや
っておこう」という表現が出てきたら、その著者は信頼す
るに値しないと判断してよい。書いてる当人がわかってい
ないから、問題を整理できていないから、そういう表現が
出てくる。
0720nobodyさん
2008/12/21(日) 10:37:30ID:???さっさとやめろ
0721nobodyさん
2008/12/21(日) 10:42:23ID:???0722nobodyさん
2008/12/21(日) 10:44:07ID:???0723nobodyさん
2008/12/21(日) 10:51:21ID:pZUxQjb7UTF-8は、全ての文字が3バイト掛かるんだよ。
サーバー負荷が大きいサイトなら、メモリーが圧迫されることになる。
インフラも含めてプログラミングするのは、真のプログラマーだろ。
そういう視点が抜けているように思うが。
0725nobodyさん
2008/12/21(日) 10:54:28ID:pZUxQjb7今更、EUCって何だよ。俺はCCNPだぞ。もっと考えろよ。
0726nobodyさん
2008/12/21(日) 10:57:12ID:???0727nobodyさん
2008/12/21(日) 12:10:15ID:???>技術文書なら、前提を明らかにした上でその前提の
>上で何が言えるかを書くのであって、例外があるなら例
>外を書くようにする。
これの根拠が示されておらず勝手に決め付けてる。
0728nobodyさん
2008/12/21(日) 12:30:16ID:VviuyWm4$a=" aaa ";
$b=" bbb ";
$c= $a.$b;
print $c;
print "<br>";
trim ($c);
print $c;
?>
なんかこれで、
全然トリムされてないんだけど？？？
0730nobodyさん
2008/12/21(日) 12:52:07ID:VviuyWm4あ、、、
代入しないとダメなんだ、、、
ありがと
0731nobodyさん
2008/12/21(日) 12:52:30ID:???0732nobodyさん
2008/12/21(日) 13:06:16ID:VviuyWm4basenameって日本語使えないの？
0733nobodyさん
2008/12/21(日) 13:07:05ID:???0735nobodyさん
2008/12/21(日) 15:28:56ID:???やっぱ不景気でカツカツな人が多いいの？かわいそうに。
0736nobodyさん
2008/12/21(日) 15:33:09ID:???0737nobodyさん
2008/12/21(日) 15:41:06ID:???0740nobodyさん
2008/12/21(日) 16:04:30ID:???0743nobodyさん
2008/12/21(日) 16:09:21ID:???http://info.2ch.net/guide/faq.html#C5
0745nobodyさん
2008/12/21(日) 22:25:03ID:BLufKTBe同じクラスのメンバやメソッドにアクセスする際に $this->
はつけた方がいいのでしょうか？
class A {
private $hoge;
private function foo() { }
public function bar() {
$hoge = 'なんたらかんたら';
$this->hoge = 'なんたらかんたら'; /* どっちいいの？ */
foo();
$this->foo(); /* どっちがいいの？ */
}
}
0746nobodyさん
2008/12/21(日) 22:37:42ID:???0748nobodyさん
2008/12/22(月) 01:52:46ID:???あと日本語のマルチバイトが３バイト使うってだけでUTF8の全てが３バイトじゃないよね？
信頼性と容量どっちを優先するかは好きにすりゃいい。
自分でよりよい案も出せず文句つけるだけの723には無理だけど。
0749nobodyさん
2008/12/22(月) 02:19:57ID:???帳票出力アプリ任せてたのに、出力データ取得条件が絶対に1件も持ってこない条件だった。
引継ぎ資料には「帳票が出ないのは整合性の取れたデータが無いためです。アプリの動作は問題ありません」
エビデンスのデータで再テスト行っても出力されず。
技術が無くて作業が進まず、それを隠すために逃げたんだろうな
0751nobodyさん
2008/12/22(月) 05:37:08ID:???「ニューヨークにはピアノの調律師は何人いるか？」
って質問されたら、答えられなくて発狂するの？
0753nobodyさん
2008/12/22(月) 06:07:29ID:???スレ違いな上に頭悪いな
0754nobodyさん
2008/12/22(月) 06:13:45ID:???質問されると発狂するじゃん
0755nobodyさん
2008/12/22(月) 06:24:37ID:???0756nobodyさん
2008/12/22(月) 06:31:15ID:???はてなにでも池
0757nobodyさん
2008/12/22(月) 08:53:52ID:Cwv0g3tMPECL::PDOのことなの？
0758nobodyさん
2008/12/22(月) 08:59:25ID:Cwv0g3tMmysqliと、
pear::DBと、
PEAR::MDB2と、
PECL::PDOと、
どれを使えばいいの？
0759nobodyさん
2008/12/22(月) 09:04:29ID:Cwv0g3tMmysqliと、
pear::DBと、
PEAR::MDBと
PEAR::MDB2と、
PECL::PDOと、
どれを使えばいいの？
0760nobodyさん
2008/12/22(月) 09:15:50ID:???使いやすさや開発の効率など機能の利便さを求めるならライブラリ
0761nobodyさん
2008/12/22(月) 09:20:53ID:Cwv0g3tMPDO一択かな
でもそれだと、mysqliが使えないんだけど、
みんな使ってないの？
0762nobodyさん
2008/12/22(月) 09:25:01ID:???0763nobodyさん
2008/12/22(月) 09:41:19ID:Cwv0g3tMmysql_real_escape_string でエスケープしなければ
いけないのか、それとも、しなくていいのか、という議論ですが、
http://labs.cybozu.co.jp/blog/hata/archives/2005-10-04-1.html
このページを読む限りだと、
（１）
PDO::query() でいきなりSQL文を実行する場合
↓
SQLインジェクションの可能性があるので、
自分でmysql_real_escape_stringしなければならない
（２）
prepare()して、execute()する場合、
↓
SQLインジェクション対策を自動的にしてくれる
↓
mysql_real_escape_string 不要
=--------------------------
この理解で合ってますか？
0764nobodyさん
2008/12/22(月) 09:57:12ID:???0765nobodyさん
2008/12/22(月) 09:57:50ID:Cwv0g3tMhtmlentitiesを使ってエスケープする」
という記事を読んだことがあるのですが、
これってマユツバですか？
0766nobodyさん
2008/12/22(月) 10:00:35ID:???あってる。というか、可能な時はいつでもprepareを使え。
DB接続のパフォーマンスがどうしても問題になる場合のみ、しぶしぶmysql関数。
それ以外の場合はPECL::PDO（現在はPECLではなく標準ライブラリ）。
きちんとクラス構成ができていれば、書き換えはそれほど手間ではないので、迷ったらとりあえずPDOで書く。
0767nobodyさん
2008/12/22(月) 10:14:36ID:???その本を燃やせ。というか、出版社を燃やせ。あり得ない。
「エスケープは、出力先に応じて適切なものを選ぶ」のが基本。
出力先はSQLなのだから、SQLとして安全になるようなエスケープを選ぶ必要がある。
DBに応じたエスケープ関数があるはずだからそれを使え。
たとえばMySQLならmysql_real_escape_string。SQLiteならsqlite_escape_string。
ttp://jp2.php.net/manual/ja/refs.database.php
とりあえずそれだと、'NULL OR TRUE'という入力には確実に無防備になる。
WHERE ID = $id
というプログラムに上記文字列がぶち込まれた時にどう動作するか考えてみるといい。
DROPやDELETE、UPDATEと組み合わせた文も上手くやれば発行可能かもしれん。
HTMLの実体参照はよりによってセミコロンを多用するしな。
ユーザー管理テーブルが書き換えられ、RDBMSのroot権限を奪取される事もじゅうぶんあり得る。
0768nobodyさん
2008/12/22(月) 10:15:12ID:???目的がSQLインジェクション対策でないからしなくていい
DBには生のデータを入れるのが基本
XSS等を意識するのは取り出す時
取り出す時に忘れるかもしれないから入れる時にエスケープする人もいるが
取り出す時にエスケープするのは当たり前なので
穴を防ぐ目的としてはいいかもしれないが根本的な解決にはなってない
0770nobodyさん
2008/12/22(月) 10:20:58ID:???0771nobodyさん
2008/12/22(月) 11:27:37ID:YHC8UPCZ画像キャプチャによるフォームの認証のセキュリティについて
画像キャプチャの下にhiddenでその画像キャプチャの値を設定し
認証の時にユーザが記述した値とhiddenの値を照らし合わせるという
やり方はセキュリティー的に問題がありますか？
以前どこかのサイトで
生成された画像キャプチャの値とidを一度データベースに書き込み
hiddenには値ではなくIDを設定、
認証時にそのIDからデータベース検索を行い認証するやり方
を目にし上のやり方はセキュリティ的に問題あるのかなと
ずっと気になっています。
わかりにくい説明ですいませんがアドバイスよろしくお願いします。
0772nobodyさん
2008/12/22(月) 11:29:20ID:???http://gimpo.2ch.net/test/read.cgi/wildplus/1229912492/
0773nobodyさん
2008/12/22(月) 11:31:17ID:???hiddenの値はHTMLのソース見れば
誰でも見れるよね。
つまり、スクリプト等でhiddenの値を
自動的に読み取るようにして、その値を
連続でぶちこまれたら、アカウント10万個とか
取られてしまうのではないかな？
0774nobodyさん
2008/12/22(月) 11:33:23ID:???金庫に鍵をさしっぱなしで一緒に置いておいても
問題がないならいいんじゃないの？
俺ならhiddenにいれずに簡易に済ませるならセッションに入れる
0775nobodyさん
2008/12/22(月) 11:37:46ID:???クッキーにも書き込んでるよね。
クッキーの値はクライアント側から読めるわけで、
もしアタッカーが、クッキーの値を読み取って、
自動的に連続入力するスクリプトをrubyで書いたら
やっぱりアカウント10万個とか取られてしまう。のでは？
0777nobodyさん
2008/12/22(月) 11:46:49ID:???すまん、高度すぎて言ってる意味が分らん
クッキーに入ってるのはセッションIDだろ？
画像チャプタってたいがい都度生成だろうからその都度ID変わるし
都度セッションに値セットするなら仮に違うセッションID使われたとしても
セッションの参照先に値が無いからとおらないだろ
0778nobodyさん
2008/12/22(月) 11:52:47ID:???だから安全性に問題があるとは書いている
0779nobodyさん
2008/12/22(月) 11:57:34ID:???0780771
2008/12/22(月) 12:01:59ID:???>>774
たくさんのアドバイスありがとうございます！
今独学でPHPを勉強してるんですが
アプリケーション作成時にXXSやSQLインジェクション、XSRFなど
どんな時にセキュリティを施せばいいかがすごい難しかったりします。
もう少し頑張って勉強してみます。
本当にありがとうございました！
0781nobodyさん
2008/12/22(月) 12:04:39ID:???ユーザーが手で入力すべき値と
同一なの？
0782nobodyさん
2008/12/22(月) 12:11:23ID:e1MSnnKM上記のエラーが、”たまに”出ます。
70行目は、クラス変数（配列）を宣言している場所です。
var $prefs = array(
'北海道', '青森県', '秋田県', …
：
：
… '宮崎県', '鹿児島県', '沖縄県'
);
といった感じです。
一体なぜでしょうか？
毎回出るわけじゃなく、アクセスすると条件不明でたまに出るのです。
0783nobodyさん
2008/12/22(月) 12:15:33ID:???配列の要素を1万個に増やして
F5しまくって実験
0784nobodyさん
2008/12/22(月) 12:17:34ID:???hiddenに入れる値（以下、キー）に「12345」としたら何の意味もない。これは論外。
じゃあ、推測困難な計算方法で「12345」が導けるようなキーはどうだろう。
たとえば「23456」とか（これだと推測容易なんで、実際はもっと難しい計算を使うべき）。これは悪くない。
これを発展させて、crypt($salt . '12345')とかをキーにする。これも悪くない。まず破られないだろう。
ベストは、キーには「12345」とはまったく無関係の値を入れておき、キーと「12345」の関連付けはDBなどで行なう方法。
これだとDBのデータを知らないと絶対に両者を関連付けられない。
セッション・キーを発行しているなら、もうキーにできる値はあるので、新規に発行する意味もない。
キーとしてセッション・キーを使い、CAPTCHA生成時に「12345」をセッション変数としてサーバーに保存しておけばいいわけだ。
0785nobodyさん
2008/12/22(月) 12:21:03ID:???> これを発展させて、crypt($salt . '12345')とかをキーにする
この場合、キーから'12345'は算出不能になる。
答え合わせは、ユーザーの入力した「12345」を同じ方法でcryptして、両者が一致するかで行なう。
0786nobodyさん
2008/12/22(月) 12:26:46ID:???Shift_JISでプログラムを書くな。
0788nobodyさん
2008/12/22(月) 12:38:02ID:e1MSnnKMUTF-8ですよ
0789nobodyさん
2008/12/22(月) 12:50:13ID:Cwv0g3tM<?php
$user="root";
$pass="abcde";
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
print $dbh;
?>
って書いて実行したら、
Catchable fatal error: Object of class PDO could not be converted to string in
ってエラーが出るのですが、
これを出力するにはどんな関数を使えばいいですか？
自分の予想だと１か０で返ってくるかと思ったのですが。
0790nobodyさん
2008/12/22(月) 12:53:25ID:???0791nobodyさん
2008/12/22(月) 12:56:27ID:Cwv0g3tMやってみたら、
object(PDO)#1 (0) { }
って返ってきました。これって、（０）の部分を
見ればいいの？０ってことは失敗してる？
0793nobodyさん
2008/12/22(月) 13:07:26ID:???データベースへの接続に成功すると、PDO クラスのインスタンスが スクリプトに返されます。
この PDO オブジェクトが存在する間、 接続がアクティブであり続けます。
パスワードわざと間違えたのを入れて、もいちど var_dump($dbh);
0794771
2008/12/22(月) 13:29:14ID:???そう考えてました。
掲示板の新規登録のところを作ってたんですが
個人情報を扱う場所じゃないから
そこまで厳しくしないでいいかなと思ってました・・
明らかに無知ですよね・・
もう少ししっかり勉強します。
>>784
丁寧な説明本当にありがとうございます！
色んな方法があるんですね。
アプリケーションでも様々な物があり
個人情報を登録してもらうフォームや掲示板の新規登録のフォームなど
各々でどこまでのセキュリティを施すべきかの判断が
本当に難しく感じます。
しっかり勉強しようと思います。
0795nobodyさん
2008/12/22(月) 13:30:26ID:???■ このスレッドは過去ログ倉庫に格納されています