ウェブ健康診断 仕様について
(平成 20 年度版・一般公開用)
(財)地方自治情報センター
自治体セキュリティ支援室
目次 1 はじめに ... 3 1.1 本資料公開の経緯... 3 1.2 ウェブ健康診断とは... 4 2 ウェブ健康診断 診断内容... 5 2.1 診断対象脆弱性（診断項目）及びその選定理由... 5 2.2 危険度基準... 5 2.3 総合判定基準... 6 2.4 診断時に利用する診断項目毎の検出パターン(目安)、脆弱性有無の判定基準について... 7 2.5 診断対象画面（機能）とその定義について... 12 3 ウェブ健康診断検討委員会 ... 14 3.1 設置目的... 14 3.2 検討委員会の検討事項... 14 3.3 検討委員会委員一覧 （五十音順・敬称略）... 14 （別紙） ウェブ健康診断報告書フォーマット 本診断での報告書フォーマット（一部）です。A3 一枚表裏に診断結果が全て収まるようにしています。
1 はじめに
1.1 本資料公開の経緯
本資料は、地方自治情報センター（以下「当センター」という。）が平成 20 年度に実施したウェブ健康診 断1事業（地方公共団体のWeb アプリケーションのセキュリティ状況を診断する事業。以下「本事業」とい う。）における診断仕様の一部をまとめたものです。同診断仕様は、有識者等によるウェブ健康診断検討委 員会（詳細は P.14 を参照）において検討し、定めたものです。 この度、本事業で実施した診断内容（診断仕様）を公開し、地方公共団体の Web アプリケーションの開発・ 運用・検査及び利用に関わる全ての方々の参考資料として提供することにいたしました。 本仕様は、より多くの地方公共団体に診断事業を受けていただき、Web アプリケーションの脆弱性を身近 な問題として知っていただくことに主眼を置いているため、診断内容が一般に診断サービスとして提供され ているものよりも簡素になっています。そのため本事業の診断を受けた結果が良好だっただけでは“安全で ある”との判断はできません。診断を受けた地方公共団体には、本事業は現状認識の第一歩、きっかけの一 つとしてご活用いただくことを想定しています。 また、本事業で脆弱性が発見されるようであれば、別途より詳細な診断を実施いただくことをお勧めいた します。 [ 地方公共団体担当者の方へ ] 本資料は、一般公開用のものであり、下記内容について入手したい場合は、下記 LGWAN サイトから取得し てください（Internet では非公開です）。 ・ 本仕様の作成経緯及び詳細な検討内容（診断しないと決めた診断項目及びその理由等） ・ 平成 20 年度同事業における１団体あたりの診断単価 ・ Web アプリケーションの脆弱性の理解を深めるための参考資料 （診断仕様中に取り上げている 12 種類の脆弱性に関する解説・対策・脆弱性の再現方法） 診断仕様(詳細) 資料公開 （LGWAN 接続環境が必要です） http://lascww01.lg-lib.asp.lgwan.jp/cb/bbs/cbServlet?FRID=Edisp&ci=203&ei=840&o=S&r=Y&p=1&t=O なお、診断実施団体全体の結果統計データ等につきましては、下記 LGWAN サイトにおいて公開予定です。 （Internet では非公開です） 地方自治情報センター 自治体セキュリティ支援室ポータルサイト（LGWAN接続環境が必要です） http://lascww01.lg-lib.asp.lgwan.jp 1 本事業は当センターが実施している、セキュリティ支援事業です。『ウェブ健康診断』という名称は、多くの 地方公共団体に気軽に診断して現状を把握して頂きたいという考えから付けている Web アプリケーション脆弱 性診断事業の事業名称です（平成 20 年度から同名称を利用）。1.2 ウェブ健康診断とは
「ウェブ健康診断」とは、人間に例えるなら、その名のとおり 「健康診断」にあたるような位置づけの診断 です。人間ドックに比べたら精密ではありませんが、平成19 年度に実施した Web アプリケーション脆弱性診断 結果等も考慮しながら重要な診断項目を検討しました。 本診断は「基本的な対策が出来ているかどうかを診断するもの」とご理解ください。また、診断対象の Web アプリケーションの全てのページを診断するものではなく、診断対象の規模にもよりますが、基本は抜き取り調 査(診断)です。 ※ ①～③までを当センターの支援事業として実施。 診断方式 ： 遠隔地からインターネット経由による手動若しくは自動診断ツールを利用 診断実施数：約３００団体 診断対象 ： 地方公共団体が保有若しくは利用している、現在インターネットで稼動中の Web サーバ１サイト分（1 ドメインネーム） ・ページ数規模は、動的ページ5～10、最大で 20 画面（機能）程度まで ・診断対象サイトのサブドメイン、別ドメインは原則として対象外 ・診断対象例 - 電子申請・電子入札 - 図書館蔵書検索、貸し出し予約 - 公共施設等の設備予約 - 自治体ホームページ全体や、議事録の検索 - 資料請求・問い合わせ、イベント・メールマガジン等の申込みフォーム - 地域 SNS、掲示板 - GIS 等。2 ウェブ健康診断 診断内容
2.1 診断対象脆弱性（診断項目）及びその選定理由
診断対象脆弱性（診断項目）は以下のとおりです。なお、以降のページ及び別紙で、診断項目を示す場 合は、記号（A）～（L）を付与しています。 想定被害 記 号 診断項目（脆弱性名） 危険度 能動的攻撃 /受動的攻撃 情報 漏洩 改ざん 妨害 (A) SQL インジェクション 高 能動的 ○ ○ ○ (B) クロスサイト・スクリプティング(XSS) 中 受動的 ○ △ (C) クロスサイト・リクエスト・フォージェリ(CSRF) 中 受動的 △ ○ ○ (D) OS コマンドインジェクション 高 能動的 ○ ○ ○ (E) ディレクトリ・リスティング 低～高 能動的 ○ (F) メールヘッダインジェクション 中 能動的 ○ (G) パストラバーサル 高 能動的 ○ △ (H) 意図しないリダイレクト 中 受動的 ○ (I) HTTP ヘッダインジェクション 中 受動的 ○ △ (J) 認証 低～中 能動的 ○ ○ (K) セッション管理の不備 低～高 能動的／受動的 ○ ○ (L) アクセス制御の不備、欠落 高 能動的 ○ ○ 上記診断対象脆弱性の選定における根拠（概要）は以下のとおりです。 ・危険性の高い脆弱性 (直接的な被害を被る可能性が高いもの) ・平成19 年度 Web アプリケーション脆弱性診断事業（LASDEC 実施）で検出数の多かったもの ・IPA「安全なウェブサイトの作り方2」に取り上げられているもの(届出の多いもの) ・最近問題となるケースの多いもの(SQL インジェクション、XSS、CSRF)2.2 危険度基準
各脆弱性に付与している危険度のレベルは、以下の基準に則って提示しました。 危険度「高」 被害者ユーザの関与がなくても攻撃者が直接アプリケーションに対して攻撃可能である能動的な脆弱性。 攻撃を受けると、大量の情報漏洩や改ざんの被害を生じる可能性がある。 危険度「中」 攻撃成功には被害者ユーザの関与（攻撃者の罠のリンクをクリックする等）が必要である受動的な脆弱性。 もしくは、能動的な脆弱性であっても大量の情報漏洩や改竄にはつながりにくいもの。 危険度「低」 攻撃成功の確率が低い、もしくは攻撃が成功しても被害が軽微であると考えられる脆弱性。ただし被害に 遭う可能性はゼロではない。 2 http://www.ipa.go.jp/security/vuln/websecurity.html2.3 総合判定基準
脆弱性が発見された場合、地方公共団体へ提示する報告書では「総合判定所見」として「要治療・精密検 査」「差し支えない」「異常は発見されなかった」のいづれかを記載します。同所見は以下の基準に則って記 載しました。 「要治療・精密検査」 説明 危険度が「高」または「中」の、明らかに危険な脆弱性が検出された。Web アプリケーションの改修 等の措置を講じる必要がある。また、指摘箇所以外にも危険な脆弱性が発見される可能性が高い。 基準 脆弱性(A)～(L)の 12 項目のうち、1 つでも脆弱性が発見された場合。ただし、「差し支えない」の判定 基準にある脆弱性以外のもの（危険性が高い脆弱性） 「差し支えない」 説明 今回の診断では危険度が「低」の脆弱性のみが検出された。現状すぐに実被害に及ぶ可能性は低く、運 用上は差し支えないと判断されるが、本件は注意が必要であり放置しない方がよい。 基準 下記の３つの脆弱性のみが検出された場合。 (E) ディレクトリ・リスティング 但し、重要な情報（個人情報の記載されたファイル等）が検出された場合は、既に危険な状態とい うことから、「要治療・精密検査」とする。 (J) 認証 但し、以下だった場合は、危険度が高いため、「要治療・精密検査」とする。 （１）パスワードが8 文字以内、かつ、英数字のみの場合 （２）ログイン機能に対するログアウト機能がない。もしくは、ログアウト機能は存在するが適切 な処理を行っていない場合" (K) セッション管理の不備 但し、以下だった場合は、危険度が高いため、「要治療・精密検査」とする。 （１）セッション管理機能が自作（ミドルウェア等で提供されていない独自）で問題があると判断 される場合 （２）Cookie が有効であるにも関わらず、セッション ID が URL に埋め込まれ、リファラから漏 れる場合（携帯サイトを除く） 「異常は発見されなかった」 説明 今回の診断では脆弱性は発見されなかった。但し、診断していない項目もあり、診断方法も限定してい るので、「安全である」ことと同義ではない。 基準 診断結果が「すべて正常」あるいは「該当なし」の場合2.4 診断時に利用する診断項目毎の検出パターン(目安)、脆弱性有無の判定基準について
各診断項目における検出パターン及び脆弱性有無の判定基準は以下のとおり。なお、厳密な意味で言えば、本基準で判定される挙動は、「当該脆弱性がある可能 性が高い」ということになる（必ず当該脆弱性があることを100%保障はしない）。 （A） SQL インジェクション 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 「'」 (シングルクォート)1 個 エラーになる レスポンスに DBMS 等が出力するエラーメッセージ（例：SQLException、 Query failed 等）が表示された場合にエラーが発生したと判定します。 2 「検索キー
」と「検索キー
'and'a'='a」の比較 検索キーのみと同じ結果になる HTTP ステータスコードが一致し、かつレスポンスの diff（差分）が全体の 6%未満の場合、同一の結果と判定します。検査対象が検索機能の場合 は、検索結果件数が同一の場合にも、同一の結果と判定します。 3 「検索キー(数値)
」と「検索キー
and 1=1」の比較 検索キーのみと同じ結果になる 同上 （B） クロスサイト・スクリプティング（XSS) 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 「'>"><hr>」 エスケープ等されずに出力される レスポンスボディーに検査文字列の文字列がエスケープ等されずに出力 されると脆弱と判定します。 2 「'>"><script>alert(document.cookie)</script>」 エスケープ等されずに出力される 同上 3 URL 中のファイル名として <script>alert(document.cookie)</script> エスケープ等されずに出力される 同上。http://www.xxxx.jp/service/index.html という URL であった場合、 「index.html」の部分に検査文字列をエンコードせずに挿入します。 4 javascript:alert(document.cookie); href 属性等に出力されるレスポンスボディーの特定の URI 属性（src, action, background, href, content）や、JavaScript コード（location.href, location.replace）等に検査 文字列が出力される場合、脆弱と判定します。
（C） クロスサイト・リクエスト・フォージェリ（CSRF) 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 ログイン状態において、特定副作用を持つ画面に対 して外部からパラメータを強制する 特定副作用が実行される 特定副作用を持つ機能において、以下のいずれかを満たす場合に脆弱 と判定します。 ・トークン等のパラメータが存在しない ・トークン等を削除しても特定副作用が実行される ・トークン文字列の推測が可能 ・別ユーザのトークンが使用できる 特定副作用が実行されたかは、画面に表示されるメッセージ等により判 断します。 （D） OS コマンド・インジェクション 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他）
1 「../../../../../../../sbin/ifconfig|」を入力 ifconfig の実行結果が表示される レスポンスに、127.0.0.1 等の文字列が含まれる場合、ifconfig が実行され たと判定します。
2 「;/sbin/ifconfig」を入力 ifconfig の実行結果が表示される 同上
3 「../../../../../../../windows/system32/ipconfig|」を入力 ipconfig の実行結果が表示される レスポンスに、Ethernet, adapter 等の文字列が含まれる場合、ipconfig が 実行されたと判定します。 4 「&/windows/system32/ipconfig」を入力 ipconfig の実行結果が表示される 同上 （E） ディレクトリ・リスティング 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 URL をディレクトリまでで終端しリクエストする ディレクトリ一覧が表示される。ファイ ル一覧の表示のみでは「低」危険 度、重要情報があれば「高」危険度 URL の末尾のファイル名部分を削除してリクエストを送り、ファイル一覧 がレスポンスされるか確認します。icons 等明らかに無害なものは報告し ません。抜き取りにて、一覧ファイル内のバックアップファイル等を探して 発見されたものを報告します。
（F） メールヘッダインジェクション 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 Subject、From、To 欄に「%0d%0aTo:[email protected]」 （XXX は数値 2～3 桁）を入力することで、新たなあて 先を指定できるか 新たなあて先を指定できる 改行文字の後に追加した To アドレス（@xxxx.jp のアドレス）にメールが届 く場合に、新たなあて先を指定できたと判定します。 2 Subject、From、To 欄に「%0d%0a%0d%0akensa」を入力 することで、本文内容を改ざんできるか 本文内容を改ざんできる @xxxx.jp のアドレスに届いたメールの本文部分に「kensa」という文字列が 含まれている場合、本文内容を改ざんできたと判定します。 （G） パストラバーサル 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 【UNIX 系 OS 向け】 「../../../../../../../../../etc/hosts」 /etc/hosts が表示される レスポンスに 127.0.0.1、localhost 等の文字列が含まれる場合、 /etc/hosts が表示されたと判定します。 2 【UNIX 系 OS 向け】 「../../../../../../../../../etc/hosts%00」 /etc/hosts が表示される 同上 3 【Windows 向け】 「../../../../../../../../../windows/win.ini」 win.ini が表示される レスポンスに[extensions]等の文字列が含まれる場合、win.ini が表示され たと判定します。 4 【Windows 向け】 「../../../../../../../../../windows/win.ini%00」 win.ini が表示される 同上 （H） 意図しないリダイレクト 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 クエリストリング等に URL を保持している場合に、 URL を別ドメインのもの（http://www.xxxx.jp/）に変更 してリクエストする 指定した別ドメインの URL に遷移さ せられる
Location ヘッダ、META タグの Refresh、JavaScript コード（location.href, location.assign, location.replace）によるリダイレクト部分に検査文字列が 出力される場合にリダイレクト可能と判定します。ログイン機能以外でも 脆弱性として判定します。
（I） HTTP ヘッダ・インジェクション 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 Cookie に相当するパラメータに改行コードを入力 元の値%0d%0aSet-Cookie:xxxtest%3Dxxxxtest%3B Set-Cookie のパラメータに改行が挿 入される レスポンスヘッダに、xxxxtest=xxxxtest という Set-Cookie ヘッダが存在 する場合、改行が挿入されたと判定します。 2 リダイレクト先 URL に相当するパラメータに改行コー ドを入力 元の値%0d%0aSet-Cookie:xxxxtest%3Dxxxxtest%3B Location ヘッダのパラメータに改行 が挿入される 同上 （J） 認証 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 パスワードの max 文字数が 8 文字以上確保されてい るか 8 文字未満の場合は指摘 － 2 パスワードの文字種が数字のみ、英字のみに限定さ れていないか 数字のみ、英字のみの場合は指摘 － 3 パスワードが入力時に伏字になっているか 伏字になっていない場合は指摘 － 4 パスワード間違いの際のメッセージは適切か ユーザ ID とパスワードのどちらが間 違いか分かるようなメッセージの場 合指摘 － 5 ログアウト機能はあるか、適切に実装されているか ログアウト機能がない、あるいはログ アウト後「戻る」ボタンでセッションを 再開できる場合は指摘 － 6 意図的に 10 回パスワードを間違える アカウントロックされない場合は指摘 －
（K） セッション管理の不備 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 ログインの前後でセッション ID が変化するか ｾｯｼｮﾝ ID が変わらない場合は指摘 － 2 言語・ミドルウェアの備えるセッション管理機構を使 用せず手作りのセッション管理機構を使っていない か 手作りのセッション管理機構を使用 している場合は指摘 セッション ID のパラメータ名等で、言語・ミドルウェアのセッション管理機 構を使用しているかを判断します。判断がつかない場合には、"手作りの 疑いあり"として報告します。 3 SSL を使用するサイトの場合、セッション ID を保持す る Cookie にセキュア属性が付与されているか Cookie のセキュア属性が付与されて いない場合は指摘 － 4 Cookie をオフにしてアクセスした場合、セッション ID が URL 埋め込みにならないか セッション ID が URL 埋め込みの場合 は指摘 リファラから漏洩するおそれがある場合にのみ、脆弱と判定します。（5 を 参照） 5 携帯電話向けサイト等でセッション ID を URL 埋め込 みにしている場合、外部リンクから Referer 経由でセ ッション ID が漏洩しないか Referer からセッション ID が漏洩する 場合は指摘 PC/携帯サイト両方が対象。外部へのリンク（検査対象とは異なるホスト 上のページへのリンク）が存在する場合にのみ脆弱と判定します。セッシ ョン ID の漏洩が問題とならない場合（認証等の機能が無いケースや、ワ ンタイムなセッション ID を使用しているケース）は報告から除外します。 （L） アクセス制御の不備、欠落 検出パターン 脆弱性有無の判定基準 備考 (脆弱性有無の判定基準詳細、その他） 1 URL 操作により、現在のユーザでは実行権限のない 機能が実行可能。 実行可能の場合は指摘 貸与アカウントでは実行権限が無いと推測されるページ（管理者機能等） の URL が特定できる場合に、検査を実施します。権限が無いと推測され るページ（管理者向けメニュー等）が表示された時点で、脆弱性として判 定します。 2 文書 ID､注文番号、顧客番号等がパラメータにより指 定されている場合、その ID 類を変更して、元々権限 のない情報を閲覧できるか ID 類の変更により、閲覧権限のない 情報が表示された場合は指摘 閲覧権限がない情報の ID 類が特定できる場合に検査を実施します。特 定できない場合は、ID 類の末尾数値を操作する等の方法で、参照権限 がないと推測される情報が表示されたら脆弱と判定します。 3 hidden, Cookie に現在権限が指定されており、その変 更により現在のユーザでは実行権限のない機能が 実行可能 実行可能の場合は指摘 「admin」等権限クラスを示すと推測されるパラメータが存在する場合に、 検査を実施します。
2.5 診断対象画面（機能）とその定義について
診断を実施するにあたっては、全ての画面（機能）を調査するのは困難なため、本事業では診断対象のページ 数に上限を設けており、診断対象となる画面（機能）の選定に関して以下のような定義を設けています。また、 各画面（機能）で最低限実施する診断項目を規定しました。なお、平成20 年度事業では、ここに定めた最低限 実施する範囲よりも若干広く診断をしました。 診断対象画面 (機能) 名称 診断対象画面(機能)の定義 最低限実施する診断項目 ログイン ユーザ ID とパスワードを入力する等して認証を行う画面。パ スワードの代わりに「暗証番号」等の表記になっている場合 もある。認証機能のある Web サイトの場合は、かならずどこ かにログイン画面がある（はず）。 (H) 意図しないﾘﾀﾞｲﾚｸﾄ (J) 認証 (K) ｾｯｼｮﾝ管理不備 ログアウト 認証状態を廃棄するための機能。認証機能があれば、ログ イン機能は必ずあるが、ログアウト機能を有しているとは限 らない。ログアウトボタン等が見当たらない場合は、よく探す か、サイト管理者に問い合わせる等で調べる。 (K) ｾｯｼｮﾝ管理不備 DB アクセス 検索機能やデータ登録・参照機能等、SQL を利用していると 想定される画面のこと。実際に SQL を使っているか、他の手 段(ファイル、オブジェクト DB 等)を利用しているかは分からな いので、通常 SQL を利用していると想定されるものを列挙す ればよい。 (A) SQL ｲﾝｼﾞｪｸｼｮﾝ 入力内容確認 ユーザが入力した値を次の画面で表示し、確認できるように なっている画面。一般的に、データ入力の画面は、「入力」→ 「確認」→「登録」の 3 画面構成になっていることが多く、その 場合の 2 番目の画面を指す。Web サイトによっては「入力」→ 「登録」という構成の場合もある(この場合は確認画面がない) ので、その場合は別の画面を探す。 (B) ｸﾛｽｻｲﾄ･ｽｸﾘﾌﾟﾃｨﾝｸﾞ エラー エラー表示に特化した画面のこと。意図的にエラーを発生さ せることにより、エラーに特化した画面が現れるかどうかを確 認すること。そのような「エラー専用画面」がない場合もある。 (B) ｸﾛｽｻｲﾄ･ｽｸﾘﾌﾟﾃｨﾝｸﾞ ファイル名 ファイル名と想定されるパラメータを引き回している画面のこ と。xxxxx.txt 等拡張子が値に付与されている場合や、パラメ ータ名が xxxxfile、filexxxx 等のネーミングになっていることに より見分ける。 (D) OS ｺﾏﾝﾄﾞ・ｲﾝｼﾞｪｸｼｮﾝ (G) ﾊﾟｽﾄﾗﾊﾞｰｻﾙ Cookie Cookie 設定を行っている画面。レスポンスヘッダを調べて、 Set-Cookie:が発行されている画面を探す。ミドルウェアの発 行するセッション ID 以外の Cookie を優先して探す。 (I) HTTP ﾍｯﾀﾞ･ｲﾝｼﾞｪｸｼｮﾝリダイレクト Location ヘッダや「<meta http-equiv="Refresh" ...」により、
診断対象画面 (機能) 名称 診断対象画面(機能)の定義 最低限実施する診断項目 パスワード変更 文字通り、ユーザが自分のパスワードを変更する画面のこ と。 (C) ｸﾛｽｻｲﾄ･ﾘｸｴｽﾄ･ﾌｫｰｼﾞｪﾘ DB 更新 データの新規登録や変更により、データベースに更新処理を 行っていると想定される画面を探す。実際に DB 更新を行っ ているかどうかは外部からは判別できないので、DB 更新と 想定される画面を探せばよい。 (C) ｸﾛｽｻｲﾄ･ﾘｸｴｽﾄ･ﾌｫｰｼﾞｪﾘ メール送信 重要な処理(パスワード変更、申し込み処理等)の際に確認メ ールが送信される場合がある。そのように、アプリケーション がメールを送信している画面を探す。 (F) ﾒｰﾙﾍｯﾀﾞ・ｲﾝｼﾞｪｸｼｮﾝ (D) OS ｺﾏﾝﾄﾞ・ｲﾝｼﾞｪｸｼｮﾝ (C) ｸﾛｽｻｲﾄ･ﾘｸｴｽﾄ･ﾌｫｰｼﾞｪﾘ (※注 1) アクセス制御有 情報アクセスのための認可システムが実装されている箇所 を指す。 (L) アクセス制御不備 ※注1 メール送信機能における (C) ｸﾛｽｻｲﾄ･ﾘｸｴｽﾄ･ﾌｫｰｼﾞｪﾘ の検査については、ログイン後の状態でメール送信 機能が利用可能な場合に限る。 ※注2 (E) ﾃﾞｨﾚｸﾄﾘ･ﾘｽﾃｨﾝｸﾞ に関しては特に調査対象の基準を設けていない。必要に応じて診断する。 ※注3 (G) ﾊﾟｽﾄﾗﾊﾞｰｻﾙ に関しては、ファイルアクセスが想定される画面、ファイル名を想起させるパラメータ タがあった場合に診断する。
