アカウント名:
パスワード:
「開発チームのメンバー全員がセキュアプログラミング技術のトレーニングを適切に受けていることを確証する責任を負」っているからと言って、実際そう作られるかというのは別問題ですよね?
マジレスすると、以前委託したECサイトのテスト中、入力項目にfontタグ入れてみたら見事に文字が赤くなったり大きくなったり。。。
なんでサニタイズせんのじゃ~~!と委託先にクレームあげたら「最初に言え!」とか開き直られました。「んなもん、常識だろうが!」とこっちも吠え返して、社内にあったWEBプログラミングのテキストからXSSだのSQLインジェクションへの対策のページを送りつけてやりました。
こういうのって、要求仕様に明記しないといけないのでしょうか?呼吸するように実装してくれないと、発注側としては安心できないのですが。
…… め、めはらみか?
マジレスすると、この話の受注側はタコだし、「んなもん、常識だろうが!」も、もっともなんだけど、要求仕様への明記は必要じゃないかな。
日本人同士であればまだ阿吽の呼吸でやってくれたりしますが、海外、ことに中国系の場合、「書いてないことは全くもってやらない」ですよ。書いてあることは「書いてあるとおりに」やってくるけど。※そもそも設計に矛盾があったとしても「書いてあるとおりに」実装してきます
日本人であれば、実際に組んでいるときに「あれ? これ何かおかしくない?」と気付いたら、それとなく設計に尋ねてみたりするなどして事前に潰せたりするのですが、日本人以外の場合はそのようなことはなく、「設計が気付いてないならしったこっちゃない。うちらは指示通りに組むだけだし」と。分業の徹底といってしまえばそれまでかもしれませんけど。
まあ、「書いてあること無視する」どこぞの IT よりはマシですが……
この前、Webアプリなのに複数人が同時に編集することを考慮してない画面があって直してたんですが、 隣の席の中国人に「こういう問題起こさないようにな。」って話したら、 「こういうところはチェックを入れた方がいいんですか?」って返されました。
いや、Webアプリなんだからそんなこと考えるまでもないだろ!と久しぶりに声を荒げてしまった。 むしろ何でチェックを入れなくていいなんて思えるんだ? 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか・・・orz
# サニタイズ?もちろん毎回言わないとやりませんが何か? 新人じゃなくてWebアプリ経験4年てー。 # 即戦力だの派遣だの寝言言わずちゃんと教育しようぜ(涙
> 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか
あなたがどういう立場なのかわかりませんが、それぞれを対処するのにも、システムごとにそれなりにやりかたがあります。ぶっちゃけ、排他制御について、一人のユーザーが使っていたら、他のユーザーの利用を止めてしまうシステムも山のようにあります。
なんで、そういうことを対処してほしいと思うなら、明確に仕様の段階で盛り込むべきです。設計書を作成した段階で漏れている方が悪いと思います(漏れていることを指摘出来なかった方も悪いけど)。そんで、口頭でしか言わなかったということは、テスト項目から漏れているわけで、当該のシステムの利用はちょっと怖い気がします。
失礼。誤解を招いたようなので追記します。
そのシステムを設計したのも作成したのは、私とも隣の人とも縁もゆかりもない別の会社の方々です。 そんな糞システムなので、えぇ全く持って利用するのも保守するのも怖いです。
一概に排他制御を入れられない、というのはもちろん判りますが、だからといってデータが壊れるような状況を目にしておいて対策を入れたほうがよい?何て疑問系で出てくるのが信じられませんでした。 文化の違いとかそんなレベルではなく、プログラマとして間違っていると言いたくなります。
後からコミットされた方のデータを有効にする、というやり方もあるわけで。何をもってデータが壊れるとしているのかもわかりません。
そこが本題のつもりは無かったのですが、何か気にされているようなのでレスします。
データが壊れるは文字通りの意味ですね。削除済みのデータにリレーション貼るとか、データがあるのにリレーション消すとか。 後優先とかで何かしら完全性が保たれていれば、ああそういう設計なのかとも思えるんですが・・・。 そんなの常識だ!は駄目だと批判されていますが、せめてそれぐらいは考えてほしいです(涙
参照制約ぐらい言わなくてもつけてくれると思ってた。
なんてね。元コメが全てで「結局契約と金次第」です。「安ければなんでも良い」なんて方々もいるのですよ。サニタイジングにはその分手間とテストが増えるわけで、その分のコストを見積もっているかどうかです。
ここで一句
「そこからか そこからいわんと だめなのか」
なぜか社内オフショア状況に陥ったSEの世事の句
>こういうのって、要求仕様に明記しないといけないのでしょうか?>呼吸するように実装してくれないと、発注側としては安心できないのですが。
当然、必要です。というか明記されていない仕様を見た事がありませんなw「呼吸するように」俺様常識を振り回されると思うと、怖くて受注できません。
# 日本的馴れ合い要件定義にどっぷりはまってない?# 一度海外に投げて「常識」を学んだ方がいいと思うぞ。
>入力項目にfontタグ入れてみたら見事に文字が赤くなったり大きくなったり。。。
ぶっちゃけそういうことを決めることこそが仕様だしなあ。
[font]をfontタグに変換する仕様だってありだし、半角<>は全部取り除く仕様もありだし。<とかにエスケープするのが便利だけど、僅かに手間が増えるし、下手すると「タグをエスケープせずにそのまま入れられるようにしてくれ」という注文が出ることもある。#つかスラドもそうじゃんか。「テキスト形式(HTML OK)」とかある。
そういうことを明記してない仕様なんて「ありえない」わけだが、まあニッポンだとそういう基本的なことさえ記載されてない「穴だらけの仕様」がジョーシキになっていて、発注者側に自覚が無かったりするのが悩みの種だ。
>というか明記されていない仕様を見た事がありませんなw心底羨ましい。よほど恵まれた環境で仕事をなされているのですね。
> こういうのって、要求仕様に明記しないといけないのでしょうか?
要求仕様を明示した委託なんだったら、最初になんらかの形で明記しとかないとダメでしょ。そうすれば、最初に入れたものがあいまいでも、そこから契約までに『どのレベルまで対策する』とかそういう協議になるはず。
どこから委託するのか(どういう仕様で作るのかを明文化する作業を含めてコンサルするところからなのか、例外なく明文化された仕様があってその通り作るのか)を考えたほうがよいと思う。
こんな発注は受けたくない・・・・仕様を少なくして値切らなければいいだよ・・・
書いてないことはしない。請負の基本です。
# そりゃね、同じようなものを複数作るんだったらともかく# 毎回違うことをやっているわけで# 安心に金をちゃんと払ってくれないからサボるようになってくるんですよ実際。# やってられん毎日
スラドらしい開発する側からの視点で一杯批判レス付いてるけどさ、ちょっとそれでいいのかという気が・・・。 俺も開発する側の人間なので、確かに要件に無いものなんてほいほい作らされてたまるか!という自己防衛の気持ちはあるんだけど、これだけセキュリティが問題になっている昨今、XSSやSQLインジェクションの対策をしないって言うのは、
「注文住宅を作ってください、こういう間取りでこんな感じでお願いします。」 ↓ 「はい、できましたよ。ご注文いただいたとおりの間取りになっていると思います。」 ↓ 「あー確かに私の要望どおりですねー・・・あれ?玄関にも窓にも鍵
理想的には受注側が契約前に仕様の不備を指摘して両者で協議できればいいんですけどねえ。
少なくとも、これは、プログラマーの責任じゃなくて、上流設計での問題ですね。上流が仕事サボって「常識だろう」とか言い出したら、プログラマーは怒ってよい。もちろん、ツッコミ返してもいいけど、それだったら、その人が仕様書作ればいいのだし。
注文住宅なら戸締りも比較的当たり前(とは言ったって、鍵だってピンキリだから暗黙につけたって絶対顧客の暗黙の要望と合うわけがない)かもしれないが、「倉庫」や「車庫」に置き換えたら全く当たり前ではなくなる。暗黙でつけたら「あ、戸締りもできるようにしてくれたの?サービスしてくれたのね。」で終わりかもしれないし、「なんでこんなチャチな鍵なんだ、ふざけんな馬鹿野郎!」かもしれない。
そもそも、最初の要件書(あるいは契約締結まででもいいが)の段階で、『(建物で言えば)一般的な防犯対策が施されていること』=『(Webサイトで言えば)一般的なセキュリティを備えていること』と書くくらいは発注側でもできるだろう。それから契約締結までに具体的な内容を詰めればいいだけのこと。
大体、契約内容に入ってなければ、文句は言えない。注文建築だって、建物の契約時には図面のチェックぐらいするだろ?
契約締結までに提案してくれなかったことに対して文句をいっているのなら、相手を見る眼がなかったことを嘆くべき。
倉庫にも車庫にも鍵ついていると思う。
> 相手を見る眼がなかったことを嘆くべき。
嘆いてる話じゃなかったっけ?
> こういうのって、要求仕様に明記しないといけないのでしょうか?> 呼吸するように実装してくれないと、発注側としては安心できないのですが。
要求仕様にないってことは、受け入れ試験の基準にもないわけですから、受注側は安心できないでしょうねえ。(何をどこまで作れば金を払ってくれるのかわからんということだから)
ただまあ、大方の請負業者は要求された段階で「実装して欲しければ追加料金だ」なんて言うのを避けて、はじめから仕様追加を見込んだ額を出してきますね。で、それを受注側も呼吸するように受けるわけだけど、コストダウンの名の下に見積もりが安い業者に切り替えて痛い目を見たりもする。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
結局契約と金次第 (スコア:0)
「開発チームのメンバー全員がセキュアプログラミング技術のトレーニングを適切に受けていることを確証する責任を負」っているからと言って、実際そう作られるかというのは別問題ですよね?
Re:結局契約と金次第 (スコア:3, 興味深い)
マジレスすると、以前委託したECサイトのテスト中、入力項目にfontタグ入れてみたら
見事に文字が赤くなったり大きくなったり。。。
なんでサニタイズせんのじゃ~~!と委託先にクレームあげたら「最初に言え!」とか
開き直られました。「んなもん、常識だろうが!」とこっちも吠え返して、社内にあった
WEBプログラミングのテキストからXSSだのSQLインジェクションへの対策のページを
送りつけてやりました。
こういうのって、要求仕様に明記しないといけないのでしょうか?
呼吸するように実装してくれないと、発注側としては安心できないのですが。
Re:結局契約と金次第 (スコア:1)
…… め、めはらみか?
マジレスすると、この話の受注側はタコだし、
「んなもん、常識だろうが!」も、もっともなんだけど、
要求仕様への明記は必要じゃないかな。
Re:結局契約と金次第 (スコア:1)
日本人同士であればまだ阿吽の呼吸でやってくれたりしますが、海外、ことに中国系の場合、
「書いてないことは全くもってやらない」
ですよ。書いてあることは「書いてあるとおりに」やってくるけど。
※そもそも設計に矛盾があったとしても「書いてあるとおりに」実装してきます
日本人であれば、実際に組んでいるときに「あれ? これ何かおかしくない?」と気付いたら、それとなく設計に尋ねてみたりするなどして事前に潰せたりするのですが、日本人以外の場合はそのようなことはなく、「設計が気付いてないならしったこっちゃない。うちらは指示通りに組むだけだし」と。分業の徹底といってしまえばそれまでかもしれませんけど。
まあ、「書いてあること無視する」どこぞの IT よりはマシですが……
-- To be sincere...
見た目動けばいい人たち (スコア:0)
この前、Webアプリなのに複数人が同時に編集することを考慮してない画面があって直してたんですが、
隣の席の中国人に「こういう問題起こさないようにな。」って話したら、
「こういうところはチェックを入れた方がいいんですか?」って返されました。
いや、Webアプリなんだからそんなこと考えるまでもないだろ!と久しぶりに声を荒げてしまった。
むしろ何でチェックを入れなくていいなんて思えるんだ?
排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか・・・orz
# サニタイズ?もちろん毎回言わないとやりませんが何か? 新人じゃなくてWebアプリ経験4年てー。
# 即戦力だの派遣だの寝言言わずちゃんと教育しようぜ(涙
Re: (スコア:0)
> 排他制御してください、データが壊れないようにしてください、とか一々伝えないと駄目なのか
あなたがどういう立場なのかわかりませんが、それぞれを対処するのにも、システムごとにそれなりにやりかたがあります。ぶっちゃけ、排他制御について、一人のユーザーが使っていたら、他のユーザーの利用を止めてしまうシステムも山のようにあります。
なんで、そういうことを対処してほしいと思うなら、明確に仕様の段階で盛り込むべきです。設計書を作成した段階で漏れている方が悪いと思います(漏れていることを指摘出来なかった方も悪いけど)。そんで、口頭でしか言わなかったということは、テスト項目から漏れているわけで、当該のシステムの利用はちょっと怖い気がします。
Re: (スコア:0)
失礼。誤解を招いたようなので追記します。
そのシステムを設計したのも作成したのは、私とも隣の人とも縁もゆかりもない別の会社の方々です。
そんな糞システムなので、えぇ全く持って利用するのも保守するのも怖いです。
一概に排他制御を入れられない、というのはもちろん判りますが、だからといってデータが壊れるような状況を目にしておいて対策を入れたほうがよい?何て疑問系で出てくるのが信じられませんでした。
文化の違いとかそんなレベルではなく、プログラマとして間違っていると言いたくなります。
Re: (スコア:0)
後からコミットされた方のデータを有効にする、というやり方もあるわけで。
何をもってデータが壊れるとしているのかもわかりません。
Re: (スコア:0)
そこが本題のつもりは無かったのですが、何か気にされているようなのでレスします。
データが壊れるは文字通りの意味ですね。削除済みのデータにリレーション貼るとか、データがあるのにリレーション消すとか。
後優先とかで何かしら完全性が保たれていれば、ああそういう設計なのかとも思えるんですが・・・。
そんなの常識だ!は駄目だと批判されていますが、せめてそれぐらいは考えてほしいです(涙
Re: (スコア:0)
参照制約ぐらい言わなくてもつけてくれると思ってた。
なんてね。
元コメが全てで「結局契約と金次第」です。
「安ければなんでも良い」なんて方々もいるのですよ。
サニタイジングにはその分手間とテストが増えるわけで、その分のコストを見積もっているかどうかです。
Re: (スコア:0)
ここで一句
「そこからか そこからいわんと だめなのか」
なぜか社内オフショア状況に陥ったSEの世事の句
Re: (スコア:0)
辞世の句でなくてよかったよ…
Re: (スコア:0)
>こういうのって、要求仕様に明記しないといけないのでしょうか?
>呼吸するように実装してくれないと、発注側としては安心できないのですが。
当然、必要です。
というか明記されていない仕様を見た事がありませんなw
「呼吸するように」俺様常識を振り回されると思うと、怖くて受注できません。
# 日本的馴れ合い要件定義にどっぷりはまってない?
# 一度海外に投げて「常識」を学んだ方がいいと思うぞ。
Re:結局契約と金次第 (スコア:1, 興味深い)
よく聞く言葉ですが、これが出るとそれは大抵発注者の単なる考慮漏れです。
Re: (スコア:0)
>入力項目にfontタグ入れてみたら見事に文字が赤くなったり大きくなったり。。。
ぶっちゃけそういうことを決めることこそが仕様だしなあ。
[font]をfontタグに変換する仕様だってありだし、半角<>は全部取り除く仕様もありだし。
<とかにエスケープするのが便利だけど、僅かに手間が増えるし、下手すると
「タグをエスケープせずにそのまま入れられるようにしてくれ」という注文が出ることもある。
#つかスラドもそうじゃんか。「テキスト形式(HTML OK)」とかある。
そういうことを明記してない仕様なんて「ありえない」わけだが、まあニッポンだと
そういう基本的なことさえ記載されてない「穴だらけの仕様」がジョーシキになっていて、
発注者側に自覚が無かったりするのが悩みの種だ。
>というか明記されていない仕様を見た事がありませんなw
心底羨ましい。
よほど恵まれた環境で仕事をなされているのですね。
Re: (スコア:0)
・正当な権限の無い者に、クッキーを含む通信内容を詐取されないこと
・アクセス権限のないデータを閲覧されたり改竄されたりしないこと
など。
入力にタグを許可するかどうかは微妙なので、どんな入力を許容すべきかは一通り(ホワイトリストで)指定するのが無難ですね。
「書かなくてもやってくれるはず」って? (スコア:0)
お金払わずに、しかも実装仕様は山盛りに盛り込みたい人の勝手な都合です。
#最初から書いておくと料金上がるから、
#後になって「いや、これにはこれもついてくるもんでしょ??」とかいってゴネてタダで仕様追加させる技術
Re: (スコア:0)
> こういうのって、要求仕様に明記しないといけないのでしょうか?
要求仕様を明示した委託なんだったら、最初になんらかの形で明記しとかない
とダメでしょ。そうすれば、最初に入れたものがあいまいでも、そこから契約
までに『どのレベルまで対策する』とかそういう協議になるはず。
どこから委託するのか(どういう仕様で作るのかを明文化する作業を含めてコ
ンサルするところからなのか、例外なく明文化された仕様があってその通り作
るのか)を考えたほうがよいと思う。
Re: (スコア:0)
こんな発注は受けたくない・・・・
仕様を少なくして値切らなければいいだよ・・・
書いてないことはしない。
請負の基本です。
# そりゃね、同じようなものを複数作るんだったらともかく
# 毎回違うことをやっているわけで
# 安心に金をちゃんと払ってくれないからサボるようになってくるんですよ実際。
# やってられん毎日
玄関に鍵を付けるなんて要件なかった (スコア:0)
スラドらしい開発する側からの視点で一杯批判レス付いてるけどさ、ちょっとそれでいいのかという気が・・・。
俺も開発する側の人間なので、確かに要件に無いものなんてほいほい作らされてたまるか!という自己防衛の気持ちはあるんだけど、これだけセキュリティが問題になっている昨今、XSSやSQLインジェクションの対策をしないって言うのは、
「注文住宅を作ってください、こういう間取りでこんな感じでお願いします。」
↓
「はい、できましたよ。ご注文いただいたとおりの間取りになっていると思います。」
↓
「あー確かに私の要望どおりですねー・・・あれ?玄関にも窓にも鍵
Re:玄関に鍵を付けるなんて要件なかった (スコア:2)
カタログに載っているようなドアだと通常鍵はついていますが、
木工職人に木材からドアを作ってくれと依頼した場合、鍵を指定しないと
鍵なしになるような・・・
なので、特に何も言わなくても期待しているものが一通りそろってることを
求めるならパッケージを買いましょう。
Re: (スコア:0)
Re:玄関に鍵を付けるなんて要件なかった (スコア:2)
Re:玄関に鍵を付けるなんて要件なかった (スコア:1)
理想的には受注側が契約前に仕様の不備を指摘して両者で協議できればいいんですけどねえ。
Re: (スコア:0)
少なくとも、これは、プログラマーの責任じゃなくて、上流設計での問題ですね。上流が仕事サボって「常識だろう」とか言い出したら、プログラマーは怒ってよい。もちろん、ツッコミ返してもいいけど、それだったら、その人が仕様書作ればいいのだし。
Re: (スコア:0)
Re: (スコア:0)
注文住宅なら戸締りも比較的当たり前(とは言ったって、鍵だってピンキリだから暗黙につけたって絶対顧客の暗黙の要望と合うわけがない)かもしれないが、「倉庫」や「車庫」に置き換えたら全く当たり前ではなくなる。暗黙でつけたら「あ、戸締りもできるようにしてくれたの?サービスしてくれたのね。」で終わりかもしれないし、「なんでこんなチャチな鍵なんだ、ふざけんな馬鹿野郎!」かもしれない。
そもそも、最初の要件書(あるいは契約締結まででもいいが)の段階で、『(建物で言えば)一般的な防犯対策が施されていること』=『(Webサイトで言えば)一般的なセキュリティを備えていること』と書くくらいは発注側でもできるだろう。それから契約締結までに具体的な内容を詰めればいいだけのこと。
大体、契約内容に入ってなければ、文句は言えない。
注文建築だって、建物の契約時には図面のチェックぐらいするだろ?
契約締結までに提案してくれなかったことに対して文句をいっているのなら、相手を見る眼がなかったことを嘆くべき。
Re: (スコア:0)
倉庫にも車庫にも鍵ついていると思う。
> 相手を見る眼がなかったことを嘆くべき。
嘆いてる話じゃなかったっけ?
Re: (スコア:0)
> こういうのって、要求仕様に明記しないといけないのでしょうか?
> 呼吸するように実装してくれないと、発注側としては安心できないのですが。
要求仕様にないってことは、受け入れ試験の基準にもないわけですから、受注側は安心できないでしょうねえ。
(何をどこまで作れば金を払ってくれるのかわからんということだから)
ただまあ、大方の請負業者は要求された段階で「実装して欲しければ追加料金だ」なんて言うのを避けて、はじめから仕様追加を見込んだ額を出してきますね。
で、それを受注側も呼吸するように受けるわけだけど、コストダウンの名の下に見積もりが安い業者に切り替えて痛い目を見たりもする。
Re: (スコア:0)