Java Web の面接でよくある質問

#JSP とサーブレットの違いは何ですか? (推奨される学習: Java の頻繁な会議テストの質問 )

JSP がサービスになる JSP コードを認識すると、Web コンテナは JSP コードを Java クラスにコンパイルします。 JVM)

jsp はページ表示に優れ、サーブレットはロジック制御に優れています。

サーブレットには組み込みオブジェクトがありません。Jsp の組み込みオブジェクトは、HttpServletRequest オブジェクト、HttpServletResponse オブジェクト、および HttpServlet オブジェクトを通じて取得する必要があります。

Jsp はサーブレットを簡略化したものです。Jsp を使用する場合は、プログラマがクライアントに出力する必要がある内容だけを完成させる必要があります。Jsp 内の Java スクリプトをクラスに埋め込む方法は、Jsp コンテナーによって完了します。サーブレットは完全な Java クラスであり、このクラスの Service メソッドはクライアントへの応答を生成するために使用されます。

jsp の組み込みオブジェクトとは何ですか?機能は何ですか?

JSP には 9 つの組み込みオブジェクトがあります:

request: GET または POST リクエストからのパラメータを含むクライアントのリクエストをカプセル化します。 # #response: クライアントへのサーバーの応答をカプセル化します;

pageContext: このオブジェクトを通じて他のオブジェクトを取得できます;

session: ユーザー セッションをカプセル化するオブジェクト;

application: サーバーをカプセル化します 実行環境のオブジェクト;

out: 出力サーバー応答の出力ストリーム オブジェクト;

config: Web アプリケーションの構成オブジェクト;

page: JSP ページ自体 (プログラム内の Java this に相当);

Exception: ページによってスローされた例外をカプセル化するオブジェクト。

JSP の 4 つのスコープについて教えてください。

JSP の 4 つのスコープには、ページ、リクエスト、セッション、アプリケーションが含まれます。特に:

page は、ページと属性に関連するオブジェクトを表します。

request は、Web クライアントによって発行されたリクエストに関連するオブジェクトと属性を表します。リクエストは複数のページにまたがり、複数の Web コンポーネントが関与する場合があり、ページに表示する必要がある一時データをこのスコープに配置できます。

session は、ユーザーとサーバーによって確立されたセッションに関連するオブジェクトと属性を表します。ユーザーに関連するデータは、ユーザー自身のセッションに配置する必要があります。

application は、Web アプリケーション全体に関連するオブジェクトとプロパティを表します。基本的に、複数のページ、リクエスト、セッションを含む Web アプリケーション全体にわたるグローバル スコープです。

セッションとクッキーの違いは何ですか?

HTTP プロトコルはステートレス プロトコルであるため、サーバーがユーザーのステータスを記録する必要がある場合、特定のユーザーを識別するための何らかのメカニズムを使用する必要があります。このメカニズムはセッションです。ショッピングなどの一般的なシナリオCar では、注文ボタンをクリックすると、HTTP プロトコルはステートレスであるため、どのユーザーが操作しているかがわからないため、サーバーはユーザーを識別し、ユーザーを追跡するために、特定のユーザーに対して特定のセッションを作成する必要があります。ショッピングカートに何冊の本が入っているかがわかります。

このセッションはサーバー側に保存され、一意の識別子を持ちます。サーバー側でセッションを保存するには、メモリ、データベース、ファイルなど、さまざまな方法があります。

クラスタリング時にはセッション転送も考慮する必要があります。大規模な Web サイトでは、通常、ユーザー セッションを保存するための専用のセッション サーバー クラスターが存在します。このとき、セッション情報はメモリに配置され、一部のキャッシュが使用されます。このようなサービスMemcached としてセッションを保存するために使用されます。

サーバーが特定の顧客をどのように識別するかについて考えてみませんか?

この時点で Cookie が表示されます。 HTTP リクエストが行われるたびに、クライアントは対応する Cookie 情報をサーバーに送信します。実際、ほとんどのアプリケーションはセッション追跡を実装するために Cookie を使用します。初めてセッションが作成されると、サーバーは HTTP プロトコルでクライアントにセッション ID を Cookie に記録する必要があることを伝えます。これはセッションごとに記録されます。セッション ID がサーバーに送信され、あなたが誰であるかがわかります。

誰かが質問しました。クライアントのブラウザで Cookie が無効になっている場合はどうすればよいですか?

通常、この場合、URL 書き換えと呼ばれるテクノロジがセッション追跡に使用されます。つまり、HTTP インタラクションごとに、sid=xxxxx などのパラメータが URL に追加されます。これを使用してユーザーを識別します。

Cookie は実際にいくつかのユーザーフレンドリーなシナリオで使用できます。Web サイトに一度ログインした後、次回ログインするときにアカウントを再度入力したくないと想像してください。やるべきですか？

この情報は Cookie に書き込むことができ、Web サイトにアクセスすると、Web ページのスクリプトがこの情報を読み取り、ユーザー名を自動的に入力するため、ユーザーの利便性が高まります。クッキー名の由来でもある、ユーザーへのちょっとした甘さ。

要約すると:

セッションはユーザーのステータスを追跡するためにサーバー側に保存されるデータ構造であり、このデータはクラスター、データベース、ファイル内;

Cookie はクライアントがユーザー情報を保存するためのメカニズムであり、ユーザー情報の一部を記録するために使用され、Session の実装方法でもあります。

セッションの仕組みを教えてください。

実際、セッションはサーバー上に存在するハッシュ テーブルに似たファイルです。必要な情報はそこに保存されており、必要なときにすぐに取り出すことができます。

これは大きな地図に似ています。内部のキーにはユーザーのセッション ID が格納されます。ユーザーはサーバーにリクエストを送信するときにこのセッション ID を持ちます。このとき、対応する値をそこから抽出することができます。

クライアントが 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 をファイル、データベースなどに保存し、クロスページ プロセス中に手動で呼び出します。

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

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

Struts2 はクラスレベルのインターセプトです。各リクエストはアクションを作成します。Spring と統合する場合、Struts2 ActionBeanインジェクションスコープはプロトタイプモードであり、リクエストデータはセッターとゲッターを通じてプロパティに注入されます。

Struts2では、Actionはリクエストとレスポンスのコンテキストに相当し、パラメータを受け取る際には属性を介して受け取ることができ、属性パラメータが複数のメソッドで共有されることがわかります。

Struts2 の Action のメソッドは URL に対応できますが、そのクラス属性はすべてのメソッドで共有されます。これは、そのメソッドを識別するためにアノテーションや他のメソッドを使用することは不可能であることを意味します。複数のインスタンスとして設計されています。

SpringMVC はメソッドレベルのインターセプトであり、1 つのメソッドがリクエスト コンテキストに対応するため、メソッドは基本的に独立しており、リクエスト データとレスポンス データに排他的にアクセスできます。各メソッドは同時に URL に対応しており、メソッドに固有のパラメータの受け渡しが直接メソッドに挿入されます。処理結果はModeMapを通じてフレームワークに返されます。

Spring 統合中、SpringMVC のコントローラー Bean はデフォルトでシングルトン モードになるため、デフォルトでは、すべてのリクエストに対してコントローラーが 1 つだけ作成されます。共有属性は存在しないため、スレッドセーフです。デフォルトのスコープを変更するには、@Scope アノテーションの変更を追加する必要があります。

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

基盤となるフレームワークの違い

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

パフォーマンスの側面

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

構成の側面

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

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

PreparedStatement (シンプルで効果的なメソッド)

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

文字列フィルタリング

JSP で呼び出されるこの関数は、次のことを確認します。不正な文字が含まれています

JSPページ判定コード

XSS攻撃とは何ですか?またその回避方法はありますか?

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

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

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

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 リクエストの場合、トークンがパラメーターの形式になるように、フォームの最後に を追加します。参加をリクエストされました。

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

このメソッドもトークンを使用して検証します。前のメソッドとは異なり、代わりにトークンを配置します。トークンを HTTP リクエストのパラメータとして使用するには、それを HTTP ヘッダーのカスタム属性に置きます。

XMLHttpRequest クラスを通じて、csrftoken HTTP ヘッダー属性をこのタイプのすべてのリクエストに一度に追加し、そこにトークン値を入れることができます。

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

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