データベースにアクセスするための Java EE バックエンドがあります。サーブレットは XML データを要求し、それに従って XML 応答を送信します。次に、そのためのフロントエンドを作成する必要があります。アイデアは、jQuery AJAX を介してバックエンドと通信し、xml 要求を Java バックエンドに送信して、クライアント側でデータを処理することです。
質問:セキュリティ ホールはありますか? Java/JSP を使用してフロントエンドを作成する価値はありますか?
あまりにも一般的な質問に答えるにはあまりにも一般的ですが、クライアント側のアプリケーションを作成するときは、通常、次のことを考慮する必要があります。
入力の検証や承認チェックなどのセキュリティ制御がサーバー側で正しく実行され、クライアント制御の JavaScript に解決を委ねないようにします。AJAX アクションを呼び出す機能が UI に表示されないという理由だけで、攻撃者が AJAX アクションを呼び出すことができないと想定しないでください。ログアウトまたは別のユーザーとしてログインしているときに、テスターに、ログインしたアクションまたはあるユーザーに属するリソースに対するアクションの AJAX 要求を手動で送信してもらいます。
クライアント側のスクリプトに、XSS の脆弱性を引き起こす HTML インジェクション ホールがないことを確認します。たとえば、変数を含むマークアップの文字列での jQuery の使用html()
(または関連するappend()
などのbefore()
操作メソッド) では、$('<element>', {dynamic attributes})
代わりに作成ショートカットを使用します。同様に、プレーン JS ではcreateElement
/ setAttribute
to を優先しinnerHTML
ます。
クライアント側のスクリプトに、XSS の脆弱性を引き起こす JS インジェクション ホールがないことを確認します。タイムアウトまたはインライン イベント ハンドラに文字列を設定しないでください。.on()
代わりに、関数オブジェクトと適切なイベント処理 (例: jQuery ) を使用してください。
中間層の HTML+フォームではなく、クライアント側の JS+AJAX としてアプリケーションを作成することを検討する場合、必要な JavaScript をサポートしていないユーザー エージェントでアプリが使用できなくなっても耐えられるかどうかを検討する必要があります。
それに満足し、JS を使用可能/アクセス可能にするために追加の作業を行う場合、それは理にかなっています。
セキュリティ ホールは、使用するテクノロジに関係なく発生する可能性があります。XML と Jquery と Ajax、Java と JSP の両方にセキュリティ ホールが存在する可能性があります。どの情報がどこに存在するか、ハッカーがアプリケーションをどのようにハッキングするかなどを考慮する必要があります。