アカウント名:
パスワード:
過去の裁判例を検討すると，システムの処理速度に関する瑕疵が「重大な瑕疵」と判断されているケースが目につきます
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
サニタイズ言うな！ (スコア:0, 興味深い)
# と私は解釈しているのだが間違ってますかね。
Re: (スコア:1, すばらしい洞察)
Re: (スコア:1, すばらしい洞察)
考える力が足りないから何度も同じようなSQLインジェクションに引っかかるし、サニタイズ言うなキャンペーンも誤解する
全くどうかしてる
Re:サニタイズ言うな！ (スコア:1)
- そのようなコードを書いた本人
- そのようなコードがあることを見逃して納品した開発チーム or 開発チームリーダ or プロジェクトマネージャ
- そのようなコードがあることを見逃して検収を完了させた発注元
- そのようなコードがあることを知らずにサーバ上に乗っけているインフラチーム
- そのようなコードがあることを知らずに運用させている発注元の経営者
- そのようなコードがあることを知らずに利用しているユーザ
ちなみにこの時、一番被害を蒙るのはどこでしょうか。Re: (スコア:0)
ところでサニタイズ言うなキャンペーンは誰が対象ですか？
ちなみにこの時、サニタイズｗやら文字のエスケープを意識すべきなのはどこでしょうか。
#なんなの？この人？？
Re:サニタイズ言うな！ (スコア:1)
被害を蒙らないことをいいことに意図して罠にかかっている場合を考慮しているのかどうか。
もし、そういう人もマヌケと呼ぶのなら、タブン私と #1432720 のAC氏とはマヌケの定義が違うのでしょう。
と、それはおいといて。
プログラムの作成を発注して意図して穴を残された場合、どこまで瑕疵責任を負わせることができるのでしょう。
IT法務ライブラリ [nikkeibp.co.jp]の記述を見ると、とあるわけですが、セキュリティホールはどうなるのでしょう。
私は法律の専門家ではないので推測しかできませんが、意図しての行為だとしても「滅多に無いことだ」とか「製造時は予想できなかった」と言い張られると追求が厳しそうな。
また、意図してかどうかは、どの程度立証可能なのかとか。考えると厳しそうですけど…。
# 法律の専門家の方、突っ込み願います
もし、もし瑕疵責任を取らせることが難しいとなると、SQLインジェクションによる問題はいつまでもなくならないのかもしれないと危惧してしまうわけです。
そこで、法律上もある程度は瑕疵責任を特別に認定できるようにしておく必要性というものが見えてくるのですが、それはそれで問題がでそうですね。
そんなわけで、開発者は納期に追われて厳しいと言われている昨今、啓蒙だけではSQLインジェクション問題が無くならないのではと思ってしまうわけですが、いかがでしょうか。
Re:サニタイズ言うな！ (スコア:1)
原因が把握され対応もできる脆弱性が敢えて放置されるのはそれを放置しても(利用者はどうかしりませんが)企業は困らないからだと思いますよ。
そして既にそれがデファクトスタンダードになりつつあるから自分のとこがそうでも気にしないのでは？ならば、そもそものところでSQLインジェクション問題が無くなるわけがないと思われ。
◆IZUMI162i6 [mailto]