• 戻る（脆弱性対策のポイント）
  • Webアプリケーション脆弱性対策
  • ネットワーク脆弱性対策

Web アプリケーション脆弱性対策のポイント。

SQLインジェクション対策の実装方針

XSS対策の実装方針

CSRF(XSRF)対策の実装方針

• 基本的に、電文の内容をガードする。
• Session にデータを格納すれば、電文には乗らないが、
  下記セッション ハイジャックで、漏洩する危険はある。

他システム、エンドユーザからの入力データは信用しない。

• エンドユーザ入力は、必ずチェックしてから利用する。
• これは、各種を防ぐ、基本的な防護策である。
• ASP.NET では、以下の方法でインジェクション系の攻撃をチェックできる。

• 別名、クロスサイト スクリプティング（XSS）
• ASP.NET で検証される（デフォルトの設定で検証は有効）。
• 詳細：XSS対策の実装方針

補足（要求検証だけでは不十分）: ASP.NET の
要求検証（Request Validation）は「<script のような
疑わしい入力を弾く」だけの保険的な機構であり、XSS 対策の本体ではない。

層	対策
入力	要求検証（保険）。業務的な入力チェック
出力	エスケープ（HTML / 属性 / JavaScript / URL の文脈ごと） ← 本体
ブラウザ	Content Security Policy (CSP)、HttpOnly / Secure Cookie

本質は出力時のエスケープである。
ASP.NET Core の Razor は既定で HTML エスケープするため、
@Html.Raw() を使う箇所だけが危険箇所になる。

なお、ASP.NET Core には要求検証が存在しない
（出力エスケープで守る設計に移行している）。

• パラメタライズド・クエリで検証される。
• 詳細：SQLインジェクション対策の実装方針

補足: 「検証される」というより、
パラメータ化すると値が SQL 文の一部として解釈されなくなる
というのが正確なところである。
実装はADO.NET、SQLを参照。

注意すべきは、パラメータ化できない箇所である。

• テーブル名・列名を動的に組み立てる
• ORDER BY の列名を画面から受け取る
• OPENQUERY（SQL Server リンクサーバ機能）

これらは許可リスト方式（想定される値の集合と突き合わせる）で守る。

チェックが必要な部位は、アプリケーションでチェックする必要がある。

.NET では発生しないが、アンマネージド・モジュールに入力データを渡す場合は注意。

補足: マネージドコードとアンマネージドコードのブリッジで
P/Invoke や COM相互運用を行う場合、
バッファ長を呼び出し側が正しく渡す責任がある。
unsafe / stackalloc を使う箇所も同様。
現在は Span<T> を使うことで境界チェックを効かせやすくなっている。

特に Session Cookie を盗み、ユーザの Session 情報を盗み出す方法。

• ネットワークのパケット キャプチャを行い、Session Cookie を盗む事ができる。
• このため、ネットワークの暗号化（HTTPS や SSL-VPN）が必要になる。

• ネットワークの暗号化（HTTPS や SSL-VPN）をしていても、
  クロスサイト スクリプティング（XSS）で、
  Session Cookie、認証チケットなどが漏洩する。
• 詳細：XSS対策の実装方針

補足（Cookie 側の防御）: XSS 対策と併せて、
Cookie 自体に属性を付けるのが現在の標準である。

属性	効果
HttpOnly	JavaScript から読めなくする（XSS で盗まれない）
Secure	HTTPS でのみ送信する
SameSite=Lax / Strict	クロスサイトからの送信を制限（CSRF 対策にもなる）
__Host- プレフィックス	ドメイン・パスを固定し、サブドメインからの上書きを防ぐ

また、ログイン成功時にセッション ID を再発行する
（セッション固定化攻撃への対策）ことも重要である。
詳細はASP.NET Session、
ASP.NETの状態管理方式を参照。

クライアントに見せられないデータ、改ざんの危険性があるデータは、

サーバ側の Session などに持たせクライアントから見えないようにする。

または、ネットワークの暗号化（HTTPS や SSL-VPN）とは別に、
ロジックにより個別に暗号化・改ざん防止する。

この際、

• 暗号化や、改ざん防止のロジックには、
  コードやアプリケーション設計の秘匿性を要求しない。
• 暗号化や、改ざん防止のロジックが露呈してもクラッキングされないようにするために、
  一般に流布し安全性が実践的に保証されている暗号化ロジックを利用する。

補足（ケルクホフスの原理）: ここで述べられているのは、
暗号の世界でケルクホフスの原理と呼ばれる原則である。
「アルゴリズムが公開されても、鍵さえ秘密なら安全であるべき」というもので、
その裏返しが「独自の暗号を作らない（Don't roll your own crypto）」。

.NET での具体的な選択は
.NETの署名・暗号化アルゴリズムを参照。
ASP.NET Core では Data Protection API（IDataProtector）が
鍵管理まで含めて面倒を見るため、自前実装は原則不要である
（ASP.NETの状態管理方式の
machineKey に関する補足も参照）。

全体のセキュリティ バランスをとった、多重防御に基づいた設計

• 部分的にセキュリティを高めても、費用対効果が高いとはいえない。
• 複数の手段を組み合わせて実施したほうが、セキュリティ強度は高めやすい。
• 従って、要求されるセキュリティ強度をバランスよく実現する。

• 予め、定められた以上のことができないようにアプリケーションを設計する。
• ロックダウンの原則を受け入れ、必要なサーバ機能だけを利用可能にする。
• ASP.NET の実行ユーザ アカウント、DB へのログイン アカウントも、
  適切な権限になるようにする。

補足: DB のログイン アカウントについては
リソース アクセス ストラテジ、
SQL Server の認証を参照。
アプリ用アカウントに db_owner や sysadmin を与えないこと、
可能ならマネージド ID などパスワードを持たない認証にすることが要点である。

• セキュリティ アップデートは必ず適用すること。
• テスト環境でテストした後、タイムリーにアップデートを実施する。
  • セキュリティ アップデートをタイムリーに適用することが重要。
  • このため、製品修正情報の収集 ～ テスト環境などの整備が必要となる。

補足（依存パッケージも対象）: 現在は OS / ミドルウェアだけでなく、
NuGet パッケージなどの依存ライブラリが攻撃経路になることが多い
（サプライ チェーン）。

手段	内容
dotnet list package --vulnerable	既知の脆弱性を持つパッケージを検出
Dependabot / Renovate	依存の更新を自動で PR 化
ロック ファイル	packages.lock.json で解決結果を固定（ビルド）
SBOM	何を使っているかを機械可読な形で管理

CIに組み込んで継続的に検査するのが現在の定石である。

補足（最新化：現在の指針）: 本ページの分類は
OWASP Top 10 の 2010 年前後の版に近い。
現在（2021 年版）では以下が上位に来ており、
アクセス制御の不備が第 1 位である点が大きな変化である。

順位	項目	本ページとの対応
A01	アクセス制御の不備	「最小特権の原則」に相当。現在は最重要
A02	暗号化の失敗	「データの格納場所、暗号化・改ざん防止」
A03	インジェクション（XSS を含む）	「インジェクションに注意」
A04	安全でない設計	「多重防御に基づいた設計」
A05	セキュリティ設定ミス	「運用面」
A06	脆弱で古くなったコンポーネント	「セキュリティ アップデートの適用」
A07	識別と認証の失敗	「セッション ハイジャックの防止」

注目すべきは、XSS が単独項目からインジェクションに統合された一方で、
アクセス制御（認可）の不備が 1 位に上がったことである。
「ログインはできるが、他人のデータが見える」という類の欠陥が
実際に最も多い、という実態を反映している。

セキュリティ脆弱性対策ツール

• 脆弱性対策のポイント
• ネットワーク脆弱性対策
• セキュリティ（インデックス）
• CSRF(XSRF)対策の実装方針

---

Tags: 移行, テスト, ツール類