「経産省、Cookie盗聴への対策を指示」記事へのコメント

くっきーはぐはぐ

[Anonymous Coward]

時々メンテや後始末もやってますが、金取ってコード書く前に金払って勉強してこいって感じの仕事にお目にかかる事が多くなりました。セッションハイジャックなんて当たり前。つか動けばいいだけのメンタリティで書かれたと思われるコードが多く、変数汚染に不正なSQLインジェクションもぼこぼこ見つかります。
メーリングリストや質問板に見るユーザー層の質もそんな状態で、基礎理解が不足している上に解法でなく解答を求める人が大半。最近は素人に素人がリプライ付

Re:くっきーはぐはぐ

[mishima (737)]

結局、開発時に発注元が「できること」だけでなくて
「できないこと（XSSできない、不正なSQLは投げられない、など）」も
機能に盛り込んでいかない限り、改善しないんだろうなぁ。
しかし、現状では「できないことは機能ではないし、払う金はない」なんて言われそうだな。

「できない機能を盛り込んでトラブルを抑え、運用費を削減しました！」
みたいな成功体験はないのかな…
そういうのがあれば管理職を説得しやすいと思うんだけど。

--
# mishimaは本田透先生を熱烈に応援しています

Re:くっきーはぐはぐ

[Anonymous Coward]

そういうフレームワークを独自に作るしかないのかな？

Re:くっきーはぐはぐ

[Anonymous Coward]

>「できないこと（XSSできない、不正なSQLは投げられない、など）」も
>機能に盛り込んでいかない限り、改善しないんだろうなぁ。
>しかし、現状では「できないことは機能ではないし、払う金はない」
>なんて言われそうだな。

そういうのは

Re:くっきーはぐはぐ

[Anonymous Coward]

もし機能だとするなら
「XSSできない」じゃなくて
「XSS攻撃に対する耐性がある」かな。

機能というより品質や安全性に関する要件だと思う。
最低限守るべきお約束みたいな。
そういうのを毎回お客さんが書くのって大変だから
汎用的な「ネット利用のアプリの安全性に関する要件」の文書を
どこぞの専門家さんに書いてもらって
それをGPLのように公開して御自由にお使いください
になるといい