CompTIA SY0-701: アプリケーションとWebセキュリティ — 学習ガイド
こちらの一部です： CompTIA Security+ SY0-701 — 学習ガイド. 検証済みの解答で練習： CompTIA試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
現代のアプリケーションは、ビジネスロジック、機密データ、そして信頼できないユーザー入力が交差する場所に位置しています。Webおよびモバイルのフロントエンドはインターネット全体に公開されているため、あらゆるエンタープライズにおいて最大級かつ最も一貫して悪用される攻撃対象領域（アタックサーフェス）の一つとなっています。これらを防御するには、コードの記述方法から始まり、ランタイム保護、完全性検証、継続的テストに至るまでの多層的なコントロールが必要です。
インジェクション攻撃
インジェクションは、依然として典型的なWebの脆弱性です。これは、アプリケーションが信頼できない入力を、コードとデータを適切に分離することなく、インタープリタ（SQLクエリ、シェルコマンド、LDAPフィルタ、XMLパーサー、テンプレートエンジンなど）に連結する際に常に発生します。SQLインジェクション（SQLi）では、攻撃者はクエリを操作し、データベースに攻撃者が制御するロジックを実行させます。PHPにおける古典的な脆弱なパターンは次のようになります。
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
admin' OR '1'='1 を送信すると、クエリはすべての行を返すトートロジー（恒真式）に変換されます。より高度な亜種には、UNIONベースの抽出（' UNION SELECT credit_card FROM payments--）、ブラインドブールまたは時間ベースの推論（' AND SLEEP(5)--）、DNSコールバックを介したアウトオブバンドでのデータ窃取などがあります。決定的な修正方法は、パラメータ化クエリまたはプリペアドステートメントです。これらはクエリテンプレートとそのパラメータを別々の構造としてデータベースに送信します。
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
コマンドインジェクションも同じパターンに従いますが、オペレーティングシステムのシェルを標的とします。os.system("ping " + host) のようなコードでは、攻撃者は 8.8.8.8; cat /etc/passwd を送信して任意のコマンドを実行できます。修正には、シェルの呼び出しを完全に避け、引数配列を受け入れるAPI（subprocess.run(["ping", host], shell=False)）を使用し、シェルに渡す必要のあるすべての値に厳格な許可リスト（allow-list）検証を適用することが必要です。
クロスサイトスクリプティングとCSRF
クロスサイトスクリプティング（XSS）は、信頼されたアプリケーションによってレンダリングされるページに悪意のあるスクリプトを注入し、被害者のブラウザにサイトのオリジン内で攻撃者のコードを実行させる攻撃です。反射型XSSは脆弱なパラメータからペイロードを跳ね返させます。格納型XSSはペイロードをデータベースに永続化し、すべての閲覧者に配信します。DOMベースXSSは、信頼できないデータを innerHTML、document.write、または同様のシンクに書き込むクライアントサイドのJavaScript内で完全に発生します。その結果は、セッションハイジャックやキーロギングから、強制的なアクションによる完全なアカウント乗っ取りまで多岐にわたります。
クロスサイトリクエストフォージェリ（CSRF）は、XSSとは異なるものの、補完的な攻撃です。これは、ブラウザが自動的にCookieを付与する仕組みを悪用し、認証済みのユーザーを騙して意図しないリクエストを送信させるものです。例えば、悪意のあるサイト上の隠しフォームが bank.com/transfer にPOSTするようなケースです。防御策には、シンクロナイザートークン（フォームに埋め込まれ、サーバーサイドで検証されるセッションごとのランダムな値）、Cookieの SameSite=Lax または SameSite=Strict 属性、機密性の高いアクションに対する再認証の要求などがあります。XSSとCSRFはしばしば混同されますが、XSSが被害者のブラウザでコードを実行するのに対し、CSRFは単にブラウザにリクエストを発行させるだけです。特筆すべきは、XSS攻撃が成功すると、ほとんどのCSRF防御策を無効化できる点です。
セキュアコーディング：入力値検証 vs. 出力エンコーディング
2つのコントロールは頻繁に混同されますが、それぞれ異なる問題を解決します。入力値検証は、アプリケーションがデータを処理する前に、そのデータが期待される構造（長さ、型、文字セット、範囲、フォーマット）に準拠していることを保証します。これはサーバーサイドで行うべきであり、可能な限り許可リスト（allow-list）を使用します（例：ユーザー名に対する ^[A-Za-z0-9_]{3,20}$）。JavaScriptを使用したクライアントサイドの検証は、ユーザビリティ向上のための機能にすぎません。あらゆるHTTPプロキシでバイパス可能であり、決してセキュリティ境界として扱ってはなりません。
出力エンコーディングは、データがどのようなコンテキストに渡されても安全にレンダリングされることを保証します。完全に有効な入力である同じ文字列でも、最終的にどこに配置されるかによって異なる処理が必要になる場合があります。HTMLボディのコンテキストではHTMLエンティティエンコーディング（< → <）、属性のコンテキストではクォート付き属性エンコーディング、JavaScriptのコンテキストでは \xHH エスケープ、URLではパーセントエンコーディングが必要です。O'Brien のようなユーザー名は正当な入力ですが、HTMLに配置する際には O'Brien のようにエンコードする必要があります。入力値検証は出力エンコーディングの代わりにはならず、エンコーディングも検証の代わりにはなりません。これらはデータライフサイクルの異なる時点で異なる問題に対処します。
追加の堅牢化（hardening）には、スクリプトのソースを制限するためのContent Security Policy (CSP) ヘッダー、セッションCookieへのHttpOnlyおよびSecureフラグの付与、すべての信頼境界におけるパラメータ化APIの使用などがあります。
WAFとファイルアップロード保護
Webアプリケーションファイアウォール（WAF）は、HTTPトラフィックを検査し、既知の悪意のあるパターン（SQLiシグネチャ、XSSペイロード、パストラバーサルシーケンス、プロトコル異常など）に一致するリクエストをブロックします。リバースプロキシとしてデプロイされ（例：OWASP Core Rule Setを使用したModSecurity、AWS WAF、Cloudflare、F5）、コードが修正される前に脆弱性が発見された場合に、価値のある仮想パッチを提供します。しかし、WAFは補完的なコントロールであり、セキュアコーディングの代替にはなりません。高度な攻撃者は、エンコーディングのトリック、HTTPパラメータ汚染、ペイロードの断片化などを通じて、日常的にWAFをバイパスします。
ファイルのアップロードは、信頼できないコンテンツとサーバーサイドでの保存、そしてしばしば実行を組み合わせるため、特別な注意が必要です。保護策には、拡張子や Content-Type ヘッダーを信頼せず、マジックバイトを検査してファイルタイプを検証すること、アップロードされたファイルをウェブルートの外に保存すること、巧妙に細工されたファイル名によるディレクトリトラバーサルを防ぐためにサーバーが生成した識別子にファイル名を変更すること、保存前にアンチウイルスでスキャンすること、同一オリジンでのスクリプト実行を防ぐためにユーザーがアップロードしたコンテンツを別のドメインから配信することなどが含まれます。
実践シナリオ：SQLインジェクションによるデータベースの完全な侵害
ある小売企業の製品検索エンドポイントは、category パラメータを受け取り、それをサニタイズせずにSQLクエリに直接連結していました。あるセキュリティ研究者が、' UNION SELECT table_name,null,null FROM information_schema.tables-- を送信すると、レスポンスですべてのデータベーステーブルのリストが返されることを発見しました。その後のリクエストで customers テーブルが抽出され、名前、メールアドレス、bcryptでハッシュ化されたパスワードを含む120万件のレコードが漏洩しました。攻撃者はさらに、SQLインジェクションを介して呼び出すことができるストアドプロシージャを発見しました。これにより、ウェブルートにファイルを書き込むことが可能になり、ウェブシェルの展開とサーバーの完全な侵害につながりました。この脆弱性は3年間存在していましたが、過去2回のペネトレーションテストでは見過ごされていました。その理由は、テスターが検索エンドポイントではなく、ログインフォームのみをテストしていたためです。教訓：インジェクションテストは、明白な認証パスだけでなく、すべてのエンドポイントのすべてのパラメータを対象に実施しなければなりません。
← インシデント対応、フォレンジック、アセスメント · すべてのドメイン · クラウド、仮想化、コンテナセキュリティ →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →