チートシート：アプリケーションセキュリティのアルファベット略字トップ10

本記事は、英語ブログ[Cheatsheet: top 10 application security acronyms](https://snyk.io/blog/cheatsheet-top-10-application-security-acronyms/)を日本語化した内容です。アプリケーションセキュリティに関するアルファベット略語トップ10についてまとめてみました。SAST、DAST、SCA、OWASP、XSS、CSRF、RASP、DoS、CSP、SSRFについて解説しています。

[![logo-solid-background.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/5cca45ec-b070-6128-ae34-9437db6e049d.png)](https://www.snyk.io/jp)

# はじめに
例えば、あなたが開発者として会議に出席し、セキュリティ専門家が最近行ったペネトレーションテストや、あなたが書いたコードの静的解析の結果について議論している状況を想像してみてください。

議論している間、彼らは様々な略語を使っています。でも、あなたがその意味を知っていると思い込んでいるだけで、実際には、あなたがよく知っている用語ではなかったりします。このようなことに心当たりはありませんか？残念ながら、これは多くの[DevSecOps](https://snyk.io/series/devsecops/)の組織でよくあることのようです。実際、私たちSnykは、最近SnykのSAST機能を発表した際にこの罠にはまりました。ソーシャルメディアでは、[SAST](https://snyk.io/learn/sast-vs-dast/)が何であるかを知らないというフィードバックを多く受けました。そこで、よく使われるセキュリティ略語のトップ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/静的アプリケーションセキュリティテスト
[静的アプリケーションセキュリティテスト（SAST）](https://snyk.io/learn/application-security/static-application-security-testing/)とは、アプリケーション、サービス、マイクロサービスなどのソースコードを解析し、セキュアでないコーディングの結果として生じる潜在的なセキュリティ脆弱性を特定する手法です。SASTは、セキュリティ脆弱性につながる可能性のあるコーディングパターン、セキュアでない関数、セキュアでないオブジェクトの使用についてソースコードを検索する自動化ツールとして実装されることが多いです。SASTは、新規に開発されたコードの脆弱性を特定するために最も一般的に使用されます。通常、コーディングの段階、または、コードがテスト環境に移行される段階で実施されます。

SASTの主な利点の1つは、開発プロセスの早い段階で脆弱性を特定でき、アプリケーションの機能を見ただけでは検出できないような隠れた脆弱性を見つけることができる点です。自動化されたSASTツールは、大量のコードを非常に高速に解析することができます。しかし、大量の解析結果が作成され、その解析結果に、誤検出や、アプリケーションのコンテキスト上、まったくリスクとならない脆弱性が含まれていることがよくあります。ツールによっては、チューニングしてこれらの問題を排除するのに多大な時間を要することもあります。それでも、このようなツールの価値は、セキュリティ体制にとって極めて重要です。

#2. DAST—Dynamic Application Security Testing/動的アプリケーションセキュリティテスト
[ダイナミックアプリケーションセキュリティテスト（DAST）](https://snyk.io/learn/application-security/dast-dynamic-application-security-testing/)とは、実行中のアプリケーションやサービスにセキュリティ上の脆弱性がないかどうかを分析することです。DASTは、悪意のあるユーザーが、ユーザーやアプリケーションのインターフェースを通じて、アプリケーションに対して行う可能性のある攻撃の種類を模倣します。このアプローチの利点は、ソースコードを分析するだけでは見逃してしまうような、アプリケーションの特定の機能に起因する複雑な脆弱性を特定することができる点です。

DASTでは、アプリケーションが様々なリクエストやインプット（しばしばペイロードと呼ばれます）に対してどのように反応するかを検査することにより、脆弱性の様々な指標についてインターフェースを分析します。ユーザーの入力フィールドからHTTPヘッダまですべてを調べ、攻撃者がアプリケーションやサービスを操作するのを防ぐために、適切なデータ処理とセキュリティ対策が実施されているかどうかを判断します。

DASTの実施には、自動化、半自動化、手動化されたツールを使用することができます。完全に自動化されたDASTツールは、通常、アプリケーションの様々なページをマッピングし、さまざまなペイロードを使用して、潜在する様々なセキュリティ脆弱性をテストすることができます。これらのツールは、多くの場合、Webサービスやマイクロサービスもテストすることができます。DASTに使用されるツールは、1つまたはいくつかの特定のタイプの脆弱性をより深く分析するために、より専門的に焦点を当てるものもあります。DASTは通常、アプリケーションやサービスが本番環境にデプロイされる直前の後期テストフェーズで実施されます。

SASTとDASTの違いについて詳しくは、[SAST vs. DAST Learn page](https://snyk.io/learn/sast-vs-dast/)をご覧ください。

# 3. SCA—Software Composition Analysis/ソフトウエア構成分析
[ソフトウエア構成分析（SCA）](https://snyk.io/blog/what-is-software-composition-analysis-sca-and-does-my-company-need-it/)とは、アプリケーションを分析し、ソフトウェアに含まれるサードパーティーやオープンソースのソフトウェアコンポーネントを特定することを指します。通常、SCAには、既知のセキュリティ脆弱性や可能性のあるライセンス問題について、外部依存を分析することも含まれます。Snyk　Open　Sourceのような自動化されたSCAツールは、通常、アプリケーションのソースコード内に含まれるものを調べるだけでなく、それらの依存関係のそれぞれが持つ依存関係も分析し、依存関係ツリー全体をマッピングすることができます。

ソフトウェア構成分析は、デリバリーパイプラインのどの段階でも実行できますが、通常は、出てきた問題に迅速に対処できるように、コーディング段階といった早いタイミングで実行することが望ましいとされています。SCA を実施する主な理由は、アプリケーションの開発中にサードパーティのコンポーネントによってもたらされる潜在的なセキュリティ欠陥を特定するだけではありません。サードパーティまたはオープンソースのソフトウェアで新しい脆弱性が確認されたときに、組織が新たに発表された脆弱性の影響を受けているかどうかを迅速に評価し、迅速に改善策を策定できるようにするためでもあります。


# 4. OWASP—Open Web Application Security Project/オープン・ウェブ・アプリケーション・セキュリティ・プロジェクト
オープン・ウェブ・アプリケーション・セキュリティ・プロジェクト（[OWASP](https://owasp.org/)）は、ソフトウェアのセキュリティに焦点を当てた非営利団体です。OWASPは、より安全なソフトウェアを作るための教育やガイダンスを提供することを目的とした、コミュニティ主導の多くのプロジェクトで知られています。OWASPは、より広いセキュリティとソフトウェア開発コミュニティの利益のために、これらのプロジェクトや教材を提案、開発、管理するボランティアの大規模なコミュニティを育成しています。

有名なものとしては[OWASP Top10（読み方：オワスプトップテン）](https://snyk.io/learn/owasp-top-10-vulnerabilities/)があり、これはコミュニティからのインプットにより定期的に更新されます。SASTやDASTを実施する際、テスト担当者が探している脆弱性のタイプのガイドとして、OWASP Top 10の議論を耳にすることがあります。これは、すべての可能な脆弱性の種類を包括的に分類したものではありませんが、基本的な考え方としては、良いものです。

また、OWASP は、世界中でさまざまなセキュリティ会議を開催しており、アイデアを共有し、プロジェクトに取り組み、知識を広めるために定期的に会合するグローバルな支部を有しています。また、個々のプロジェクトでは、専門家やプロジェクト・メンバーを集めて、プロジェクトの側面について議論し、改善を加えるためのサミットを随時開催しています。


# 5. XSS—Cross-Site Scripting/クロスサイトスクリプティング
[クロスサイトスクリプティング（XSS）](https://snyk.io/learn/cross-site-scripting/)は、Webアプリケーションでよく見られるセキュリティ脆弱性の一種です。2003年に発表された最初のバージョンから、OWASP Top 10に含まれています。XSSは、アプリケーション攻撃の一種で、攻撃者が悪意のあるスクリプトコード（最も一般的なのはjavascript）をユーザーまたは多くのユーザーのブラウザ内で実行することを可能にします。この種の攻撃は、ユーザーセッションの詳細や個人データを含む機密情報を収集するために使用されることがあります。

XSSには、通常、次の3つの形態があるとされています。

* 反射型(Reflected):攻撃者は、ユーザーに攻撃用のペイロードを含むリクエストをアプリケーションに送信させ、アプリケーションは、レスポンスにそれを含めることで、ブラウザ内でそれを実行させます。
* 保存型(Stored):攻撃者が攻撃用ペイロードをアプリケーションに送信し、それが動的に構築されたページの一部として他のユーザーに返される値に格納され、そのユーザーのブラウザでスクリプトが実行される。
* DOMベース(DOM-based):攻撃者は悪意のあるスクリプトをユーザーに送り（通常は悪意のあるリンクを経由します）、アプリケーションを一切介さずにページのDOMで直接実行されます。


XSS の詳細とその防止方法については、Snyk Learn の [XSSのページ](https://snyk.io/learn/cross-site-scripting/)を参照してください。


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

[クロスサイトリクエストフォージェリ（CSRF）](https://snyk.io/learn/csrf-cross-site-request-forgery/)は、ウェブアプリケーションに対するもう一つの一般的な攻撃形態です。CSRF攻撃では、攻撃者はユーザーのブラウザとアプリケーションの間で既に認証されたセッションを利用し、攻撃者がコントロールする悪意のあるウェブサイトに埋め込まれたリクエストを通じて、そのアプリケーションの機能を実行することができます。CSRFは、セッション・ライディングとも呼ばれることがあり、C-Surfと発音することを好む人もいます。

クロスサイトリクエストフォージェリは、ターゲットアプリケーションに対して行われた有効なリクエストを取り出し、ターゲットアプリケーションとのアクティブな認証セッションがある間に、犠牲者のブラウザ内でそれを再生させることによって悪用されることがよくあります。例えば、攻撃者は、電子送金を実行するオンラインバンキングアプリケーションからのリクエストをキャプチャすることができます。そして、悪意のあるサイトを作成し、同じリクエストをIFRAMEでホストし、そのサイトにアクセスした誰もが銀行アプリケーションに同じリクエストを送信するようにします。この方法では、訪問者がその銀行アプリケーションでアクティブなセッション（おそらく別のブラウザタブ）を持っている場合、リクエストはそのアクティブなセッションの下で送信されることになります。このサイトへの訪問者を得るために、攻撃者はおそらく、標的型のフィッシングキャンペーンを利用して、銀行の顧客と思われる人々（つまり、銀行アプリケーションのユーザーと思われる人々）を騙し、悪意のあるサイトを訪問させようとするのでしょう。

クロスサイトリクエストフォージェリの詳細とその防止方法については、Snyk Learn の [CSRFのページ](https://snyk.io/learn/csrf-cross-site-request-forgery/)を参照してください。

# 7. RASP—Runtime Application Self-Protection/ランタイムアプリケーションセルフプロテクション

RASP（Runtime Application Self-Protection）とは、アプリケーションに組み込まれた防御技術で、アプリケーションが攻撃を検知して即座に対応することを可能にするものです。RASPは、サードパーティツールを介して実装されることがほとんどです。RASPツールは通常、アプリケーションに組み込まれ、送られてくるリクエストだけでなく、アプリケーションの動作も監視して、攻撃を発見し、防止します。これは、パッケージ、ライブラリ、またはプラグインを介して行われ、リクエストとアプリケーションの動作を検査できるように、アプリケーションの前面でフィルタ同様に機能します。RASP の主な利点は、アプリケーションに脆弱性が存在する場合でも、攻撃者に悪用されない（または、少なくとも悪用の範囲が大幅に制限される）ことを保証することです。


# 8. DoS—Denial of Service/サービス拒否

DoS（Denial of Service）とは、攻撃者がアプリケーションやサービスの利用を制限したり阻止したりしようとするエクスプロイトの一種です。一般的には、アプリケーション、サービス、またはシステムが応答しなくなったり、応答が極端に遅くなったりする結果になります。また、アプリケーションに通信を提供するネットワークインフラを攻撃することによっても行われることがあります。DoS攻撃は、攻撃者がアプリケーションのコード、システムソフトウェア、またはネットワークインフラの欠陥を悪用して、他者が利用できないようにすることで発生します。DoS 攻撃にはさまざまな方法がありますが、よく議論されるのは、次の 2 つの特定のタイプの DoS です。

* DDoS：Distributed Denial of Service（分散型サービス拒否）。攻撃者が多数のシステム（通常はボットネットの一部）を使用して、標的をトラフィックで圧倒し、利用不能に陥らせることです。
* [REDoS](https://snyk.io/blog/redos-and-catastrophic-backtracking/)：正規表現サービス拒否は、サーバーサイドのJavaScriptアプリケーションでよく見られる特定の欠陥で、攻撃者が正規表現エンジンに大量のリソースを消費させ、アプリケーションを応答不能にすることができます。


# 9. CSP—Content Security Policy/コンテンツ・セキュリティ・ポリシー

CSP（Content Security Policy）とは、XSS攻撃を防ぐためのWebアプリケーション対策です。アプリケーション開発者は、HTTPヘッダーを使用して、特定のソースからのスクリプトのみをロードして実行するようにブラウザに指示することができます。意図しないソースからのスクリプトの読み込みを防ぐことで、アプリケーション開発者は、XSS攻撃によって供給されたスクリプトがブラウザに到達したときに実際に実行されるのを防ぐことができます。

CSPに関するより多くのリソースと情報は、当社の[ブログ](https://snyk.io/blog/how-can-a-content-security-policy-prevent-xss-and-other-vulnerabilities/)でご覧ください。

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

[Server Side Request Forgery（SSRF）](https://learn.snyk.io/lessons/ssrf/javascript/)は、アプリケーション攻撃の一種で、攻撃者がフロントエンドアプリケーションから任意の場所（他の内部サーバー、外部サーバー、または自分自身に戻るなど）にリクエストを送信させることができるものです。これにより、攻撃者はデータや機能へ不正にアクセスすることができます。

SSRFの詳細については、[OWASP](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)によるこちらのガイドをお勧めします。


#まとめ
他の業界と同様に、セキュリティにもさまざまな専門用語があり、議論を容易にするために頭文字をとって短縮されることがよくあります。そのため、セキュリティ担当者以外の人は混乱することがあります。開発者にとって、セキュリティ・パートナーが使用する用語を解読できることは、円滑に業務を遂行するための強力なコミュニケーションツールとなるでしょう。

#最後に
Snykの公式ウェブサイトを公開しました。またSNSにて最新の脆弱性情報などを発信しているので、ぜひフォローをお願いします。

* [Snyk公式ウェブサイト](https://www.snyk.io/jp)
* [Snyk Japan Twitter](https://twitter.com/snykjp)
* [Snyk Japan Facebook](https://www.facebook.com/snykJP/)

またSnykは無料でお試しいただけます。ぜひお試しください！

https://qiita.com/SnykSec/items/aa80a976eb17299fff62


Snykを活用したブログは、ぜひQiitaアドカレ2021もご参照ください。

https://qiita.com/advent-calendar/2021/snyk