アプリケーションセキュリティ用語略語トップ10
よく使われるAppSecの略語を解説
0 分で読めます
チートシート
アプリケーションセキュリティに関する主要な略語10選を解説
開発者であるあなたが、セキュリティ担当者から、最近実施されたペネトレーションテストや、あなたが書いたコードの静的解析の結果について説明を受けている場面を想像してみてください。
説明の中で、担当者はさまざまなアプリケーションセキュリティの略語を使い、その意味をあなたも知っているものとして話を進めます。しかし実際には、聞き慣れない用語ばかりです。心当たりはありませんか？残念ながら、これは多くのDevSecOps組織でよくあることのようです。実際、Snykが最近SAST機能を発表した際、私たちも同じ落とし穴にはまりました。ソーシャルメディアでは、SASTが何なのか知らないという声が多く寄せられたのです。そこで、よく使われるセキュリティ関連の略語トップ10をまとめたチートシートを作ることにしました。もちろんSASTも含まれているので、ぜひ読み進めてみてください。
1. SAST—静的アプリケーションセキュリティテスト
静的アプリケーションセキュリティテスト（SAST）は、アプリケーション、サービス、マイクロサービスなどのソースコードを分析し、安全でないコーディング手法によって生じる潜在的なセキュリティ脆弱性を特定する手法です。SASTは通常、自動化ツールを使ってソースコードを検索し、脆弱性につながる可能性のあるコーディングパターン、安全でない関数やオブジェクトを検出します。主に、新たに開発されたコードの脆弱性を特定するために使用されます。一般に、コーディング中、またはコードをテスト環境に移行する段階で実施します。
SASTの主な利点の一つは、開発プロセスの早い段階で脆弱性を特定できること、また、アプリケーションの機能を見るだけでは見つからない隠れた脆弱性を検出できることです。自動化されたSASTツールは、大量のコードをすばやく分析できます。一方で、その結果として多数の検出結果が生成され、誤検知や、アプリケーションの状況を踏まえると実際にはリスクではない脆弱性が含まれることも少なくありません。ツールによっては、こうした問題を解消するための調整にかなりの時間がかかります。それでも、こうしたツールはセキュリティ体制を整えるうえで欠かせない価値があります。
Capture the Flagを始めよう
オンデマンドのバーチャル入門ワークショップを見て、Capture the Flagの課題の解き方を学びましょう。
2. DAST—動的アプリケーションセキュリティテスト
動的アプリケーションセキュリティテスト（DAST）は、稼働中のアプリケーションやサービスを分析してセキュリティ脆弱性を特定する手法です。悪意あるユーザーがユーザーインターフェースやアプリケーションインターフェースを通じて行う攻撃を模倣します。この方法の利点は、ソースコードの分析だけでは見落とされる可能性がある、アプリケーション固有の機能に起因する複雑な脆弱性を特定できることです。
DASTでは、さまざまなリクエストや入力（ペイロードと呼ばれることが多い）に対するアプリケーションの応答を調べ、インターフェースに脆弱性の兆候がないか分析します。ユーザー入力欄からHTTPヘッダーまでを確認し、攻撃者によるアプリケーションやサービスの操作を防ぐための適切なデータ処理とセキュリティ対策が実装されているかを判断します。
DASTの実施には、自動、半自動、手動のツールを利用できます。完全自動化されたDASTツールは通常、アプリケーション内のさまざまなページをマッピングし、複数のペイロードを使って幅広い潜在的なセキュリティ脆弱性をテストできます。こうしたツールの多くは、Webサービスやマイクロサービスもテストできます。DASTで使われるほかのツールには、特定の種類の脆弱性を一つまたはいくつかに絞って、より詳しく分析するものもあります。DASTは通常、本番環境にアプリケーションやサービスをデプロイする直前の、テスト工程の後半に実施されます。
SASTとDASTの違いについて詳しくは、SASTとDASTの比較の記事をご覧ください。
3. SCA—ソフトウェア構成分析
ソフトウェア構成分析（SCA）とは、アプリケーションを分析し、ソフトウェアに含まれるサードパーティ製またはオープンソースのソフトウェアコンポーネントを特定することです。通常、SCAでは外部依存関係を分析し、既知のセキュリティ脆弱性やライセンス上の問題がないかを確認します。Snyk Open Sourceのような自動化されたSCAツールは、依存関係ツリー全体をマッピングできます。アプリケーションのソースコード内に含まれるコンポーネントだけでなく、それぞれの依存関係が持つ依存関係も、さらにその先も分析します。
ソフトウェア構成分析はデリバリーパイプラインのどの段階でも実施できますが、問題が見つかった場合にすぐ対処できるよう、コーディング中など早い段階で実施するのが一般的に望ましいとされています。SCAを行う主な理由の一つは、アプリケーションの開発中にサードパーティ製コンポーネントが持ち込む潜在的なセキュリティ上の欠陥を特定することです。また、サードパーティ製またはオープンソースのソフトウェアで新たな脆弱性が発見された際に、自組織が影響を受けるかどうかをすばやく評価し、迅速に修正計画を立てるためにも重要です。
SASTとSCAの比較や、安全なソフトウェアのリリースに活用する方法について詳しくご覧ください。
CTFを始めよう
オンデマンドのバーチャル入門ワークショップを視聴して、CTFの課題の解き方を学びましょう。
4. OWASP—Open Web Application Security Project
Open Web Application Security Project（OWASP）は、ソフトウェアのセキュリティに取り組む非営利団体です。OWASPは、より安全なソフトウェアを開発するための教育やガイダンスを提供する、多くのコミュニティ主導のプロジェクトで知られています。大勢のボランティアがプロジェクトや教育資料を提案、開発、運営し、セキュリティやソフトウェア開発に携わる幅広いコミュニティに役立てています。
最もよく知られているプロジェクトの一つがOWASP Top 10です。コミュニティからの意見を取り入れて定期的に更新される、Webアプリケーションでよく見られる脆弱性のトップ10をまとめたリストです。SASTやDASTを実施する際には、テスターが探す可能性のある脆弱性の種類を示す指針として、OWASP Top 10が話題に上ることがあります。考えられるすべての脆弱性を網羅しているわけではありませんが、出発点として役立ちます。
OWASPは世界各地でセキュリティカンファレンスを開催し、定期的に集まってアイデアを共有したり、プロジェクトに取り組んだり、知識を広めたりする地域支部も運営しています。個々のプロジェクトが、専門家やプロジェクトメンバーを集めて内容を話し合い、改善するためのサミットを随時開催することもあります。
5. XSS—クロスサイトスクリプティング
クロスサイトスクリプティング（XSS）は、Webアプリケーションでよく見つかるセキュリティ脆弱性の一つです。2003年に初版が公開されて以来、OWASP Top 10に掲載されています。XSSは、攻撃者が悪意あるスクリプト（多くの場合JavaScript）をユーザー、または複数のユーザーのブラウザー上で実行できるようにするアプリケーション攻撃です。この攻撃を利用して、ユーザーのセッション情報や個人データなどの機密情報を収集できます。
一般に、XSSには次の3つの種類があります。
反射型：攻撃者が、攻撃ペイロードを含むリクエストをユーザーにアプリケーションへ送信させます。アプリケーションがその内容をレスポンスに含めることで、ブラウザー上でスクリプトが実行されます。
格納型：攻撃者が攻撃ペイロードをアプリケーションに送信し、値として保存させます。その値が動的に生成されたページの一部としてほかのユーザーに返されると、ブラウザー上でスクリプトが実行されます。
DOMベース：攻撃者が悪意あるスクリプトをユーザーに送信します（通常は悪意あるリンクを使います）。アプリケーションを経由せずに、ページのDOM内で直接実行されます。
XSSとその防止方法について詳しくは、Snyk LearnのXSSページをご覧ください。
6. CSRF—クロスサイトリクエストフォージェリ
クロスサイトリクエストフォージェリ（CSRF）も、Webアプリケーションでよく見られる攻撃の一つです。CSRF攻撃では、ユーザーのブラウザーとアプリケーション間の認証済みセッションを悪用し、攻撃者が管理する悪意あるWebサイトに埋め込まれたリクエストを通じて、アプリケーションの機能を実行させます。CSRFはセッションライディングとも呼ばれ、「C-Surf」と発音する人もいます。
クロスサイトリクエストフォージェリでは、対象アプリケーションに対する正規のリクエストを利用し、被害者が対象アプリケーションとの認証済みセッションを有効にしている間に、ブラウザーからそのリクエストを再送させることがよくあります。たとえば、攻撃者がオンラインバンキングアプリケーションから、送金を実行するリクエストを取得したとします。攻撃者は悪意あるサイトを作成し、そのリクエストをIFRAMEに埋め込みます。サイトを訪れた人は誰でも、同じリクエストを銀行アプリケーションに送信することになります。訪問者がその銀行アプリケーションで有効なセッション（別のブラウザータブで開いている場合もあります）を持っていれば、そのセッションを使ってリクエストが送信されます。訪問者をサイトに誘導するため、攻撃者は銀行の顧客（つまり、その銀行アプリケーションのユーザーである可能性が高い人）を狙ったフィッシングキャンペーンを仕掛けるでしょう。
クロスサイトリクエストフォージェリとその防止方法について詳しくは、Snyk LearnのCSRFページをご覧ください。
7. RASP—実行時アプリケーション自己保護
実行時アプリケーション自己保護（RASP）とは、アプリケーションに組み込まれる防御技術で、攻撃を検知してすぐに対応できるようにします。RASPは通常、サードパーティ製ツールを使って実装します。RASPツールは一般にアプリケーションに組み込まれ、受信リクエストだけでなくアプリケーションの動作も監視して、攻撃を検知・防止します。パッケージ、ライブラリ、プラグインなどを使って実装でき、アプリケーションの前段に置くフィルターのようにリクエストやアプリケーションの動作を検査します。RASPの主な利点は、アプリケーションに脆弱性が存在していても、攻撃者による悪用を防げることです（少なくとも、悪用による影響を大幅に抑えられます）。
8. DoS—サービス拒否
サービス拒否（DoS）は、アプリケーションやサービスを利用できない状態にしたり、その可用性を低下させたりする攻撃です。一般的には、アプリケーション、サービス、システムの応答を停止させるか、極端に遅くします。また、アプリケーションとの通信を担うネットワークインフラを攻撃する場合もあります。アプリケーションのコード、システムソフトウェア、ネットワークインフラの欠陥を攻撃者が悪用して、ほかのユーザーが利用できない状態にすると、DoS攻撃が成立します。DoS攻撃にはさまざまな手法がありますが、よく話題に上るものは次の2種類です。
DDoS：分散型サービス拒否攻撃のことです。攻撃者が多数のシステム（通常はボットネットの一部）を使って標的に大量のトラフィックを送り、利用できない状態にします。
REDoS：正規表現によるサービス拒否（Regular Expression Denial of Service）は、サーバーサイドのJavaScriptアプリでよく見られる特定の脆弱性です。攻撃者が正規表現エンジンに大量のリソースを消費させ、アプリケーションを応答不能にする可能性があります。
9. CSP—コンテンツセキュリティポリシー
コンテンツセキュリティポリシー（CSP）は、XSS攻撃を防ぐためのWebアプリケーションの対策です。HTTPヘッダーを使って、特定のソースからのみスクリプトを読み込み、実行するようブラウザーに指示できます。意図しないソースからのスクリプト読み込みを防ぐことで、XSS攻撃を通じて送り込まれたスクリプトがブラウザーに到達しても、実行されないようにできます。
CSPの詳細や関連情報は、こちらのブログをご覧ください。
10. SSRF—サーバーサイドリクエストフォージェリ
サーバーサイドリクエストフォージェリ（SSRF）は、攻撃者がフロントエンドアプリケーションに任意の宛先（他の内部サーバーや外部サーバー、さらには自身）へのリクエストを送信させる攻撃手法です。これにより、攻撃者が許可されていないデータや機能にアクセスできる可能性があります。
SSRFの詳細については、OWASPのこちらのガイドをご覧ください。
まとめ
セキュリティ業界に限らず、専門用語は議論しやすいように略語で表されることがよくあります。そのため、セキュリティに携わっていない人には分かりにくい場合があります。開発者がセキュリティ担当者の使う用語を理解できれば、DevSecOpsのデリバリーパイプラインにおける連携を強化するうえで、大きな力になります。