JAVA Web（6）

64. jspとサーブレットの違いは何ですか？

jspをコンパイルすると、サーブレットになります（JSPの本質はサーブレットです。JVMはJavaクラスのみを認識でき、JSPコードは認識できません。WebコンテナはJSPコードをJVMが認識できるJavaクラスにコンパイルします）
Jspはページの表示に優れており、サーブレットは論理制御に優れています。
サーブレットには組み込みオブジェクトはありません。Jspの組み込みオブジェクトは、HttpServletRequestオブジェクト、HttpServletResponseオブジェクト、およびHttpServletオブジェクトを介して取得する必要があります。
Jspはサーブレットを単純化したものです。Jspを使用する場合は、プログラマーがクライアントに出力する必要のあるコンテンツを完了するだけで済みます。JspのJavaスクリプトをクラスに挿入する方法は、Jspコンテナーによって完了します。サーブレットは完全なJavaクラスであり、このクラスのServiceメソッドを使用してクライアントへの応答を生成します。

65. jspにはどのような組み込みオブジェクトがありますか？役割は何ですか？

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

request：GETまたはPOSTリクエストからのパラメータを含むクライアントのリクエストをカプセル化します。
応答：クライアントに対するサーバーの応答をカプセル化します。
pageContext：他のオブジェクトはこのオブジェクトを介して取得できます。
セッション：ユーザーのセッションをカプセル化するオブジェクト。
アプリケーション：サーバーの動作環境をカプセル化するオブジェクト。
out：出力サーバーが応答する出力ストリームオブジェクト。
config：Webアプリケーションの構成オブジェクト。
page：JSPページ自体（Javaプログラムのこれと同等）。
例外：例外をスローするページをカプセル化するオブジェクト。

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

JSPの4つのスコープには、ページ、リクエスト、セッション、アプリケーションが含まれます。具体的には次のとおりです。

pageは、ページに関連するオブジェクトと属性を表します。
requestは、Webクライアントによって発行された要求に関連するオブジェクトと属性を表します。リクエストは複数のページにまたがり、複数のWebコンポーネントを含む場合があります。ページに表示する必要のある一時データは、このスコープに配置できます。
セッションは、特定のユーザーがサーバーとの間で確立したセッションに関連するオブジェクトと属性を表します。ユーザーに関連するデータは、ユーザー自身のセッションに配置する必要があります。
アプリケーションは、Webアプリケーション全体に関連するオブジェクトと属性を表します。これは基本的に、複数のページ、要求、およびセッションを含むWebアプリケーション全体にまたがるグローバルスコープです。

67.セッションとCookieの違いは何ですか？

HTTPプロトコルはステートレスプロトコルであるため、サーバーがユーザーのステータスを記録する必要がある場合、特定のユーザーを識別するために何らかのメカニズムを使用する必要があります。このメカニズムはセッションです。注文をクリックしたときのショッピングカートなどの一般的なシナリオボタンHTTPプロトコルはステートレスであるため、どのユーザーがそれを操作しているかがわかりません。したがって、サーバーは特定のユーザーに対して特定のセッションを作成する必要があります。このセッションは、ユーザーの識別と追跡に使用されます。多くはショッピングカートに入っています。予約してください。このセッションはサーバーに保存され、一意の識別子があります。セッションをサーバーに保存するには、メモリ、データベース、ファイルなど、さまざまな方法があります。クラスタリングの際には、セッション転送も考慮する必要があります。大規模なWebサイトでは、通常、ユーザーセッションを保存するための専用のセッションサーバークラスターがあります。このとき、セッション情報はメモリに保存され、Memcachedなどの一部のキャッシュサービスが使用されます。セッション。
サーバーが特定の顧客をどのように認識するかを考えてみてください。現在、Cookieが登場しています。HTTPリクエストが行われるたびに、クライアントは対応するCookie情報をサーバーに送信します。実際、ほとんどのアプリケーションはCookieを使用してセッション追跡を実装します。セッションが初めて作成されると、サーバーはHTTPプロトコルでクライアントにセッションIDをCookieに記録する必要があることを通知します。セッションIDはに送信されます。サーバー、そして私はあなたが誰であるかを知っています。クライアントのブラウザでCookieが無効になっている場合はどうなりますか？通常、この場合、セッション追跡にはURL書き換えと呼ばれる技術が使用されます。つまり、すべてのHTTPインタラクションで、sid = xxxxxなどのパラメータがURLに追加され、サーバーはこれに基づいてユーザーを識別します。
Cookieは、実際にはいくつかのユーザーフレンドリーなシナリオで使用できます。Webサイトに一度ログインしたことがあり、次回ログインするときにアカウントを再度入力したくないとします。どうすればよいですか？この情報はCookieに書き込むことができます。Webサイトにアクセスすると、Webサイトページのスクリプトがこの情報を読み取ることができ、ユーザー名が自動的に入力されるため、ユーザーにとって便利です。これはクッキー名の由来でもあり、ユーザーに少し甘さを与えます。つまり、要約すると、セッションはユーザーのステータスを追跡するためにサーバーに保存されるデータ構造です。このデータはクラスター、データベース、ファイルに保存できます。Cookieは、クライアントがユーザー情報を保存して一部のユーザー情報を記録するためのメカニズムです。セッションを実現する方法でもあります。

68.セッションの動作原理について教えてください。

実際、セッションはサーバーに保存されているハッシュテーブルに似たファイルです。必要な情報が含まれており、必要なときに取り出すことができます。大きなマップと同様に、内部のキーにはユーザーのセッションIDが格納され、ユーザーはサーバーにリクエストを送信するときにこのセッションIDを取得します。このとき、そこから対応する値を抽出することができます。

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

CookieとSessionは、一般に2つの独立したものと見なされます。Sessionはサーバー側で状態を維持するソリューションを使用し、Cookieはクライアント側で状態を維持するソリューションを使用します。しかし、Cookieを無効にすると、なぜセッションを取得できないのですか？セッションはセッションIDを使用して現在のセッションに対応するサーバーセッションを決定し、セッションIDはCookieを介して渡されるため、Cookieを無効にすることは、セッションIDを失うことと同じであり、セッションを取得できません。

CookieがオフになっているときにユーザーがSessionを使用すると仮定すると、それを実装する方法はいくつかあります。

php.ini構成ファイルで「session.use_trans_sid = 1」を設定するか、コンパイル時に「–enable-trans-sid」オプションをオンにして、PHPがページ間でセッションIDを自動的に渡すようにします。
URLを介して手動で値を渡し、非表示のフォームを介してセッションIDを渡します。
セッションIDをファイル、データベースなどの形式で保存し、クロスページプロセス中に手動で呼び出します。

70.スプリングMVCとストラットの違いは何ですか？

傍受メカニズムの違い

Struts2はクラスレベルのインターセプトです。各リクエストはアクションを作成します。Springと統合する場合、Struts2のActionBeanインジェクションのスコープはプロトタイプモデルであり、リクエストデータはセッターとゲッターを介して属性にインジェクトされます。Struts2では、アクションは要求と応答のコンテキストに対応します。パラメーターを受信するときは、属性を介して受信できます。つまり、属性パラメーターは複数のメソッドで共有されます。Struts2のアクションメソッドはURLに対応できますが、そのクラス属性はすべてのメソッドで共有されるため、アノテーションやその他の方法を使用して独自のメソッドを識別することはできず、複数のケースとしてのみ設計できます。

Spring MVCはメソッドレベルのインターセプトです。メソッドはリクエストコンテキストに対応するため、メソッドは基本的に独立しており、排他的なリクエストとレスポンスのデータがあります。また、各メソッドは同時にURLに対応し、パラメータの送信はメソッドに直接注入されます。これはメソッドに固有です。処理結果は、ModeMapを介してフレームワークに返されます。Spring統合中、SpringMVCのController Beanはデフォルトでシングルトンに設定されるため、デフォルトでは、すべてのリクエストに対して1つのControllerのみが作成されます。共有属性は存在しないため、スレッドセーフです。デフォルトのスコープを変更する場合は、次のことを行う必要があります。 @Scopeアノテーションの変更を追加します。

Struts2には独自のインターセプトインターセプターメカニズムがあり、SpringMVCは独立したAopメソッドを使用します。これにより、Struts2の構成ファイルのボリュームはSpringMVCよりも大きくなります。

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

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

パフォーマンスの側面

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

構成の側面

SpringMVCとSpringはシームレスです。このプロジェクトの管理と安全性もStruts2よりも高くなっています。

71. SQLインジェクションを回避する方法は？

PreparedStatement（シンプルで効果的なメソッド）
正規表現を使用して、受信パラメーターをフィルター処理します
文字列フィルタリング
JSPでこの関数を呼び出して、不正な文字が含まれていないかどうかを確認します
JSPページ判定コード

72. XSS攻撃とは何ですか？それを回避する方法は？

XSS攻撃はCSSとも呼ばれ、そのフルネームはクロスサイトスクリプティング（クロスサイトスクリプティング）です。その原則は、攻撃者がXSSの脆弱性を持つWebサイトに悪意のあるHTMLコードを入力することです。ユーザーがWebサイトを閲覧すると、このHTMLコードは攻撃の目的を達成するために、自動的に実行されます。XSS攻撃はSQLインジェクション攻撃に似ています。SQLインジェクション攻撃では、データのクエリ/変更/削除の目的を達成するためにSQLステートメントがユーザー入力として使用されます。xss攻撃では、悪意のあるスクリプトが挿入されてユーザーのブラウザを制御します。ユーザーに関する情報。XSSは、Webプログラムの一般的な脆弱性です。XSSは、クライアント側で使用される受動的攻撃方法です。

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

73. CSRF攻撃とは何ですか？それを回避する方法は？

CSRF（クロスサイトリクエストフォージェリ）は、ワンクリック攻撃またはセッションライディングとも呼ばれます。完全な中国語名はクロスサイトリクエストフォージェリです。一般的に、攻撃者はユーザーのブラウザの要求を偽造し、ユーザーがアクセスを認証したWebサイトに送信するため、標的のWebサイトはそれを受信し、ユーザーの実際の操作と間違えてコマンドを実行します。口座番号の盗難、資金の送金、虚偽のメッセージの送信などによく使用されます。攻撃者は、Webサイトの要求検証の脆弱性を使用して、このような攻撃を実行します。Webサイトは、要求がユーザーのブラウザから発信されたことを確認できますが、要求がユーザーの本当の希望から発信されたかどうかを検証することはできません。

回避する方法：

1.HTTPリファラーフィールドを確認します

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

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

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

3.トークンをリクエストアドレスに追加し、確認します

ハッカーはユーザーのリクエストを完全に偽造できるため、CSRF攻撃は成功します。リクエスト内のすべてのユーザー認証情報はCookieに含まれているため、ハッカーは認証情報を知らなくてもユーザー自身のCookieを直接使用できます。セキュリティ検証に合格します。CSRFに抵抗するための鍵は、ハッカーが偽造できない情報をリクエストに入れることであり、その情報はCookieに存在しません。ランダムに生成されたトークンをパラメータとしてHTTPリクエストに追加し、サーバー上にインターセプターを確立してトークンを検証できます。リクエストにトークンがないか、トークンの内容が正しくない場合、リクエストは拒否される可能性があります。 CSRF攻撃の。この方法は、リファラーをチェックするよりも安全です。トークンは、ユーザーがログインしてセッションに配置された後に生成され、リクエストが行われるたびにセッションから取り出され、リクエスト内のトークンと比較されます。しかし、これこのメソッドの難しさは、パラメーターの形式でトークンをリクエストに追加する方法です。
GETリクエストの場合、トークンはリクエストアドレスに追加されるため、URLはhttp：// url？csrftoken = tokenvalueになります。
POSTリクエストの場合、フォームの最後に追加する必要があります。これにより、トークンがパラメータの形式でリクエストに追加されます。

4. HTTPヘッダーの属性をカスタマイズし、確認します

このメソッドもトークンを使用して検証を実行します。前のメソッドとの違いは、トークンをパラメーターとしてHTTPリクエストに配置する代わりに、HTTPヘッダーのカスタム属性に配置することです。XMLHttpRequestクラスを介して、HTTPヘッダー属性csrftokenをこのタイプのすべてのリクエストに一度に追加し、トークン値をその中に入れることができます。これにより、前の方法でリクエストにトークンを追加する不便さが解消されます。同時に、XMLHttpRequestを介してリクエストされたアドレスはブラウザのアドレスバーに記録されないため、トークンが他のユーザーにリークされることを心配する必要はありません。リファラーを介してウェブサイト。