アカウント名:
パスワード:
PHPだと$_REQUESTが諸悪の根源だってことなのかな。PHPerにとっては常識だと思うんだけど・・・。
それは$_REQUESTを使うことが問題なのではなくて、それ以前にリクエストメソッドのチェックが必要な場面でチェックしてないことが問題なのでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
モノの品質に問題あるんじゃないのそれ (スコア:1)
PHPerにとっては常識だと思うんだけど・・・。
仕事でこれ使ったコード見つけたら 書いた奴呼び出してシバき倒すけどね。
中途採用でVBを10年やってました!って奴がこういうことを知らずに書くから怖い。
というか畑違いはこっちくんなと・・・。
// そして泣く泣く修正し深夜に全工程をテストして再リリースの王道パターン(:>^
// 新人だけのプロジェクトとか技術者一年生向けの問題周知なんだろうけど。
Re:モノの品質に問題あるんじゃないのそれ (スコア:2, 参考になる)
theInsiderman(-1:フレームの元)
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
このへんとかですね。
>これらは信頼できるとは限りません。
としか書いてないや。
Re: (スコア:0)
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
考えが甘いかなぁ(Cookieだけに)
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
すいません知りませんでした。(仕事じゃないけど)
なにがまずいんでしょう?
Re:モノの品質に問題あるんじゃないのそれ (スコア:3, 参考になる)
とかいうリンクを他人に踏ませると、このセッションIDでログインさせる事ができる。
(PHPSESSIDという名前のクッキーも、get変数PHPSESSIDも、$_REQUEST['PHPSESSID']では区別しないから)
要するに、セッションキーを盗むのと同じ効果が得られる。セッション・フィクセーション攻撃という、古い古い攻撃手法。
phpのバージョンが古く、session_start()でセッション管理をしてる場合、phpが$_REQUEST相当の変数からセッションキーを読み出す仕様になっている。
それ以外でも、POSTとGETを区別しない$_REQUESTは色々マズい。
例えば<img src="http://www.example.com?title=spam&text=hoge">なんてタグを適当な場所に貼る事で
掲示板に連POST、みたいな事もできたりする。
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
Re: (スコア:0)
Java Servlet方面(のお勉強)でも、
doGetとdoPostを速攻で同じひとつのメソッドに委譲しちゃう、なんてな実装は
ふつうに書かれていますな。
…致命的?
>例えばなんてタグを適当な場所に貼る事で
>掲示板に連POST
これは「掲示板はGETで書けるように実装すべきではない」っていう話ですか?
…そんなの掲示板の仕様によるんじゃないの?
「ふつうの」掲示板ではたしかにGETで書けるようにしとくメリットは少ないけど。
Re: (スコア:0)
getとpostを同一視していい場合と、してはダメな場合がある。
検索フォームなんかはどっちでも受け取れたほうが便利だし、実際そうなってる事が多い。
一般に、参照系はgetでも問題ない事が多い。getという名が示す通りだが。
逆に、データ送信系、投稿系など副作用のあるものをgetで受けてしまうと火種になる。
>「掲示板はGETで書けるように実装すべきではない」
結論から言うとイエス。
途中の遷移(表示確認とか)はgetを使ってもいいが、最後の最後、サーバー側のDBなりストレージなりに
変更を加えるリクエストは、一切の例外なく、技術的に可能ならば常にpostのみを受け付けるべき。
Re: (スコア:0)
それは$_REQUESTを使うことが問題なのではなくて、それ以前にリクエストメソッドのチェックが必要な場面でチェックしてないことが問題なのでは?
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
自分も知りませんでした。
デバッグくらいでしか使ってないですけどね。
Post/Getの取得用のラッピング関数を作って使い回してます。
Postのみ有効とか、Getも取得するとか・・・・仕様変更が楽なので。
Re: (スコア:0)
・仕様変更したらペネトレーションテストでパスしていた項目が通らなくなった!
・新人がPOSTとGETは区別せず扱うものだと学習した!
どれがいい?
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
これは、リリース手順に問題があるって事では?
テストしないでリリースなんて・・・してる人たまにいそうですね。
ってか、デバッグくらいでしか使わないとは言ったけど、デバッグで常に使うわけではないし。
>・仕様変更したらペネトレーションテストでパスしていた項目が通らなくなった!
これも仕様変更の方法の問題では?
通らなくなったら、通る方法を考えなければいけないのはどんな仕様変更でも可能性はあるでしょう?
>・新人がPOSTとGETは区別せず扱うものだと学習した!
これは問題ですね。
でも、直接$_POST/$_GETにアクセスさせると、それはソレで障害のタネになるので一長一短はありそうです。
基本はPostしか使わないようにしていれば、リスクは軽減されると思いませんか?
Re: (スコア:0)
最近はRESTというものが流行っておってのう
Re: (スコア:0)
SQLインジェクションが問題な訳であって、値取得方法は
REQUESTだろうと何だろうと問題ないのでは?
SQL発行時にエスケープ(サニタイジング)処理を
行ってないのが根源かと。
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)
inputはどんなのでも、DBに入れる段階でキチンと検査・下処理しておけばinjectionは起きませんものね。
phpが話題に上がっているのは$_GETと$_POSTと$_COOKIEがマージされたものが$_REQUESTに入るから
値が本当にそのmethodで来たものかは件の機器では分からないよ、ってことらしいですな。
そもそも検査とかデータの正当性検査とかは組み込む奴が作るものだし、
何某の機器で誤魔化そうとすること自体に違和感を感じるけどなぁ。
Re: (スコア:0)
デフォルトでONだったりするために
SQL発行時にまたエスケープすると駄目なケースもあるかと。
自作ならいいけど、途中から派遣されて参加した場合は
設定変えろとも言えないし。
Re:モノの品質に問題あるんじゃないのそれ (スコア:1)