2020 年の新しい Java 面接の質問 - Java Web (2)

#1. クライアントが Cookie を禁止している場合でも、セッションは使用できますか?

Cookie と Session は一般に 2 つの独立したものであると考えられており、Session はサーバー側で状態を維持するソリューションを使用し、Cookie はクライアント側で状態を維持するソリューションを使用します。しかし、Cookie を無効にするとセッションを取得できなくなるのはなぜでしょうか?セッションはセッション ID を使用して現在の会話に対応するサーバー セッションを決定し、セッション ID は Cookie を介して渡されるため、Cookie を無効にすることはセッション ID を失うことと同等であり、したがってセッションは失われます。

ユーザーが Cookie をオフにするときにセッションを使用することを想定した実装方法は次のとおりです。

• php.ini 設定ファイルで "session.use_trans_sid = 1" を設定します。 」、またはコンパイル時に「--enable-trans-sid」オプションをオンにして、PHP がページ間でセッション ID を自動的に渡すようにします。

• URL を通じて値を手動で渡し、非表示のフォームを通じてセッション ID を渡します。

• セッション ID をファイル、データベースなどに保存し、クロスページ プロセス中に手動で呼び出します。

2. Spring MVC と Struts の違いは何ですか?

1. インターセプトメカニズムの違い

Struts2 はクラスレベルのインターセプトです. 各リクエストはアクションを作成します. Spring と統合する場合、Struts2 の ActionBean インジェクション スコープはプロトタイプ モードです. プロトタイプを作成し、setter と getter を通じてリクエスト データをプロパティに注入します。 Struts2ではActionはリクエストとレスポンスのコンテキストに相当し、パラメータを受け取る際には属性を介して受け取ることができ、属性パラメータが複数のメソッドで共有されることがわかります。 Struts2のActionのメソッドはURLに対応できますが、そのクラス属性はすべてのメソッドで共有されるため、アノテーションなどでメソッドを識別することができず、複数のインスタンスとして設計することしかできません。

SpringMVC はメソッドレベルのインターセプトであり、1 つのメソッドがリクエスト コンテキストに対応するため、メソッドは基本的に独立しており、リクエスト データとレスポンス データに排他的にアクセスできます。各メソッドは同時に URL に対応しており、メソッドに固有のパラメータの受け渡しが直接メソッドに挿入されます。処理結果はModeMapを通じてフレームワークに返されます。 Spring 統合中、SpringMVC のコントローラー Bean はデフォルトでシングルトン モードになるため、デフォルトでは、すべてのリクエストに対してコントローラーが 1 つだけ作成されます。共有プロパティは存在しないはずなので、スレッドセーフです。デフォルトのスコープを変更したい場合は、 @Scope アノテーションの変更を追加します。

Struts2には独自のインターセプタ機構があり、SpringMVCでは独自のAopメソッドを使用しているため、Struts2の設定ファイルの量はSpringMVCに比べて多くなります。

(推奨される関連チュートリアル: java エントリ プログラム )

2. 基礎となるフレームワークの違い

Struts2 は、フィルター (StrutsPrepareAndExecuteFilter)、SpringMVC ( DispatcherServlet ) は、サーブレットを使用して実装されます。フィルタはコンテナの起動後に初期化されますが、サーブレットよりも後で、サービスの停止後にクラッシュします。サーブレットは、フィルターが呼び出される前に呼び出されたときに初期化され、サービスの停止後に破棄されます。

3. パフォーマンスの観点から見ると、

Struts2 はクラスレベルのインターセプトです。各リクエストはインスタンスの新しいアクションに対応し、すべての属性値の注入をロードする必要があります。SpringMVC はゼロを実装します。 SpringMVC はメソッド インターセプトに基づいているため、インジェクション用のシングルトン モード Bean のロードが必要になります。したがって、SpringMVC の開発効率とパフォーマンスは Struts2 よりも高くなります。

4. 構成の点では、

spring MVC と Spring はシームレスです。このプロジェクトの管理とセキュリティも Struts2 よりも高くなっています。

3. SQL インジェクションを回避するにはどうすればよいですか?

• PreparedStatement (シンプルで効果的な方法)

• 正規表現を使用して受信パラメータをフィルタリングする

• 文字列フィルタリング

• JSP内でこの関数を呼び出して、不正な文字が含まれているかどうかを確認します

• JSPページ判定コード

4. XSS 攻撃とは何ですか?また、それを回避する方法は何ですか?

XSS 攻撃は CSS とも呼ばれ、正式名称は Cross Site Script (クロスサイト スクリプティング攻撃) で、攻撃者が XSS の脆弱性のある Web サイトに悪意のある HTML コードを入力するという原理です。ユーザーが Web サイトを閲覧すると、この HTML コードが自動的に実行され、攻撃の目的が達成されます。

XSS 攻撃は SQL インジェクション攻撃に似ています。SQL インジェクション攻撃では、SQL ステートメントがデータのクエリ/変更/削除のためのユーザー入力として使用されます。XSS 攻撃では、悪意のあるスクリプトが挿入され、ユーザーをターゲットにします。何らかのユーザー情報を取得します。 XSS は Web プログラムの一般的な脆弱性であり、クライアント側で使用される受動的な攻撃方法です。

XSS 防止の一般的な考え方は、入力 (および URL パラメーター) をフィルターし、出力をエンコードすることです。

(ビデオ チュートリアルの推奨: java ビデオ チュートリアル)

5. CSRF 攻撃とは何ですか?また、それを回避する方法は何ですか?

CSRF (クロスサイト リクエスト フォージェリ) は、ワンクリック攻撃またはセッション ライディングとも呼ばれ、正式な中国語名はクロスサイト リクエスト フォージェリです。一般的に、攻撃者はユーザーのブラウザからのリクエストを偽造し、ユーザーがアクセスを認証した Web サイトに送信します。これにより、標的となる Web サイトはそれを受信し、それがユーザーの実際の操作であると誤って認識し、コマンドを実行します。アカウントの盗難、送金、偽のメッセージの送信などによく使用されます。攻撃者は、Web サイトのリクエスト検証の脆弱性を悪用してこのような攻撃を実行しますが、Web サイトはリクエストがユーザーのブラウザからのものであることは確認できますが、リクエストがユーザーの真の意図からのものであるかどうかを確認することはできません。

回避方法:

1. HTTP Referer フィールドを確認する

HTTP ヘッダーの Referer フィールドには、HTTP リクエストの送信元アドレスが記録されます。通常の状況では、セキュリティが制限されたページへのアクセス要求は同じ Web サイトから送信され、ハッカーがそのページに CSRF 攻撃を実行したい場合、通常、自分の Web サイトでのみリクエストを作成できます。したがって、Referer 値を検証することで CSRF 攻撃を防御できます。

2. 認証コードを使用する

認証コードをキー操作ページに追加し、リクエストを受信後、バックグラウンドで認証コードを判断し、CSRF を防止します。しかし、この方法はあまりユーザーフレンドリーではありません。

3. リクエスト アドレスにトークンを追加して検証します

CSRF 攻撃が成功する理由は、ハッカーがユーザーのリクエストを完全に偽造でき、リクエスト内のすべてのユーザー検証情報が存在するためです。 Cookie に含まれるため、ハッカーは検証情報を知らなくても、ユーザー自身の Cookie を直接使用してセキュリティ検証に合格することができます。

CSRF に対抗するには、ハッカーが偽造できない情報をリクエストに含めることが重要です。この情報は Cookie には存在しません。ランダムに生成されたトークンをパラメータとしてHTTPリクエストに追加し、サーバー側でトークンを検証するインターセプタを作成することができますが、リクエストにトークンが存在しなかったり、トークンの内容が間違っていたりする場合は、トークンが不正である可能性があると考えられます。 CSRF 攻撃であるため、リクエストは拒否されます。

このメソッドは、Referer を確認するより安全です。ユーザーがログインしてセッションに配置した後にトークンを生成できます。その後、トークンはリクエストごとにセッションから取り出して、リファラー内のトークンと照合できます。比較してください。ただし、このメソッドの難しい点は、トークンをパラメーターの形式でリクエストに追加する方法です。

GET リクエストの場合、トークンはリクエスト アドレスに追加されるため、URL は

http://url?csrftoken=tokenvalue

になります。POST リクエストの場合は、最後に

<input type="hidden" name="csrftoken" value="tokenvalue"/>

## を追加する必要があります#このようにして、トークンはパラメータの形式でリクエストに追加されます。

4. HTTP ヘッダーの属性をカスタマイズして検証する

このメソッドも検証にトークンを使用します。前のメソッドとの違いは、ここではトークンが使用されていないことです。これをパラメータとして HTTP リクエストに配置し、HTTP ヘッダーのカスタム属性に配置します。 XMLHttpRequest クラスを使用すると、このタイプのすべてのリクエストに csrftoken HTTP ヘッダー属性を一度に追加し、そこにトークン値を入れることができます。

これにより、以前の方法でリクエストにトークンを追加する不便さが解決されると同時に、XMLHttpRequest でリクエストされたアドレスがブラウザのアドレス バーに記録されなくなり、リファラーを通じてトークンが他の Web サイトに漏洩します。

関連する面接の質問をさらに知りたい場合は、

java の面接の質問列にアクセスしてください。

以上が2020 年の新しい Java 面接の質問 - Java Web (2)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。