パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

最も危険なプログラミングエラーTop 25、2010年版」記事へのコメント

  • by Anonymous Coward on 2010年02月19日 11時48分 (#1720722)

    「開発チームのメンバー全員がセキュアプログラミング技術のトレーニングを適切に受けていることを確証する責任を負」っているからと言って、実際そう作られるかというのは別問題ですよね?

    • by nn1963 (35819) on 2010年02月19日 12時14分 (#1720749)

      マジレスすると、以前委託したECサイトのテスト中、入力項目にfontタグ入れてみたら
      見事に文字が赤くなったり大きくなったり。。。

      なんでサニタイズせんのじゃ~~!と委託先にクレームあげたら「最初に言え!」とか
      開き直られました。「んなもん、常識だろうが!」とこっちも吠え返して、社内にあった
      WEBプログラミングのテキストからXSSだのSQLインジェクションへの対策のページを
      送りつけてやりました。

      こういうのって、要求仕様に明記しないといけないのでしょうか?
      呼吸するように実装してくれないと、発注側としては安心できないのですが。

      親コメント
      • by soltiox (25610) on 2010年02月19日 12時39分 (#1720768) 日記

         …… め、めはらみか?

        マジレスすると、この話の受注側はタコだし、
        「んなもん、常識だろうが!」も、もっともなんだけど、
        要求仕様への明記は必要じゃないかな。

        親コメント
      • by heavensgate (21016) on 2010年02月22日 19時07分 (#1722204)

        日本人同士であればまだ阿吽の呼吸でやってくれたりしますが、海外、ことに中国系の場合、
        「書いてないことは全くもってやらない」
        ですよ。書いてあることは「書いてあるとおりに」やってくるけど。
        ※そもそも設計に矛盾があったとしても「書いてあるとおりに」実装してきます

        日本人であれば、実際に組んでいるときに「あれ? これ何かおかしくない?」と気付いたら、それとなく設計に尋ねてみたりするなどして事前に潰せたりするのですが、日本人以外の場合はそのようなことはなく、「設計が気付いてないならしったこっちゃない。うちらは指示通りに組むだけだし」と。分業の徹底といってしまえばそれまでかもしれませんけど。

        まあ、「書いてあること無視する」どこぞの IT よりはマシですが……

        --
        -- To be sincere...
        親コメント
      • この前、Webアプリなのに複数人が同時に編集することを考慮してない画面があって直してたんですが、
        隣の席の中国人に「こういう問題起こさないようにな。」って話したら、
        「こういうところはチェックを入れた方がいいんですか?」って返されました。

        いや、Webアプリなんだからそんなこと考えるまでもないだろ!と久しぶりに声を荒げてしまった。
        むしろ何でチェックを入れなくていいなんて思えるんだ?
        排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか・・・orz

        # サニタイズ?もちろん毎回言わないとやりませんが何か? 新人じゃなくてWebアプリ経験4年てー。
        # 即戦力だの派遣だの寝言言わずちゃんと教育しようぜ(涙

        • by Anonymous Coward

          > 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか

          あなたがどういう立場なのかわかりませんが、それぞれを対処するのにも、システムごとにそれなりにやりかたがあります。ぶっちゃけ、排他制御について、一人のユーザーが使っていたら、他のユーザーの利用を止めてしまうシステムも山のようにあります。

          なんで、そういうことを対処してほしいと思うなら、明確に仕様の段階で盛り込むべきです。設計書を作成した段階で漏れている方が悪いと思います(漏れていることを指摘出来なかった方も悪いけど)。そんで、口頭でしか言わなかったということは、テスト項目から漏れているわけで、当該のシステムの利用はちょっと怖い気がします。

          • by Anonymous Coward

            失礼。誤解を招いたようなので追記します。

            そのシステムを設計したのも作成したのは、私とも隣の人とも縁もゆかりもない別の会社の方々です。
            そんな糞システムなので、えぇ全く持って利用するのも保守するのも怖いです。

            一概に排他制御を入れられない、というのはもちろん判りますが、だからといってデータが壊れるような状況を目にしておいて対策を入れたほうがよい?何て疑問系で出てくるのが信じられませんでした。
            文化の違いとかそんなレベルではなく、プログラマとして間違っていると言いたくなります。

            • by Anonymous Coward

              後からコミットされた方のデータを有効にする、というやり方もあるわけで。
              何をもってデータが壊れるとしているのかもわかりません。

              • by Anonymous Coward

                そこが本題のつもりは無かったのですが、何か気にされているようなのでレスします。

                データが壊れるは文字通りの意味ですね。削除済みのデータにリレーション貼るとか、データがあるのにリレーション消すとか。
                後優先とかで何かしら完全性が保たれていれば、ああそういう設計なのかとも思えるんですが・・・。
                そんなの常識だ!は駄目だと批判されていますが、せめてそれぐらいは考えてほしいです(涙

              • by Anonymous Coward

                参照制約ぐらい言わなくてもつけてくれると思ってた。

                なんてね。
                元コメが全てで「結局契約と金次第」です。
                「安ければなんでも良い」なんて方々もいるのですよ。
                サニタイジングにはその分手間とテストが増えるわけで、その分のコストを見積もっているかどうかです。

              • by Anonymous Coward

                ここで一句

                「そこからか そこからいわんと だめなのか」

                なぜか社内オフショア状況に陥ったSEの世事の句

              • by Anonymous Coward
                >SEの世事の句

                辞世の句でなくてよかったよ…
      • by Anonymous Coward

        >こういうのって、要求仕様に明記しないといけないのでしょうか?
        >呼吸するように実装してくれないと、発注側としては安心できないのですが。

        当然、必要です。
        というか明記されていない仕様を見た事がありませんなw
        「呼吸するように」俺様常識を振り回されると思うと、怖くて受注できません。

        # 日本的馴れ合い要件定義にどっぷりはまってない?
        # 一度海外に投げて「常識」を学んだ方がいいと思うぞ。

        • by Anonymous Coward on 2010年02月19日 13時07分 (#1720793)
          「そんなの常識だ」

          よく聞く言葉ですが、これが出るとそれは大抵発注者の単なる考慮漏れです。
          親コメント
        • by Anonymous Coward

          >入力項目にfontタグ入れてみたら見事に文字が赤くなったり大きくなったり。。。

          ぶっちゃけそういうことを決めることこそが仕様だしなあ。

          [font]をfontタグに変換する仕様だってありだし、半角<>は全部取り除く仕様もありだし。
          <とかにエスケープするのが便利だけど、僅かに手間が増えるし、下手すると
          「タグをエスケープせずにそのまま入れられるようにしてくれ」という注文が出ることもある。
          #つかスラドもそうじゃんか。「テキスト形式(HTML OK)」とかある。

          そういうことを明記してない仕様なんて「ありえない」わけだが、まあニッポンだと
          そういう基本的なことさえ記載されてない「穴だらけの仕様」がジョーシキになっていて、
          発注者側に自覚が無かったりするのが悩みの種だ。

          >というか明記されていない仕様を見た事がありませんなw
          心底羨ましい。
          よほど恵まれた環境で仕事をなされているのですね。

      • by Anonymous Coward
        被害の方に着目して盛り込んでおくと無難で手っ取り早いです。
        ・正当な権限の無い者に、クッキーを含む通信内容を詐取されないこと
        ・アクセス権限のないデータを閲覧されたり改竄されたりしないこと
        など。
        入力にタグを許可するかどうかは微妙なので、どんな入力を許容すべきかは一通り(ホワイトリストで)指定するのが無難ですね。
      • 「書かなくてもやってくれるはず」なんてのは
        お金払わずに、しかも実装仕様は山盛りに盛り込みたい人の勝手な都合です。

        #最初から書いておくと料金上がるから、
        #後になって「いや、これにはこれもついてくるもんでしょ??」とかいってゴネてタダで仕様追加させる技術
      • by Anonymous Coward

        > こういうのって、要求仕様に明記しないといけないのでしょうか?

        要求仕様を明示した委託なんだったら、最初になんらかの形で明記しとかない
        とダメでしょ。そうすれば、最初に入れたものがあいまいでも、そこから契約
        までに『どのレベルまで対策する』とかそういう協議になるはず。

        どこから委託するのか(どういう仕様で作るのかを明文化する作業を含めてコ
        ンサルするところからなのか、例外なく明文化された仕様があってその通り作
        るのか)を考えたほうがよいと思う。

      • by Anonymous Coward

        こんな発注は受けたくない・・・・
        仕様を少なくして値切らなければいいだよ・・・

        書いてないことはしない。
        請負の基本です。

        # そりゃね、同じようなものを複数作るんだったらともかく
        # 毎回違うことをやっているわけで
        # 安心に金をちゃんと払ってくれないからサボるようになってくるんですよ実際。
        # やってられん毎日

      • スラドらしい開発する側からの視点で一杯批判レス付いてるけどさ、ちょっとそれでいいのかという気が・・・。
        俺も開発する側の人間なので、確かに要件に無いものなんてほいほい作らされてたまるか!という自己防衛の気持ちはあるんだけど、これだけセキュリティが問題になっている昨今、XSSやSQLインジェクションの対策をしないって言うのは、

        「注文住宅を作ってください、こういう間取りでこんな感じでお願いします。」

        「はい、できましたよ。ご注文いただいたとおりの間取りになっていると思います。」

        「あー確かに私の要望どおりですねー・・・あれ?玄関にも窓にも鍵

        • 鍵は通常、ドアに含まれています。
          カタログに載っているようなドアだと通常鍵はついていますが、
          木工職人に木材からドアを作ってくれと依頼した場合、鍵を指定しないと
          鍵なしになるような・・・

          なので、特に何も言わなくても期待しているものが一通りそろってることを
          求めるならパッケージを買いましょう。
          親コメント
        • 理想的には受注側が契約前に仕様の不備を指摘して両者で協議できればいいんですけどねえ。

          親コメント
        • by Anonymous Coward

          少なくとも、これは、プログラマーの責任じゃなくて、上流設計での問題ですね。上流が仕事サボって「常識だろう」とか言い出したら、プログラマーは怒ってよい。もちろん、ツッコミ返してもいいけど、それだったら、その人が仕様書作ればいいのだし。

          • by Anonymous Coward
            素直に考えようよ。 元記事のように、Webサイトの開発委託なのだったら 当然、あらゆる入力文字列に対して異常な結果(まあ、fontが赤になるのが異常なのかは文面だけではわからないが、 たぶんjavascriptのコードがそのままはいったりするんだろう)をもたらしたりしないことは考慮しなくちゃいけないだろうと思うよ。 そういうふうに要求仕様かけ、ってのならそうかもな。
        • by Anonymous Coward

          注文住宅なら戸締りも比較的当たり前(とは言ったって、鍵だってピンキリだから暗黙につけたって絶対顧客の暗黙の要望と合うわけがない)かもしれないが、「倉庫」や「車庫」に置き換えたら全く当たり前ではなくなる。暗黙でつけたら「あ、戸締りもできるようにしてくれたの?サービスしてくれたのね。」で終わりかもしれないし、「なんでこんなチャチな鍵なんだ、ふざけんな馬鹿野郎!」かもしれない。

          そもそも、最初の要件書(あるいは契約締結まででもいいが)の段階で、『(建物で言えば)一般的な防犯対策が施されていること』=『(Webサイトで言えば)一般的なセキュリティを備えていること』と書くくらいは発注側でもできるだろう。それから契約締結までに具体的な内容を詰めればいいだけのこと。

          大体、契約内容に入ってなければ、文句は言えない。
          注文建築だって、建物の契約時には図面のチェックぐらいするだろ?

          契約締結までに提案してくれなかったことに対して文句をいっているのなら、相手を見る眼がなかったことを嘆くべき。

          • by Anonymous Coward

             倉庫にも車庫にも鍵ついていると思う。

            > 相手を見る眼がなかったことを嘆くべき。

             嘆いてる話じゃなかったっけ?

      • by Anonymous Coward

        > こういうのって、要求仕様に明記しないといけないのでしょうか?
        > 呼吸するように実装してくれないと、発注側としては安心できないのですが。

        要求仕様にないってことは、受け入れ試験の基準にもないわけですから、受注側は安心できないでしょうねえ。
        (何をどこまで作れば金を払ってくれるのかわからんということだから)

        ただまあ、大方の請負業者は要求された段階で「実装して欲しければ追加料金だ」なんて言うのを避けて、はじめから仕様追加を見込んだ額を出してきますね。
        で、それを受注側も呼吸するように受けるわけだけど、コストダウンの名の下に見積もりが安い業者に切り替えて痛い目を見たりもする。

        • by Anonymous Coward
          つまり、「入力項目に<font color="red">と入れると文字を赤くする」と、要求仕様に書いてあったんだよ、きっと。
    • by Anonymous Coward

      まあ、責任が追求しやすくなるから明記するのは大事だと思うよ。
      こんなの顧客が責任を追うべき事柄じゃないし。

      # 手抜き工事もばれなきゃOK!の精神だね

アレゲは一日にしてならず -- アレゲ見習い

処理中...