Java Day Tokyo 2016に行ってきた！その3 JavaEEセキュリティ

５月２４日、Java Day Tokyo 2016に行ってきた内容をメモメモ。

---

JaveEE7アプリケーションとセキュリティ
・自己紹介
・若手のころ：社内システム
　　ＸＳＳ程度
・とある案件：セキュリティ診断　ＮＧ判定
・セキュリティ要件に合わせたコード
　システムによって異なるセキュリティ要件
　イントラのシステム：致命傷になりにくい
　→公開します：致命傷
・最初からセキュアなコード
　コーディングのノイズ
・実装コストを抑える方法
　　フレームワークが対応
　　ビュー、コントローラーでの対応
　　その他
・対策の基準
　ＩＰＡ：安全なＷｅｂサイトの作り方
　掲載されている脆弱性と対策
・クロスサイトスクりぷティング
　　動的ページでJSコードを注入する攻撃
　　動的に出力する値をエスケープする
　反射型、蓄積型、Ｄｏｍ型がある
・ＨＴＭＬテンプレート
　　ＥＬ式による値書き出しはデフォルトではエスケープしない
　　関数を自作する→カスタム関数はＸＭＬで書かれた設定ファイルを作成する必要有
　　もっとシンプルにメソッド呼出し
　　Faceletsのエスケープ対策：デフォルトで用意
　→対策漏れの検出容易性を考えるとFacelets
・クロスサイトリクエストフォージェリー
　攻撃者：外部ドメインから、非攻撃者の意図しないリクエストを送る
　　対策：そもそも、Ｇｅｔリクエストで状態変更してはいけない
　　　　　トークンを送信、一致するか確認
　　　ログインした時ではだめ？セッション生成時に行う
　　　セッションＩＤ以外を使う
　ＪＳＰのＣＳＲＦ：対応していない
　Facelets；Hiddenパラメータが埋め込まれている
　　ただし、ステートレスの場合は機能しない
　　faces-config.xmlはページを開くときにも要求されてしまう
・ＳＱＬインジェクション
　動的ＳＱＬで悪意のあるパラメータ
　パラメータにはプレースホルダーを使う
　ＪＰＡのプレースホルダー
　　ＪＰＱＬ：アノテーション@namedQuery
　別のＳＱＬインジェクション
　　CriteriaAPIを使用する
・セッション管理の不備
　セッションＩＤの推測、固定化
　ログインしたタイミングでセッションをリフレッシュ
　ServletAPIのForm認証
　　　GlassFishではリフレッシュする→使いやすくない
　changeSessionIDを呼び出す
　Cookieにsecure属性をつける
・パス名
　パラメータをそのままファイルパスに
　→意図しないパス
　パスチェック：自前のＡＰＩでチェック
　自前ラッパー：テストコードが書きやすい
　根本的：ファイル名を直接指定する実装を避ける
・クリックジャッキング
　iframeで透明ページを重ねてボタンを押させる
　X-Frame-Optionsをつける
　→他のiframeも影響
　SAMEORIGINにする
・HTTPヘッダインジェクション
　自力でヘッダーを書きださない
・メールヘッダーインジェクション
　パラメータをヘッダーにセットしない
・ＯＳコマンドインジェクション
・バッファオーバーフロー
　→省略
　　外部プロセスを起動しないから
・アクセス制御、認可制度
　→省略ｋ、アプリケーションによるから

その他の話題
・X-content-type-options:nosniff
　sniffきのうを無効化：サーブレットフィルタ
・Content-Security-Policy
　dom型でも防げる

まとめ