Vermudaコーポレートサイト
Tech Article

Webアプリ開発で押さえるセキュリティ基礎 — 主要な脆弱性と対策

  • セキュリティ
  • Web開発
  • 脆弱性対策

Webアプリケーションは便利な反面、攻撃者から狙われやすい存在でもあります。情報漏えいや不正ログインといったインシデントは、企業の信頼を大きく損ないます。この記事では、Webアプリ開発で最低限押さえておきたいセキュリティの基礎を、代表的な脆弱性とその対策を中心に、実務目線で整理します。専門用語もなるべく噛み砕いて説明します。

なぜセキュリティを「開発段階から」考えるのか

セキュリティ対策は、システムが完成してから後付けで行うと、修正コストが大きく、漏れも生じやすくなります。設計・実装の段階からセキュリティを織り込む考え方をセキュリティ・バイ・デザインと呼びます。開発の早い段階で対策を組み込むほど、安全で手戻りの少ないシステムになります。

攻撃の多くは、特別な手口ではなく基本的な対策の漏れを突いてきます。まずは代表的な脆弱性を理解することが第一歩です。

代表的な脆弱性と対策

XSS（クロスサイト・スクリプティング）

XSSは、攻撃者が悪意のあるスクリプト（プログラム）をWebページに埋め込み、それを閲覧した利用者のブラウザ上で実行させる攻撃です。これにより、Cookieの窃取（なりすましにつながる）や、偽の入力フォーム表示などが行われます。

主な対策は次の通りです。

  • 出力時のエスケープ処理: 画面に表示する値の中の 
    <
    や 
    >
    などの特殊文字を無害な文字列に変換する。
  • 適切なテンプレートエンジンの利用: 多くのフレームワークは自動エスケープ機能を備えている。これを無効化しない。
  • Content-Security-Policy（CSP）ヘッダー: 実行を許可するスクリプトの範囲を制限する。

SQLインジェクション

SQLインジェクションは、入力欄などに不正なSQL（データベースへの命令文）を混入させ、データベースを不正に操作する攻撃です。情報の全件取得や改ざん、削除につながる重大な脆弱性です。

-- 危険な例: 入力値をそのまま連結している
SELECT * FROM users WHERE name = '入力値';
-- 入力値に ' OR '1'='1 を入れられると条件が常に真になる

最も確実な対策は、プレースホルダ（プリペアドステートメント） を使い、入力値とSQL命令を分離することです。多くのライブラリが標準で提供しており、これを使えばSQLインジェクションの大半を防げます。文字列の単純な連結でSQLを組み立てないことが鉄則です。

CSRF（クロスサイト・リクエスト・フォージェリ）

CSRFは、ログイン中の利用者を悪意あるサイトへ誘導し、本人の意図しない操作（退会、送金、設定変更など）を勝手に実行させる攻撃です。

対策としては次が有効です。

  • CSRFトークン: フォーム送信時に推測困難なトークンを付与し、サーバー側で検証する。
  • SameSite Cookie属性: 外部サイトからのリクエストにCookieを送らないよう制限する。
  • 重要な操作では再認証を求める。

その他の注意すべき脆弱性

  • 認証不備・アクセス制御の不備: 権限のない利用者が他人のデータにアクセスできてしまう状態。
  • 機密情報の露出: エラーメッセージや設定ファイルから内部情報が漏れる。
  • 安全でない依存ライブラリ: 古いライブラリの既知の脆弱性が悪用される。

これらは、OWASP（Webセキュリティの国際的な非営利団体）が公開する「OWASP Top 10」という代表的な脆弱性リストでも上位に挙げられています。対策の指針として参考になります。

認証と認可を正しく区別する

セキュリティを語るうえで、認証と認可の区別は重要です。

  • 認証（Authentication）: 「あなたは誰か」を確認すること。ログインがこれにあたる。
  • 認可（Authorization）: 「あなたに何の操作を許すか」を判断すること。管理者だけが使える機能の制御などがこれにあたる。

認証で押さえるポイント

  • パスワードは平文で保存せず、ハッシュ化（不可逆な変換）して保存する。
  • 多要素認証（MFA） を導入し、パスワード漏えい時のリスクを下げる。
  • ログイン試行回数の制限により、総当たり攻撃を防ぐ。
  • セッション管理を適切に行い、ログアウトやタイムアウトを確実にする。

認可で押さえるポイント

  • 最小権限の原則: 利用者には業務に必要な最小限の権限だけを与える。
  • サーバー側で必ず権限チェックを行う。画面上でボタンを隠すだけでは不十分。

通信とサーバー設定の基礎

HTTPSの徹底

通信の暗号化（HTTPS）は今や必須です。暗号化されていない通信は、途中で盗聴・改ざんされる恐れがあります。すべてのページをHTTPSにし、HTTPでのアクセスはHTTPSへリダイレクトしましょう。HSTS という仕組みを使えば、ブラウザに常にHTTPSで接続させることができます。

セキュリティヘッダー

HTTPレスポンスに付与する「セキュリティヘッダー」で、ブラウザ側の防御を強化できます。代表的なものを挙げます。

ヘッダー役割
Content-Security-Policyスクリプトの読み込み元を制限し、XSSを緩和
Strict-Transport-Security常にHTTPS接続を強制（HSTS）
X-Content-Type-Optionsコンテンツタイプの誤認識を防ぐ
X-Frame-Optionsクリックジャッキング（偽装クリック）を防ぐ

入力検証を多層で行う

ユーザーからの入力は「信頼しない」のが原則です。入力検証（バリデーション）は次の方針で行います。

  • サーバー側で必ず検証する: 画面側（クライアント側）の検証は利便性のためであり、迂回されうる。最終的な防御はサーバー側で行う。
  • 許可リスト方式を優先する: 「危険なものを弾く」より「許可するものだけ通す」方が堅牢。
  • ファイルアップロードでは形式・サイズ・保存場所に注意する。

開発プロセスに組み込む対策と脆弱性診断

セキュリティは一度対応して終わりではなく、開発プロセスへ継続的に組み込むことが大切です。

  • 依存ライブラリの管理: 脆弱性を自動検知するツールを導入し、古いライブラリを更新する。
  • コードレビュー: セキュリティ観点をレビュー項目に含める。
  • 静的解析（SAST）: ソースコードを自動で点検し、危険なコードを早期に発見する。
  • 脆弱性診断（ペネトレーションテスト含む）: リリース前や定期的に、専門ツールや専門家による診断を行う。実際の攻撃を模した検証で、設計・実装段階で気づけなかった問題を洗い出せる。

特に、外部に公開するシステムや個人情報を扱うシステムでは、リリース前の脆弱性診断を計画に組み込んでおくと安心です。

まとめ

Webアプリのセキュリティは、特別な魔法ではなく、基本対策の積み重ねです。要点を整理します。

  • XSS・SQLインジェクション・CSRFなど代表的な脆弱性の仕組みと対策を理解する
  • 認証と認可を区別し、ハッシュ化・多要素認証・最小権限を徹底する
  • HTTPSとセキュリティヘッダーで通信とブラウザ側の防御を固める
  • 入力検証はサーバー側で、許可リスト方式を基本に行う
  • 依存ライブラリ管理・コードレビュー・静的解析・脆弱性診断をプロセスに組み込む

合同会社Vermudaは、AI駆動開発・システム開発・クラウド・DX支援を行う受託開発企業として、設計段階からのセキュリティ対策の組み込みや、安全性を考慮したWebアプリ開発を支援しています。「セキュリティに不安がある」「安心して使えるシステムを作りたい」といったご相談があれば、サービス紹介をご覧のうえ、お気軽にお問い合わせください。