セキュアプログラミング

WEB セキュアプログラミング

古くからEDPやシステム運用や開発をなされて来た方なら、驚かずに読んでいただけるでしょう。WEBシステム、携帯サイトのシステムというのは、本質的にかなりの危険を含んでいます。不特定多数の人間にＤＢの更新を伴うオペレーションを当たり前のように許可していますが、一昔前のシステムであれば、DBの更新などは、少なくともその組織の中の人間しかありえないと特定できましたが、今はそんなご時世ではありません。

セキィリティの問題は、運用するネットワークやサーバの管理者だけで解決できるものではありません。実は開発者サイドで留意しておくべきことがいくつかあります。ある程度の規模をもつシステム会社さんだと、ちゃんと意識して開発していらっしゃいますが、時々、社内の若い担当者が少しCGIの勉強をして作ったんじゃないだろうかと思えるようなサイトも見受けられます。
もしこれを読んでいる方の中に、サーバ運用担当、システム導入担当の方がいらっしゃいましたら、現在、管理しているサイトのプログラムについて、一度確認をされることをお勧めします。以下の項目は、言語に依存しない事項で、ソースを見なければわからないこともありますが、ブラウザからわかることもあります。

・入力データのチェックをクライアント側スクリプトに頼っていない。
　　　-->ユーザの利便性を求め、JavaScriptを多用するサイトで見受けます。
・全ての入力データからHTMLタグとなりうる文字「<」「>」を取り除いている。
　　　-->100% NGではありませんが、許可する場合は、
　　　　　相当な例外コードが必要です。
　　　　　意識して十分な予算と開発期間をとりましたか？
・HTMLにデータを埋め込む際には必ずHTMLエンコーディング
　　（「<」「>」「&」「"」「'」→「<」「>」「&」「"」「'」の置き換え）
　　　をしている。
　　　-->詳細仕様の議論の際に話題になければ
　　　　　省略されている可能性があります。
・保護が必要な全てのページにユーザ認証機構を組み込んでいる。
　　 -->WEBに不慣れなシステム会社が時々やります。
・事前に推定可能なセッションIDを用いていない。
　　　-->やはりWEBに不慣れなシステム会社が時々やります。
　　　　　また逆にWEBしか経験のないSOHO系のエンジニアが時々やります。
・重要なデータのキーをURLのクエリストリングで受け渡していない。
　　　-->100% NGではありませんが、やる場合は熟慮が必要です。
　　　　　弊社でも、他サイトのシステムとのI/Fのため
　　　　　（先方のミドルウエアの仕様）でやむを得ずやったことがありますが、
　　　　　最低限キーをジャミングする必要があります。
・hiddenフィールドでデータを受け渡していない。
　　　-->100% NGではありませんが、やむを得ずやる場合は、
　　　　　クライアントからの値を信用しないことを前提としたサーバサイドの
　　　　　コーディングが必要です。

このコラムでは割愛しますが、チェックすべき項目は、その他、ＤＢ周りのコーディング、それぞれの言語に依存した項目にも、重要な事柄があります。
IPAのガイドライン等には、一度は目を通し、開発パートナの選択や社内開発に際に、留意いただくべきかと思います。

インクリメンタルかウオータフォールか

どちらが優れているか、などと言う議論ではない。
杓子定規に、「どちらか」しかできないＳＥが、多いのは、困ったもんだ。

ウオターフォールを選択すべき時
・要求がかなり安定している
・設計が比較的単純、セオリーが確立されている。
・長期的な計画や予測が重要
・管理コストも含め、下流での変更が、極めて高くつく

インクリメンタルを選択すべき時
・要求が変化しやすい。要求を出す人さえ業務に精通していない。
・設計が複雑である、定型化されていない
・長期的な計画や予測は、プロジェクトにおいては重要ではない。
・下流での変更を吸収しやすいシカケがある。

プロジェクト推進の手法は、信念や宗教で選ぶべきではない。適切な手法を選ぶことも、ＰＭの腕のうちだ。

コンストラクション（設計・プログラミング）の準備

顧客に言われて、いきなりコーディングをするような仕事は、まあ、ほとんどない。コンストラクションにかかる前に、準備がどうしても必要だ。いわゆる上流工程だ。
イテレート、インクリメンタルの開発手法をとるにしても、この上流の重要度は変わらない。
今の仕事の情況では、20-80 が目安だと思っている。すなわち、プロジェクトに関わる総エネルギーの20%を費やして、80%の要求を洗い出し確定させる。
少なくとも、PMが「要求と設計は、かなり精査した。コーディングやデバックで致命的な問題は出ないだろう」と確信できるまで、コンストラクションにかかるべきではない。

もっともこれは、それまでに１行のソースも１個のクラスも作らないと言っているのではない。特に新しい技術要素を利用する場合は、準備段階での、サンプル・プロトによる評価は必須となる。

WEBブラズザベースの構築では、要求を確認するため、HTMLで紙芝居をつくり、クライアントと画面遷移を握っておくと、ほとんどの問題は潰れる。
他システムとのI/Fがあるなら、何より、実際のデータ（サンプル）を求める。設計だけでは、わからないことがある。

順番としては
課題・問題の定義(ゴール設定) ->要求仕様 ->アーキテクチャ確立->コンストラクションとなる。

関連する参考書としては、PMBOKガイドは一読しておきたい。2005年版は2000年版の１．５倍だが、書棚に持っておくべき。

アマゾン->プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of Knowledge

開発手法・プロジェクト管理手法

いくつかの本を読んではきたが、大半の手法が、排他的な姿勢だ。
つまり、この手法以外じゃ、失敗しますよ、これが絶対普遍の真理ですよ、あなたは神を信じなさい。

ハッキリ例外だったのは、XPだった。「使うべきではない」ケースをしっかりうたっている。

腕のいい大工は、その仕事にふさわしい道具を知っている。
腕のいいプログラマは、その案件にふさわしい言語を選ぶ。

官公庁相手の仕事であれば、仕事をしたことを証明するために、多くのドキュメントが必要だ。しかし、３ヶ月のキャンペーンで、使い捨てにするWEBサイトであれば、ドキュメント云々より、その間、動向を見ながら、走りながら治していくことが大事だ。

チームのあり方、プロジェクトの進め方を、一律のモノサシで測ることはできない。

プログラミングの例え4 システムを構築する

システムを構築する。建設をイメージできると思うが、このメタファが一番自然に思える。

小さい工事、それこそ、家の壁に、棚をつけろと女房に言われたなら、ちょっとした採寸とメモで、材料を買って、製造に取り掛かれる。
けれど、セルフビルドでも、家を建てましょうとなると、綿密な計画、プランが必要になる。
ましてや、ビルでも建てるとなれば、家の比ではない。

システム構築は、その規模や目的によって、採用するべき手法が異なる。

情報を見せるだけのWEBサイトと、決済、取引を伴うサイトを同列に扱うことはできない。
２０ページの企業情報を乗せたいサイト構築と１０万ページのコンテンツをもつサイト構築を進めるのに、同じ手法は使えない。

プログラミングの例え 3 アクリエーションする

システムをアクリエーションする。

こういうメタファも使われだしているようだ。

ほんと、メタファ好きだよな

真珠養殖ということなんだが・・。

母の貝が、じわじわと真珠を大きくしていく姿は、イテレート、インクリメント開発に、イメージが近い・・そうだ。

チームの構成員が真珠養殖を良く知らないと、このメタファの使用は無理がある。

プログラミングの例え2 システムを育てる

クライアントさんのシステム担当が、愛情をもっている場合、「育てる」といいたい気持ちもわかる。
いきなり最終目的に行こうとあせるクライアントに「システムは育てるもんですよ」と言ったことも確かにある。

新しい処理系をモノにしようとする場合、hellow worldから、コードを増やしていく。

インクリメンタル、イテレートのプロジェクトにも、当てはまりそうだ。

しかし、まあ、「育てる」と最初に言い出した本人（例のごとくメタファ好きの西洋人だが）は、農場をイメージしていたらしい。秋になるとコードを収穫する・・。う～ん。そうなるとちょっとね。

プログラミングの例え 1 コード（ソース）を書く

コード（ソース）を書く
　ひとつ捨てるつもりで。どうせ書き直すことになる。（Fred Brooks)
ひとつ捨てるつもりだったら２つ捨てることになる(Craig Zerouni)

　書くという比喩、メタファは、プログラムに合っているのか？

　自分ひとりでできる分量をプログラミングして、稼動させるなら違和感はない。
　ひとりの作品として、書く、著述するで、いいかもしれない。

書くとは、オリジナリティが伴う。ソフトウエアは完全にオリジナルだろうか？フレームワークに乗って、クラスライブラリを組み合わせて、他のサイトのサービスを利用して、目的を達するシステムを作ることを、書くというには、無理があるんじゃないかなあ。

　ないものは全て作る、すべて書くという、古の伝説のプログラマ達であれば、「書く」もいいだろう。

　だいち、もう、１人でやる仕事なんて、ほとんどない。