Skip to main content

チートシート:アプリケーションセキュリティでよく使われる略語トップ10

2020年12月1日

0 分で読めます

こんな状況を想像してみてください。開発者であるあなたが会議に参加していて、セキュリティの専門家が、最近実施したペネトレーションテストや、あなたが書いたコードの静的解析の結果について説明しています。

説明の中で、相手はあなたが意味を知っていると思い込んでさまざまな略語を使います。しかし実際には、聞き慣れない用語ばかり。こんな経験はありませんか?残念ながら、多くのDevSecOps組織でよくあることのようです。実際、Snykも最近、SAST機能を発表した際に同じ落とし穴にはまりました。ソーシャルメディアでは、SASTとは何か知らないという声が数多く寄せられました。そこで、セキュリティでよく使われる略語トップ10をまとめたチートシートを作ることにしました。もちろん、SASTもそのひとつとして紹介します。ぜひ読み進めて、詳しくご覧ください。

SAST、DAST、SCA、OWASP、XSS、CSRF、RASP、DOS、CSP、SSRFなど、アプリケーションセキュリティに関する10の略語を解説するチートシート。
  1. SAST—Static Application Security Testing(静的アプリケーションセキュリティテスト)

  2. DAST—Dynamic Application Security Testing(動的アプリケーションセキュリティテスト)

  3. SCA—Software Composition Analysis(ソフトウェア構成分析)

  4. OWASP—Open Web Application Security Project(オープン・ウェブ・アプリケーション・セキュリティ・プロジェクト)

  5. XSS—Cross-Site Scripting(クロスサイトスクリプティング)

  6. CSRF—Cross-Site Request Forgery(クロスサイトリクエストフォージェリ)

  7. RASP—Runtime Application Self-Protection(ランタイムアプリケーション自己保護)

  8. DoS—Denial of Service(サービス拒否)

  9. CSP—Content Security Policy(コンテンツセキュリティポリシー)

  10. SSRF—Server Side Request Forgery(サーバーサイドリクエストフォージェリ)

1. SAST—Static Application Security Testing

静的アプリケーションセキュリティテスト(Static Application Security Testing)、略してSASTとは、アプリケーション、サービス、マイクロサービスなどのソースコードを分析し、安全でないコーディングに起因する潜在的なセキュリティ脆弱性を特定する手法です。SASTは通常、自動化ツールを使って実施します。ソースコード内のコーディングパターン、安全でない関数やオブジェクトを探し、セキュリティ脆弱性につながる可能性のある箇所を特定します。SASTは、新たに開発されたコードの脆弱性を見つけるために最もよく使われます。一般的にはコーディング段階、またはコードをテスト環境に昇格させるタイミングで実施します。

SASTの主な利点は、開発プロセスの早い段階で脆弱性を特定できることと、アプリケーションの機能を見るだけでは見つからない隠れた脆弱性を検出できることです。自動化されたSASTツールは、大量のコードを非常にすばやく分析できます。一方で、その結果、多数の検出結果が生成され、誤検知や、アプリケーションの状況を踏まえると実際にはリスクにならない脆弱性が含まれることも少なくありません。ツールによっては、こうした問題を解消するための調整にかなりの時間がかかる場合があります。それでも、この種のツールはセキュリティ体制に不可欠な価値をもたらします。

2. DAST—Dynamic Application Security Testing

Dynamic Application Security Testing(動的アプリケーションセキュリティテスト)、略してDASTとは、稼働中のアプリケーションやサービスを分析し、セキュリティ脆弱性を調べる手法です。DASTでは、ユーザーインターフェースやアプリケーションインターフェースを通じて、悪意のあるユーザーが行う可能性のある攻撃を模擬します。この方法の利点は、ソースコードの分析だけでは見落とされる可能性がある、アプリケーション固有の機能に起因する複雑な脆弱性を特定できることです。

DASTでは、さまざまなリクエストや入力(ペイロードと呼ばれることがよくあります)に対するアプリケーションの応答を調べ、脆弱性の兆候がないかインターフェースを分析します。ユーザー入力欄からHTTPヘッダーまで、適切なデータ処理とセキュリティ対策が実装され、攻撃者によるアプリケーションやサービスの操作を防げているかを確認します。

DASTには、自動化ツール、半自動化ツール、手動ツールを利用できます。完全自動化されたDASTツールは通常、アプリケーション内のさまざまなページをマッピングし、複数のペイロードを使って幅広い潜在的なセキュリティ脆弱性をテストできます。多くの場合、ウェブサービスやマイクロサービスのテストにも対応しています。DASTで使用するほかのツールは、特定の種類の脆弱性をひとつ、または少数に絞って、より深く分析することに特化しています。DASTは通常、アプリケーションやサービスを本番環境にデプロイする直前の、テスト後期段階で実施します。

SASTとDASTの違いについて詳しくは、Snyk LearnのSASTとDASTの比較ページをご覧ください。

3. SCA—Software Composition Analysis

Software Composition Anlaysis(ソフトウェア構成分析)、略してSCAとは、アプリケーションを分析し、ソフトウェアに含まれるサードパーティ製またはオープンソースのコンポーネントを特定することです。通常、SCAでは、それらの外部依存関係に既知のセキュリティ脆弱性やライセンス上の問題がないかを分析します。Snyk OpenSourceのような自動化されたSCAツールは、依存関係ツリー全体をマッピングできます。アプリケーションのソースコードに直接含まれるコンポーネントだけでなく、それぞれの依存関係が持つ依存関係も、さらにその先も分析します。

ソフトウェア構成分析はデリバリーパイプラインのどの段階でも実施できますが、問題が見つかった際にすばやく対処できるよう、より早い段階、たとえばコーディング段階で実行するのが望ましいでしょう。SCAを行う主な理由のひとつは、アプリケーションの開発中にサードパーティ製コンポーネントが持ち込む潜在的なセキュリティ上の欠陥を特定することです。また、サードパーティ製ソフトウェアやオープンソースソフトウェアで新たな脆弱性が見つかった際に、組織が影響の有無をすばやく評価し、修正計画を迅速に立てられるようにするためでもあります。

4. OWASP—Open Web Application Security Project

Open Web Application Security Project、略してOWASPは、ソフトウェアのセキュリティに取り組む非営利団体です。OWASPは、より安全なソフトウェアの開発に役立つ教育やガイダンスを提供する、コミュニティ主導の数多くのプロジェクトで知られています。OWASPには大規模なボランティアコミュニティがあり、より広いセキュリティおよびソフトウェア開発コミュニティに役立つプロジェクトや教材の提案、開発、運営を行っています。

最もよく知られているプロジェクトのひとつがOWASP Top 10です。コミュニティからの意見をもとに定期的に更新される、ウェブアプリケーションで最もよく見られる10種類の脆弱性のリストです。SASTやDASTを実施する際、テスターが探す脆弱性の種類を示す指針として、OWASP Top 10について話題になることがあります。あらゆる脆弱性の種類を網羅した分類ではありませんが、取り組みを始めるうえでよい基盤となります。

OWASPは世界各地でさまざまなセキュリティカンファレンスを開催し、アイデアの共有、プロジェクトへの取り組み、知識の普及を目的に定期的に集まる各地の支部も運営しています。個々のプロジェクトが、プロジェクトの内容について話し合い、改善するために、専門家やプロジェクトメンバーを集めるサミットを随時開催することもあります。

5. XSS—Cross-Site Scripting

Cross-Site Scripting(クロスサイトスクリプティング)、略してXSSは、ウェブアプリケーションでよく見つかるセキュリティ脆弱性のひとつです。2003年に初版が公開されて以来、OWASP Top 10に含まれています。XSSは、攻撃者が悪意のあるスクリプトコード(多くの場合JavaScript)を、ひとりまたは複数のユーザーのブラウザー上で実行できるようにするアプリケーション攻撃です。この種の攻撃は、ユーザーのセッション情報や個人データなどの機密情報を盗み取るために利用される可能性があります。

XSSには、一般に次の3つの種類があります。

  • 反射型:攻撃者は、攻撃ペイロードを含むリクエストをアプリケーションに送信するようユーザーを誘導します。アプリケーションがその内容をレスポンスに含めるため、ブラウザー上でスクリプトが実行されます。

  • 格納型:攻撃者は攻撃ペイロードをアプリケーションに送信し、値として保存させます。その値が動的に生成されるページの一部としてほかのユーザーに返されると、ユーザーのブラウザーでスクリプトが実行されます。

  • DOMベース:攻撃者は悪意のあるスクリプトをユーザーに送信します(通常は悪意のあるリンクを利用します)。そのスクリプトはアプリケーションを経由せず、ページのDOM内で直接実行されます。

XSSとその防止方法について詳しくは、Snyk LearnのXSSページをご覧ください。

6. CSRF—Cross-Site Request Forgery

Cross-Site Request Forgery(クロスサイトリクエストフォージェリ)、略してCSRFも、よくあるウェブアプリケーション攻撃のひとつです。CSRF攻撃では、ユーザーのブラウザーとアプリケーション間ですでに認証済みのセッションを攻撃者が悪用します。攻撃者が管理する悪意のあるウェブサイトに埋め込まれたリクエストを通じて、アプリケーションの機能を実行させます。CSRFはセッションライディングと呼ばれることもあり、「C-Surf」と発音する人もいます。

クロスサイトリクエストフォージェリでは、標的のアプリケーションに対する正当なリクエストを利用し、被害者がそのアプリケーションで認証済みのセッションを有効にしている間に、ブラウザーから同じリクエストを再送信させる手口がよく使われます。たとえば攻撃者は、オンラインバンキングアプリケーションから、銀行振込を実行するリクエストを取得することがあります。次に、悪意のあるサイトを作成し、そのリクエストをIFRAMEに埋め込みます。サイトを訪れた人は誰でも、同じリクエストを銀行アプリケーションに送信することになります。その訪問者が(別のブラウザータブなどで)銀行アプリケーションのセッションを有効にしている場合、その有効なセッションを通じてリクエストが送信されます。サイトに訪問者を誘導するため、攻撃者は銀行の利用者(つまり銀行アプリケーションの利用者である可能性が高い人)を狙ったフィッシングキャンペーンを行うでしょう。

クロスサイトリクエストフォージェリとその防止方法について詳しくは、Snyk LearnのCSRFページをご覧ください。

7. RASP—Runtime Application Self-Protection

Runtime Application Self-Protection、略してRASPとは、アプリケーションに組み込まれ、攻撃を検知してすぐに対処できるようにする防御手法です。RASPは多くの場合、サードパーティ製ツールを使って実装されます。RASPツールは通常、アプリケーションに組み込まれ、受信リクエストだけでなくアプリケーションの動作も監視して、攻撃を検知・防止します。パッケージ、ライブラリ、プラグインなどを使い、アプリケーションの入口でフィルターのように機能させ、リクエストやアプリケーションの動作を検査できます。RASPの主な利点は、アプリケーションに脆弱性が存在していても、攻撃者による悪用を防げることです(少なくとも、悪用による影響を大幅に抑えられます)。

8. DoS—Denial of Service

Denial of Service、略してDoSとは、攻撃者がアプリケーションやサービスを利用できないようにしたり、利用を妨げたりする攻撃です。一般的には、アプリケーション、サービス、システムの応答を停止させたり、極端に遅くしたりします。アプリケーションとの通信を担うネットワークインフラを攻撃する方法もあります。DoS攻撃は、攻撃者がアプリケーションのコード、システムソフトウェア、ネットワークインフラの欠陥を悪用し、ほかのユーザーが利用できない状態にすると発生します。DoS攻撃にはさまざまな方法がありますが、よく取り上げられるものとして、次の2種類があります。

  • DDoS:分散型サービス拒否攻撃。攻撃者が大量のシステム(通常はボットネットの一部)を使って標的に大量のトラフィックを送り、利用できない状態にします。

  • REDoS:正規表現サービス拒否攻撃。サーバーサイドJavaScriptアプリケーションでよく見られる特定の欠陥を悪用し、正規表現エンジンに大量のリソースを消費させて、アプリケーションを応答不能にします。

9. CSP—Content Security Policy

コンテンツセキュリティポリシー(CSP)は、XSS攻撃を防ぐためのWebアプリケーション対策です。アプリケーション開発者はHTTPヘッダーを使って、特定のソースからのみスクリプトを読み込んで実行するようブラウザーに指示できます。意図しないソースからのスクリプトの読み込みを防ぐことで、XSS攻撃を通じて送り込まれたスクリプトがブラウザーに到達しても、実行されないようにできます。

CSPに関する詳しい情報やリソースは、こちらのブログをご覧ください。

10. SSRF—サーバーサイドリクエストフォージェリ

サーバーサイドリクエストフォージェリ(SSRF)は、攻撃者がフロントエンドアプリケーションに任意の場所(他の内部サーバー、外部サーバー、さらにはアプリケーション自身など)へのリクエストを送信させる攻撃手法です。これにより、攻撃者が許可されていないデータや機能にアクセスできる可能性があります。

SSRFの詳細については、OWASPのこのガイドをおすすめします。

まとめ

他の業界と同様に、セキュリティ分野にもさまざまな専門用語があり、会話を簡潔にするために略語がよく使われます。そのため、セキュリティ担当者以外にはわかりにくいこともあります。開発者がセキュリティ担当者の使う用語を理解できれば、DevSecOpsのデリバリーパイプラインにおける連携を強化するうえで大きな力になります。

今すぐアプリケーションセキュリティの重要な略語トップ10のチートシートをダウンロードしましょう!

カテゴリー:

続きを読む

blog feature snyk container custom base recommendations
Blog

Evo Agentic AppSecのご紹介:AI開発のスピードに対応するセキュリティ

AI駆動型開発のスピードに、従来のセキュリティワークフローは追いついていません。SnykのAgentic AppSecは、セキュリティエージェントが脆弱性を継続的に検出、修正、検証し、人が基準を定められるようにします。

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

illustration hero ai
Blog

Agentic AppSecとは?

Agentic AppSecが、根拠に基づき、範囲を限定され、独立して検証されるAIエージェントを活用して、アプリケーションセキュリティの一連のプロセスを実行する方法をご紹介します。