Webアプリケーション開発で避けて通れない「セキュリティ対策」
Struts2で最低限やっておくべきCSRF・XSS・パラメータ偽装の対策法を解説します。
✅ 1. はじめに:セキュリティの重要性
Struts2は強力なフレームワークですが、セキュリティは自分で意識して組み込む必要があります。
以下のような脅威にどう対処すべきか、実践的に見ていきましょう。
✅ 2. CSRF(クロスサイトリクエストフォージェリ)
◾ CSRFとは?
- ユーザーの ログイン中セッション を悪用して、意図しない操作 を実行させる攻撃。
- 例:フォームに仕込まれた「勝手に削除」ボタンなど
◾ 対策:トークンチェック(Struts2標準)
Struts2の token
タグを使うことで簡単に対策できます。
✅ JSP側の例
<s:form action="deleteUser">
<s:token />
<s:submit value="削除" />
</s:form>
✅ struts.xml 側の設定
<action name="deleteUser" class="com.example.DeleteUserAction">
<interceptor-ref name="token"/>
<interceptor-ref name="defaultStack"/>
<result name="invalid.token">tokenError.jsp</result>
<result name="success">success.jsp</result>
</action>
✅ 3. XSS(クロスサイトスクリプティング)
◾ XSSとは?
-
入力フォームに JavaScript を仕込んでおき、表示時に実行させる攻撃。
-
例:掲示板で
<script>alert(1)</script>
を投稿
◾ 対策:エスケープ処理
Struts2では <s:property />
を使うことで自動的にエスケープされます。
❌ 危険な書き方(JSP標準タグ)
<%= userComment %> <!-- XSSの危険あり -->
✅ 安全な書き方(Struts2タグ)
<s:property value="userComment" />
※
<s:property escapeHtml="true" />
はデフォルトでtrue
✅ 4. パラメータ改ざん(パラメータ偽装)
◾ これは何?
クライアントが意図的に formのhidden値やURLパラメータを改ざん して、システムを不正操作する手口。
◾ 例
<!-- 本来 "role=USER" で送るべき -->
<input type="hidden" name="role" value="ADMIN" />
ブラウザ開発者ツールで書き換えれば、簡単に改ざんされてしまう!
◾ 対策1:サーバ側で 再チェック
-
セッションのユーザー情報と一致するか確認
-
フォームの重要情報は、サーバで再取得する
if (!loggedInUser.getId().equals(request.getParameter("userId"))) {
// 改ざんの可能性 → エラー処理
}
◾ 対策2:サーバ側保持+hidden排除
IDやロールは hidden にせず、サーバ側セッションやDBで引くべき
画面に出すのは 最小限の情報 にする
✅ 5. その他の注意すべき点
項目 | 対策 |
---|---|
SQLインジェクション | MyBatis / JPA などでプレースホルダーを使用 |
直接アクセス制御 | Interceptorでアクセス権限チェック |
レスポンスヘッダー |
X-Frame-Options , X-Content-Type-Options などを設定 |
✅ 6. 実務でやるべき最低ラインまとめ
リスク | 対策 | Struts2の機能 |
---|---|---|
CSRF |
<s:token /> 使用 + token interceptor |
✅ あり |
XSS |
<s:property /> の使用 |
✅ あり(自動escape) |
パラメータ改ざん | サーバサイド再検証 | ✅ 必要に応じて実装 |
SQLインジェクション | PreparedStatement or ORM使用 | ✅ DB層の工夫 |
✅ 7. まとめ
-
Struts2は便利な仕組みを多く持っていますが、使う側が正しく使うことが重要。
-
セキュリティ対策は「後から」ではなく「最初から」実装しておく。
-
実務では CSRF・XSS・改ざん の3点を最初に対策すべき!
▶️ 次回予告:Vol.11.20 複数フォームを安全に扱う!セッション管理と動的フォームの考え方
フォームが複数ある画面構成での入力値の管理方法や、セッションと連携した設計を見ていきます。
🧭 関連記事(Vol.11.xxxシリーズ)
連番 | タイトル | 内容分類 |
---|---|---|
Vol.11.0 | Struts2が提供してくれる便利機能まとめ9選 | 導入&概要 |
Vol.11.1 | 自動注入とステートレスActionの仕組み | フレームワーク内部理解 |
Vol.11.2 | UX改善に効く!アクション層設計と入力制御の極意(プロローグ) | UX設計・アクション層総論 |
Vol.11.2.1 | 【実践編】Struts2アクション層の役割と設計パターン(Command型 / UIアクション分離など) | アクション設計パターン |
Vol.11.2.2 | 【UX重視】戻るボタン・キャンセル処理の設計手法と「戻り先管理」のスマート実装 | 戻り先制御とUX設計 |
Vol.11.2.3 | 【設計ノウハウ】多画面遷移時のパラメータ受け渡し・保持戦略(セッション vs hidden vs URL) | パラメータ多重管理 |
Vol.11.2.4 | 【実践ガイド】ユーザー操作を考慮したアクション遷移設計(リダイレクト vs フォワードの使い分け) | UX遷移設計/Result制御 |
Vol.11.2.5 | 【トラブル防止】アクション層の共通処理とメンテナブルなBaseAction設計 | アクション共通化/保守性 |
Vol.11.3 | Struts2の defaultStack とは?Interceptorの中身を詳しく追ってみる | Interceptor |
Vol.11.3.2 | 🔧 Vol.11.3.2 独自Interceptorの作り方と使い所 Struts2のカスタマイズを“実践で使えるレベル”に一歩進めよう | Interceptor |
Vol.11.4 | 入門者のための「パラメータ自動バインディング」完全理解ガイド | 自動バインディング |
Vol.Vol.11.4.1 | 入門者のための自動バインディング実践パターン集 | 自動バインディング |
Vol.11.5 | Struts2の構成理解が“実務レベル”へと進化する決定版 | 設定ファイル構造 |
Vol.11.5.1 | Struts2の“画面遷移の全体像”を理解するためのマイルストーン記事 | 設定ファイル構造 |
Vol.11.6 | ActionSupport の便利メソッドと国際化対応 | ユーティリティ / i18n |
Vol.11.7 | validate() / input 戦略とUX設計 | 開発スタイルの違い |
Vol.11.8 | アノテーションベースの設定 vs XML定義の比較 | 開発スタイルの違い |
Vol.11.9 | バリデーション完全解説(XML / アノテーション) | バリデーション(※Vol.8補完) |
Vol.11.10 | Struts2の「OGNL」ってなに?しくみと使い方をやさしく解説 | 式言語OGNL解説 |
Vol.11.11 | ModelDriven インターフェースの使いどころと注意点 | Model駆動開発 |
Vol.11.12 | SessionAware と RequestAware でセッション/リクエスト管理 | セッション管理 |
Vol.11.13 | Resultタイプ完全解説(dispatcher / redirect / stream など) | 遷移パターン理解 |
Vol.11.14 | Vol.11.14 ValueStackの中身を理解する – 画面とActionの橋渡し役 | Action |
Vol.11.15 | Interceptorチェーンを自作してみよう(ログ / 認証フィルタ) | Interceptor |
Vol.11.16 | エラー処理と例外ハンドリングの実践パターン | ハンドリング設計 |
Vol.11.17 | Struts2でファイルアップロード機能を実装する方法 | 実装系Tips |
Vol.11.18 | 非同期通信(AJAX)とStruts2の連携方法 | フロント連携編 |
Vol.11.20 | 複数フォームを安全に扱う!セッション管理と動的フォームの考え方 | セッション管理 |
Vol.11.21 | Struts2でJSONを返す!REST API連携と非同期通信の基本設計 | セッション管理 |
Vol.11.22 | 本番環境構成とセキュリティ設計(Apache+Tomcat+Struts2連携) | 外部公開 |