アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
本当に助かります。 (スコア:2, すばらしい洞察)
有名なIPA ISEC セキュア・プログラミング講座 [ipa.go.jp]では、PHPはないですしね。
現在とあるサイトでクリティカルなバグを見つけてIPAに依頼中です。
そのサイトは全体的に入力チェックという概念が欠如しているとしか思えないのです。
# その割りにRefererチェックは無駄にしてたりする。
# あんなの飾りにしかならないのに。
サンプルが豊富にあるのは良いのですが、セキュリティに考慮していない動作するだけのサンプルを適当に繋ぎ合わせてしまえば見た目が完成してしまいセキュリティバグを生んでいる状
Re:本当に助かります。 (スコア:5, 参考になる)
perl のように「汚染された(Tainted)」という概念が無いのが一番問題な気がします。
PHP で可能な事と言えば
ユーザからの入力を表示する時は htmlspecialchars() を利用する。
# stripslashed() や addslashes() や quotemeta() の利用も。
mysql に渡すユーザの入力は mysql_escape_string() する。
# po
Re:本当に助かります。 (スコア:5, 参考になる)
> # postgresql なら pg_escape_string(), pg_escape_bytea() とか。
私の処ではこれも禁止して、バインド変数を強制してます。
バインドできないDBMSもあるので、PEARのDBが必要になりますが。
# 必ずescapeとquoteしろと指示しても、絶対に抜けや
# 2重espace/unescapeやる奴が出るので。
後、外部コマンドの起動も、上級者の書いたwrapperを経由させてます。
結局、ダメな奴はなにを教えても業務命令出しても守らないので、
クリティカルな所は、バグを出しようがない環境を作ってやった
方が、こちらも精神的に楽です。
# 特定の関数は指定した一部のファイルからしか使えなくする拡張があるといいんですけどねぇ...
wild wild computing