水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 発注者のためのWebシステム/Webアプリケーション セキュリティ要件書

発注者のためのWebシステム/Webアプリケーション セキュリティ要件書

2009年4月2日(木曜日)

発注者のためのWebシステム/Webアプリケーション セキュリティ要件書

公開: 2009年4月5日19時15分頃

アイアクト、Webサイトのセキュリティ要件仕様書を無償公開 (enterprise.watch.impress.co.jp)」だそうで、「発注者のためのWebシステム/Webアプリケーション セキュリティ要件書 (xn--v1t6us6kb66awvj.jp)」というものが公開されていますが……。

うーむ。関わっている方々は、やればできる方たちだと思うのですけれど。日本語としてのクオリティは気にしないとして、個人的によく分からなかったり疑問に思ったりしたところをいくつかメモしておきます。

1.1 以下の箇所では、認証を実施すること

認証済みユーザーのみに表示・実行を許可すべき画面や機能

これは何を言っているのでしょうか。「認証済みユーザーのみに表示・実行を許可すべき画面や機能」に認証を実施するのは、あたりまえです。それができていなかったら明らかに不具合でしょう。何も言っていないに等しいと思うのですが。

パスワード文字列は英数字をすべて含む7文字以上とすること

7文字以上としている意味が分かりません。英数字をすべて含むパスワードは、英字26字と数字10字をすべて含むのですから、必然的に36文字以上になりますよね。:-)

※たぶん、英字と数字の両方を含むということが言いたいのだろうと思いますが、意味がだいぶ違ってきますので。

それはそれとして、やはり7文字の根拠がよく分かりません。経験上、8文字以上としていることとが多いように思いますが……。

画面にパスワード文字列を表示しないこと

入力フォームはtype="password"で指定すること

後者の表現がアレすぎるのは気にしないとして、この条件では input type="hidden" にパスワードを出力するようなケースが許されるのかどうかがハッキリしません。画面には表示されないので hidden や input type="psassword" に対してエコーバックするのはOK、というポリシーのように読めますが、それで良いのでしょうか。

※ちなみに、Cookieにパスワードをセットすることは別項目で禁止されています。

3.1 セッションの破棄について

認証済みのセッションが1時間以上アイドル状態にあるときはセッションタイムアウトとし、サーバー側でセッションを破棄しログアウトすること

ちなみに、WCAG2.0 (www.w3.org)では1時間での強制タイムアウトはNGです。2.2.1(Timing Adjustable) (www.w3.org)の項目では、操作に時間制限をつけないようにする、時間制限をユーザが延長できるようにする、といったことが求められていて、それができない場合、"20 Hour Exception: The time limit is longer than 20 hours." ……すなわち、20時間以上であれば許容するとしています。その理由はこんな感じで、

•20 hours was chosen as an upper limit because it is longer than a full waking day.

以上、Understanding SC 2.2.1 (Timing Adjustable) より

まあ、まる一日あれば良いでしょうということのようです。

ともあれ、理由も説明せずに1時間で強制タイムアウトしろと言われても困ります。まあ、「セッションタイムアウトの時間については、サービスの内容に応じて調整することが必要になります。」とありますので、WCAGを尊重したい場合は調整すれば良いのでしょうけれど。

5.1 クロスサイトスクリプティング(XSS)対策を講じること

すべてのHTML出力で特殊文字(< > " ' &)をエスケープすること

なぜ ' をエスケープしなければならないのかが謎です。5.2では

HTMLタグの属性値を「"」で囲うこと

と規定しているので、原則として ' をエスケープする必要はないと思うのですが。

※「タグの属性値」という表現についてはスルーで。

URLを出力するときは「http://」や「https://」で始まるもののみを許可すること

この書き方ですとアプリケーションが出力する全てのURLに適用しなければならないように読めますが、そんなアプリケーション見たことありません。「ユーザーに任意のURLを入力させるとき……」あるいは「ユーザーが入力したURLを出力するとき……」ということで良いかと思うのですが、そうできない理由が何かあるのでしょうか。

<script>...</script>要素の内容やイベントハンドラ(onmouseover=””など)を動的に生成しないようにすること

イベントハンドラは、クライアント側のスクリプトで動的生成されることが多いです。jQueryなんか使っていると、いつの間にかbodyのonloadが大変な事になっていたりします。そういうことまで禁止されているのかどうか、判然としない書き方ですね。

8.1 利用者のWebブラウザ環境を操作せずデフォルト状態で動作すること

・ セキュリティ設定の変更

「利用者のWebブラウザ環境を操作」して「セキュリティ設定の変更」をすることができるなら、そのブラウザには大変な脆弱性があるということになりそうです。アプリケーション側から「操作する」のと、ユーザに指示して「操作させる」のはだいぶ違うわけで、そこは混同しないようにした方が良いかと思うのですが。

8.2 フレーム、IFRAMEを使用しないこと ※

フレームやIFRAME内に表示されている画面は、ブラウザ上で一目で確認することができません。フレームやIFRAMEの使用を避けることが望ましいでしょう。

理由はそれで良いのでしょうか。任意項目ですから、「一目で確認できれば良い」と解釈されてあっさりスルーされそうですが……。

関連する話題: セキュリティ / フレーム

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13

その他サイト