Webセキュリティの小部屋

Twitter のフォローはこちらから Facebook ページはこちら Google+ページはこちら RSSフィードのご登録はこちらから
公開日:2015年12月25日

「発注者のためのWebシステム/Webアプリケーションセキュリティ要件書」が OWASP に移管されていた

以前、トライコーダ社によって公開されていた「発注者のためのWebシステム/Webアプリケーションセキュリティ要件書」が OWASP に移管されていました。もともとの文書を知らない方も多いかもしれませんね。

最新資料のダウンロードはトライコーダ社のページから行うことができます(PDF)。

もともと、この資料はネット上で公開されている数少ないセキュリティ要件書だったのですが、内容が若干古くなっていたこともあったので、OWASP に移管され公式に更新されていくことになったのはよいことだと思います。

最新資料にざっと目を通しましたが、Webシステム/Webアプリケーションのセキュリティ要件は網羅しているようですね。

 

ただ、いくつか気になる部分があるので、取り上げてみたいと思います。

 

パスワード文字列は大小英字と数字の両方を含み、最低 7 文字以上であること

上記は、最低と言っているので、まあよいといえばよいのですが、最近の傾向を踏まえると、記号も含み、最低8文字以上である方が望ましいのではないでしょうか。

なお、パスワードの定期変更に触れてないのはよいと思いました。逆に、パスワードの定期変更は望ましくないと記載があってもよかったのではないかと思う位です。

 

 パスワード文字列は「パスワード文字列+salt(ユーザー毎に異なるランダムな文字列)」をハッシュ化したものと salt のみを保存すること

salt に言及しているのはよいですね。私も salt はユーザー毎に異なるランダムな文字列を使用するのですが、ユーザー毎はともかくランダムな文字列というのは必須かどうかは議論の余地があるのかなと思います。例えば、ユーザーIDをハッシュ化したものを salt にするという方法は認められないのかという話ですね。

あと、ストレッチングについても言及が欲しかったです。

 

3.3項 CSRF 対策にある記載なのですが、CSRF の基本的な対策が、重要な処理の前に再認証を行うことが基本になるような記載になってしまっているのも気になります。

もちろん、これは間違いではないのですが、CSRF の基本的な対策はトークンによる秘密情報によりリクエストが正当なものか判断することだと思います。再認証はユーザーの負担が大きいので、本当に重要な情報のみに限定すべきではないでしょうか。

 

秘密情報としては固定値ではなく、ワンタイムトークンを使うことが望ましいでしょう。

これは、CSRF 対策としてトークンを使用する場合の話ですが、ワンタイムトークンは安全ではあるのですが、副作用があることに言及されていません。

ワンタイムトークンを採用すると、例えば小画面を開いた時にトークンが更新されたり、Ajax の通信によりトークンが更新されたりして、メイン画面からリクエストを送った時に不正なリクエストと判断されてしまうという問題があります。

こういう問題を回避するには、セッションで固有なトークンを使用する方が望ましいのではないでしょうか。

 

6.3項ですが、SSL2.0 を無効にする旨の記載があります。

SSL2.0 には脆弱性があるので、SSL3.0/TLS1.0 などを使用する必要があります。

これは時期的な問題だと思うのですが、SSL3.0 には POODLE の脆弱性があるので、SSL3.0 も無効にすべきです。

 

追記:
クリックジャッキング対策の記載がなかったですね。 

 

ざっと目を通した感想はこんなところです。

細々と指摘をしてきましたが、この資料は発注者にとって非常に有益なものです。

現在セキュリティ要件書がないのであれば、この資料は、規約に従えば改変して利用することもできるので、社内のセキュリティ担当者と相談して採用することをお勧めします。


スポンサーリンク




カテゴリー:ブログ

Twitter でも、いろんな情報を発信しています。



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA