0LINEはじめに最近セキュア・バイ・デザインを読み始めました。僕なりの解釈と僕自身の現場での体験とを交えながら1章ずつまとめてみようと思います。今回は第1章なぜ、設計がセキュリティにおいて重要なのか??についてまとめてみました。急いでセキュア・バイ・デザインを読み始めたところです。追跡可能性は本当に大丈夫??を常に心配事として捉え続ける!?ログイン済みのユーザは自分がアップロードした画像の差し替えのみ可能とすべきなのに、ある特殊な経路でアクセスすると全ユーザの画像が差し替えることが可能。お客さんから求められたログイン機能自体は、ユーザID、パスワードを入力させてそれが正しければシステムを利用できるようにできている。本来の目的である本人のみ画像の差し替えが可能な状態に本当にできているのか??(セキュリティを心配事として捉える)を意識すべきというようなことが述べられていた箇所が個人的には印象的でした。お客さんの要求通りログイン機能ができた。常に更新権限を持っているユーザしかアップロード画像を更新できなく制御しているか??を心配し続けられる方が、いろんな攻撃されるシミュレーションをしたり、それに対策したりし続けられるので出来上がるシステムも全然変わってくるだろうなぁと思います。以前、権限を詐称して権限のないユーザが本来見れないデータを参照できてしまっている。逆に、セキュリティガチガチにしすぎてアップロード画像を取得するまでに何重ものロックを解除する必要があって使い勝手が悪いようなことはないか??(可用性は大丈夫??)とか、アップロード画像をいつ誰が更新したか追跡可能か??(追跡可能性は大丈夫??)などの意識はまだ欠けているな。セキュリティ対策は専門家が必要(っぽく感じる)で設計は開発者が行うのが普通!!セキュリティ対策と機能開発を分けてタスクを切る場合、セキュリティ対策の方は専門家のタスクで機能開発における設計は開発者のタスクのように感じる。セキュリティ対策は機能開発よりも優先度が落とされて最後の最後まで着手されない傾向にある。開発者が自然に設計をすることがセキュリティ対策に繋がるような状態が良い。いうようなことが述べられていました。専門家頼りにしてたり、後回しにしてたり。画面からから入力させたユーザ名をそのままstringで受け付けるから<script>alert('ホゲほげ')<script>が埋め込まれる。ユーザドメインについて、ドメインエキスパートにヒアリングするとそもそもユーザ名として「<」などの記号は想定していない。ユーザ名を受け付けるときに半角英数字のみ(「<」を受け付けない)という妥当性確認をすべきで、さらに高凝集にするためにユーザ名を値オブジェクトとしてユーザドメインから切り離して・・・と設計を見直すべきこのドメインの理解を進め、設計を見直す過程においてセキュリティのことは一切意識していない。結果的にXSSの対策に繋る。いうようなことが述べられていました。ここを読むまでは、設計の質の向上がセキュリティに繋がるのはピンとこないなぁ・・・という感じでしたが、なるほど、、、ほんとだ。Laughs攻撃とその対策を例にXMLパーサーについての既知の脆弱性に対する推奨設定をするだけでなく、XMLパーサーに読み込ませる値の妥当性確認の設計の両方から多層セキュリティによる防御がセキュリティ向上には大切。いうようなことが述べられていました。一般的なXMLパーサーの脆弱性に対する推奨設定をする知識と持った上で正しく理解してセキュリティの設定を行うことと、XMLパーサーにインプットする前に先程のユーザ名と同じように、stringで値を受け付けるのではなく、ドメインエキスパートとドメインとして受け付けるべき値は何か??を設計に正しく落とし込む。この両方でセキュリティ対策を多層で行うことが非常に重要なのだと僕は解釈しました。多層で防御するという考え方を持たないとな、、、ということを反省させられました。まとめ今回はセキュア・バイ・デザインの1章について僕が印象に残ったこれら4点について僕なりの解釈と僕自身の現場での体験とを交えながらまとめてみました。他の方の解釈なども聞きながらもっと理解を深めていけたらと思います。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。