OWASPTOP10とIPAの 安全なウェブサイトの作り方、ASVS5.0に対応しています。
主なスキャン項⽬を以下に列挙します。
※各スキャンルールセットに含まれる実際のスキャンルールの内容は、カスタムスキャンルールセット機能よりご確認いただけます。詳細は、以下の記事をご参照ください。
https://www.aeyescan.help/hc/ja/articles/37804926318361
Webアプリケーションスキャン
スキャンルールセット「Webアプリケーションスキャン」に含まれる項目は以下です。
■OWASPTOP10
A01:2025 アクセス制御の不備
A02:2025 不適切なセキュリティ設定
A03:2025 ソフトウェアサプライチェーンの不備
A04:2025 暗号化の不備
A05:2025 インジェクション
A06:2025 安全でない設計
A07:2025 認証の不備
A08:2025 ソフトウェアまたはデータの完全性の不備
A10:2025 例外状況の不適切な取り扱い
各項目の概要はこちらをご参照ください。
※外部のWebサイトが開きます
Other:その他
※OWASP TOP 10に分類されない脆弱性です。
■安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構
セキュリティ実装 チェックリスト
１） SQL インジェクション
２） OS コマンド・インジェクション
３） パス名パラメータの未チェック／ディレクトリ・トラバーサル
４） セッション管理の不備
５） クロスサイト・スクリプティング
６） CSRF（クロスサイト・リクエスト・フォージェリ）
７） HTTP ヘッダ・インジェクション
８） メールヘッダ・インジェクション
９） クリックジャッキング
１０）バッファオーバーフロー
１１）アクセス制御や認可制御の欠落
■OWASP アプリケーションセキュリティ検証標準 5.0対応状況サマリー
V1.2.1
HTTP レスポンス、HTML ドキュメント、XML ドキュメントの出力エンコーディングは、メッセージやドキュメント構造の変更を避けるために、HTML 要素、HTML 属性、HTML コメント、CSS、HTTP ヘッダフィールドに関連する文字をエンコードするなど、要求されるコンテキストに関連している。
V1.2.2
URL を動的に構築する場合、信頼できないデータはそのコンテキストに応じてエンコードされている (例: クエリやパスパラメータの URL エンコーディングや base64url エンコーディング)。安全な URL プロトコルのみが許可されるようにしている (例: javascript: や data: を許可しない)。
V1.2.3
出力エンコーディングまたはエスケープは、JavaScript コンテンツ (JSON を含む) を動的に構築するときに使用され、メッセージやドキュメント構造の変更を回避している (JavaScript および JSON インジェクションを回避するため)。
V1.2.4
データ選択またはデータベースクエリ (SQL, HQL, NoSQL, Cypherなど) がパラメータ化クエリ、ORM、エンティティフレームワークもしくは他の方法により保護されており、SQL インジェクションや他のデータベースインジェクション攻撃の影響を受けない。これはストアドプロシージャを記述する際にも関係する。
V1.2.5
アプリケーションが OS コマンドインジェクションに対して保護していること、およびオペレーティングシステムコールがパラメータ化された OS クエリを使用するか、コンテキストに応じたコマンドライン出力エンコーディングを使用する。
V1.3.1
WYSIWYG エディタなどから取得した信頼できない HTML 入力はすべて、よく知られた安全な HTML サニタイゼーションライブラリもしくはフレームワークの機能を使用してサニタイズされている。
V1.3.2
アプリケーションが eval() や他の Spring Expression Language (SpEL) などの動的コード実行機能を使用しない。代替手段がない場合は、実行前に含まれるユーザ入力をサニタイズする必要がある。
V1.5.1
アプリケーションが XML パーサーを制限的な構成を使用するよう構成し、XML 外部エンティティ (XML eXternal Entity, XXE) 攻撃を防止するために外部エンティティの解決などの安全でない機能を無効にする。
V2.3.1
アプリケーションは同じユーザのビジネスロジックフローを期待した正しい手順通り、省略せずに処理する。
V3.2.1
ブラウザが不正なコンテキスト (API、ユーザがアップロードしたファイル、または他のリソースが直接リクエストされる場合など) で HTTP レスポンスのコンテンツや機能をレンダリングすることを防ぐために、セキュリティ制御が行われている。可能な制御には、HTTP リクエストヘッダフィールド (Sec-Fetch-* など) が正しいコンテキストであることを示さない限りコンテンツを提供しないこと、Content-Security-Policy ヘッダフィールドの sandbox ディレクティブを使用するか、Content-Disposition ヘッダフィールドの attachment ディポジションタイプを使用することなどがある。
V3.2.2
HTML としてレンダリングするのではなく、テキストとして表示することを意図したコンテンツは、HTML や JavaScript などのコンテンツの意図しない実行を防ぐために、安全なレンダリング関数 (createTextNode や textContent など) を使用して処理している。
V3.3.1
クッキーには 'Secure' 属性が設定されており、クッキー名に '__Host-' プレフィックスが使用されていない場合は、クッキー名に '__Secure-' プレフィックスを使用する必要がある。
V3.4.1
HTTP Strict Transport Security (HSTS) ポリシーを適用するために、Strict-Transport-Security ヘッダフィールドがすべてのレスポンスに含まれている。少なくとも 1 年間の最大有効期間を定義する必要があり、L2 以上では、ポリシーをすべてのサブドメインにも適用する必要がある。
V3.4.2
クロスオリジンリソース共有 (CORS) Access-Control-Allow-Origin ヘッダフィールドがアプリケーションによって固定値にしている。または、Origin HTTP リクエストヘッダフィールド値が使用される場合は、信頼できるオリジンの厳密な許可リストに対して検証されている。'Access-Control-Allow-Origin: *' を使用する必要がある場合、レスポンスに機密情報が含まれていない。
V3.5.1
アプリケーションが、機密機能を使用するための、許可されていないクロスオリジンリクエストを防ぐために、CORS プリフライトメカニズムに依存していない場合、これらのリクエストを検証して、アプリケーション自体から発信したものであることを確認している。これはフォージェリ防止トークンを使用して検証するか、CORS セーフリストリクエストヘッダフィールドではない追加の HTTP ヘッダフィールドを要求することで行われる。これは、一般にクロスサイトリクエストフォージェリ (CSRF) と呼ばれる、ブラウザベースのリクエストフォージェリ攻撃を防御するためのものである。
V3.5.2
アプリケーションが、機密機能の許可されていないクロスオリジン使用を防ぐために、CORS プリフライトメカニズムに依存している場合、CORS プリフライトリクエストをトリガーしないリクエストで機能を呼び出すことはできない。これは 'Origin' および 'Content-Type' リクエストヘッダフィールドの値をチェックするか、CORS セーフリストのヘッダフィールドではない追加のヘッダフィールドを使用する必要があるかもしれない。
V3.5.3
機密機能の HTTP リクエストは POST, PUT, PATCH, DELETE などの適切な HTTP メソッドを使用し、HEAD, OPTIONS, GET などの HTTP 仕様で「安全」と定義されているメソッドを使用しない。あるいは、Sec-Fetch-* リクエストヘッダフィールドの厳密なバリデーションを使用して、不適切なクロスオリジンコール、ナビゲーションリクエスト、期待されていないリソースロード (画像ソースなど) からリクエストが発生していないことを確保している。
V4.1.1
メッセージボディを持つすべての HTTP レスポンスにはレスポンスの実際のコンテンツと一致する Content-Type ヘッダフィールドを含んでいる。これには "text/", "/+xml", "/xml" などの IANA メディアタイプに従って安全な文字エンコーディング (UTF-8, ISO-8859-1 など) を指定する charset パラメータを含んでいる。
V4.4.1
WebSocket over TLS (WSS) がすべての WebSocket 接続に使用されている。
V5.2.2
アプリケーションはファイルを受け入れる際に、それ自体または zip ファイルなどのアーカイブ内のいずれかで、ファイル拡張子が予期されるファイル拡張子と一致するかどうかをチェックし、内容がその拡張子で表されるタイプに対応しているかどうかを検証している。これには最初の 'マジックバイト' のチェック、イメージの再書き込みの実行、ファイル内容のバリデーションのための専用ライブラリの使用が含まれるがこれに限定されない。L1 では、特定のビジネスまたはセキュリティ上の決定を行うために使用されるファイルのみに焦点を当てることができる。L2 以上では、受け入れられるすべてのファイルに適用する必要がある。
V5.3.1
信頼できない入力によってアップロードまたは生成され、パブリックフォルダに保存されたファイルは、HTTP リクエストで直接アクセスした場合、サーバサイドのプログラムコードとして実行できない。
V5.3.2
アプリケーションがファイル操作のためにファイルパスを作成する際、ユーザが送信したファイル名の代わりに、内部で生成されたデータまたは信頼できるデータを使用する。また、ユーザが送信したファイル名やファイルメタデータを使用する必要がある場合は、厳密なバリデーションとサニタイゼーションを適用する必要がある。これは、パストラバーサル、ローカルまたはリモートファイルインクルージョン (LFI, RFI)、サーバサイドリクエストフォージェリ (SSRF) 攻撃から保護するためである。
V6.2.1
ユーザが設定するパスワードの長さは少なくとも 8 文字であるが、最低限 15 文字にすることを強く推奨している。
V6.2.3
パスワード変更機能にはユーザの現在のパスワードと新しいパスワードが必要とされる。
V6.2.4
アカウント登録またはパスワード変更時に送信されるパスワードは、アプリケーションのパスワードポリシー (最小長など) に合致する、少なくとも上位 3000 件の利用可能な一連のパスワードと照合されている。
V6.2.5
パスワードはどのような構成でも使用でき、許可される文字の種類を制限するルールはない。大文字、小文字、数字、特殊文字の最低数についての要求を設けてはいけない。
V6.2.6
パスワード入力フィールドは type=password を使用して、そのエントリをマスクしている。アプリケーションはユーザがマスクしたパスワード全体または最後に入力したパスワードの文字を一時的に閲覧できるようにしている。
V6.2.7
「貼り付け」機能、ブラウザのパスワードヘルパー、および外部のパスワードマネージャが許可されている。
V6.3.1
クレデンシャルスタッフィングやパスワードブルートフォースなどの攻撃を防ぐためのコントロールは、アプリケーションのセキュリティドキュメントに従って実装されている。
V6.3.2
デフォルトユーザーアカウント ("root", "admin", "sa" など) がアプリケーションに存在しないか、無効になっている。
V6.4.2
パスワードのヒントや知識ベースの認証 (いわゆる「秘密の質問」) が存在しない。
V7.2.2
アプリケーションがセッション管理に動的に生成される自己完結型トークンまたはリファレンストークンを使用している。つまり、静的な API シークレットと API キーは使用していない。
V7.2.3
リファレンストークンがユーザセッションを表すために使用される場合、そのトークンは一意であり、暗号論的に安全な疑似乱数生成器 (CSPRNG) を使用して生成され、少なくとも 128 ビットのエントロピーを持つ。
V7.2.4
アプリケーションがユーザ認証 (再認証を含む) 時に新しいセッショントークンを生成し、現在のセッショントークンを終了する。
V7.4.1
セッションの終了 (ログアウトや期限切れなど) がトリガーされると、アプリケーションはセッションのそれ以上の使用を禁止している。リファレンストークンやステートフルセッションでは、これはアプリケーションバックエンドでセッションデータを無効にすることを意味する。自己完結型トークンを使用するアプリケーションでは、終了したトークンのリストを保持する、ユーザごとに所定の日時より前に生成されたトークンを禁止する、ユーザごとに署名鍵を入れ替えるなどの解決策が必要になる。
V8.2.1
アプリケーションは機能レベルのアクセスが明示的なパーミッションを持つコンシューマに制限されることを確保している。
V8.2.2
アプリケーションは、安全でない直接オブジェクト参照 (IDOR) と壊れたオブジェクトレベル認可 (BOLA) を軽減するために、データ固有のアクセスが特定のデータ項目に対する明示的なパーミッションを持つコンシューマに制限されることを確保している。
V9.1.1
自己完結型トークンがデジタル署名または MAC を使用して検証され、トークンのコンテンツを受け入れる前に改竄を防いでいる。
V9.1.2
特定のコンテキストでは、許可リストにあるアルゴリズムのみを使用して、自己完結型トークンを作成および検証している。許可リストには、許可されたアルゴリズム、理想的には対称アルゴリズムあるいは非対称アルゴリズムのいずれかのみ、を含める必要があり、'None' アルゴリズムを含めてはいけない。対称と非対称の両方がサポートされる必要がある場合は、追加のコントロールで鍵の混乱を防ぐ必要がある。
V12.1.1
TLS 1.2 や TLS 1.3 など、最新の推奨バージョンの TLS プロトコルのみが有効である。最新バージョンの TLS プロトコルを優先オプションにする必要がある。
V12.2.1
TLS がクライアントと外部向けの HTTP ベースのサービス間のすべての接続に使用されており、安全でない通信や非暗号化通信にフォールバックしない。
V12.2.2
外部向けサービスが公的に信頼できる TLS 証明書を使用している。
V13.4.1
アプリケーションは .git や .svn フォルダなどのソース管理メタデータなしでデプロイされるか、またはこれらのフォルダが外部からもアプリケーション自体からもアクセスできない方法でデプロイされる。
V14.2.1
機密データが HTTP メッセージボディまたはヘッダフィールドでのみサーバに送信され、URL とクエリ文字列には API キーやセッショントークンなどの機密データが含まれない。
V14.3.1
クライアントやセッションが終了した後、ブラウザ DOM などのクライアントストレージから認証データがクリアされる。'Clear-Site-Data' HTTP レスポンスヘッダフィールドで対応できるかもしれないが、セッションが終了した際にサーバ接続が利用できない場合にはクライアントサイドでもクリアできるようにする必要がある。
V15.2.1
アプリケーションは、文書化された更新および修復の時間枠に違反していないコンポーネントのみを含む。
V15.3.1
アプリケーションはデータオブジェクトからフィールドの必要なサブセットのみを返す。たとえば、個別のフィールドの中にはユーザーがアクセスすべきではないものがあるため、データオブジェクト全体を返すべきではない。
ネットワークスキャン
スキャンルールセット「ネットワークスキャン」に含まれる診断項目は以下です。
・ポートスキャン
TCP（0～65535）/ UDP（主要ポート) のポートの状況調査
・バナー調査
使用ソフトウェアの検出、バージョン情報の収集
・稼働サービスの設定調査
稼働サービスの設定不備の調査 例）Telnet,FTP,SMTP等
・アカウント調査
デフォルトアカウント調査、認証なしで利用できるサービスの調査
・SSL/TLS暗号化強度調査、暗号アルゴリズムの危殆化調査
NIST Special Publication 800-52 Revision 2とMozilla Security/Server Side TLSで推奨されている暗号を利用しているかを調査しております。
また、TLS暗号スイート一覧はInternet Assigned Numbers Authorityを参照しております。
APIスキャン
以下は、「APIスキャン機能」でのみ検出可能な項目の一覧となります。
※「APIスキャン機能」はBusinessプランのみ、追加可能なオプション機能です。
■OWASP API Security Top10 2023
・API1:2023 オブジェクトレベルの認可の不備
・API2:2023 認証の不備
・API3:2023 オブジェクトプロパティレベルの認可の不備
・API5:2023 機能レベルの認可不備
・API7:2023 サーバーサイドリクエストフォージェリ
・API8:2023 セキュリティの設定ミス
・API9:2023 不適切なインベントリ管理
各項目の概要はこちらをご参照ください。
※外部のWebサイトが開きます