→リダイレクトではなくフォワードが使われるリダイレクト...サーバからクライアントに対して一度302を返すことで遷移先のURLを伝えクライアントからサーバへ改めてHTTPリクエストを発行しているフォワード...アプリケーションサーバの中でだけで遷移処理が行われる。そのため1回のHTTPリクエスト遷移が可能になる。リダイレクトよりもフォワードは応答が速いため処理結果で異なるjspを表示する際などはフォワードを使用することが推奨されている。・リクエストスコープにおける情報の受け渡しリクエストスコープ...フォワード元とフォワード先の間でJavaのオブジェクトを共有するための仕組みである。(→cf.リクエストパラメータ...HTTPのGET、POSTメゾットによってクライアントからWebアプリケーションに文字列として渡されるものである。受け取った値を変更することはできない。)アプリケーションサーバから提供される仕組み。フォワードの前後でJavaオブジェクトを共有することができる。一回のHTTPリクエストを処理する間のみ有効なため、リクエスト処理が終了するとリクエストスコープに保持されていた情報は消えてしまう。・セッションスコープとリクエストスコープの違いに関してセッションスコープはCookieなどの仕組みを利用し、アプリケーションサーバのメモリに保存される。そのためセッションが増えるとメモリ不足になる。Tomcatではデフォルト30分に設定されている)セッションスコープでは、複数のリクエストにまたがって有効なためログイン状態や購入商品などユーザーがWebアプリケーションを使用している間に保持しておきたい情報を格納するのに適している。リクエストスコープではクライアントからリクエストが届いてから、レスポンスを返す間しか有効にならない。・コラム/URLリライティング→PHPなどではCookieが利用できない場合「PHPSESSID」というパラメータ名でリクエストのURLにセッションIDが含められるようにformタグが自動で書き換えられサブミット時にGETパラメータとしてセッションIDが渡されるようにしている。・Webアプリケーションのアーキテクチャロジックとデザインの分離ソフトウェアの設計スタイルとその設計に基づく全体構造を「アーキテクチャ」と呼ぶ。cf)カスタムタグエラーメッセージなどを開発者が自分で用意したタグをカスタムタグと呼ぶ。・例題Webアプリのアーキテクチャーwebアプリケーション内の細かな処理は「入力データの取り出し(Input)」「データ処理(Process)」「HTML出力準備(Output)」という「IPO」の流れで構成されている。例題のWebアプリは「モデル(model)」、「ビュー(view)」、「コントローラ(controller)」で構成される、「MVCモデル」である。a)modelモデルはアプリケーションの「処理」の部分とそれにかかわる情報を保持する。そのため、画面に対する入出力といった部分には一切関わりを持っていない。b)viewビューはモデルによる処理結果の画面への表示を担当する。処理結果自体はmodelが持っているためビューがモデルから取り出してユーザに見やすいように整形した上で画面へ表示する。画面への表示が役割であり、情報処理には関わらないc)controllercontrollerは画面からの情報入力とモデルの呼び出し及びにその結果に従ったビューの呼び出しを担当する。controllerはユーザーがユーザが画面に入力した情報を取り出し処理を担当するmodelに渡す。modelの処理結果によって結果を表示するviewを呼び出す。MVCモデルに基づくことで、「ロジックとデザインの分離」を実現することができる。ロジックーmodelデザインーviewMVCモデルによる処理の流れ1、Webブラウザから送信されたリクエストはまずコントローラが受け取る。2、コントローラはリクエストからパラメータを取り出し、必要に応じてセッションからの情報を取り出す。3、入力情報を処理するモデルを呼び出し、各パラメータを処理、格納する4、モデルはそれらの結果をコントローラに返却する。(この際に返すのは処理結果そのものではなく、成功・失敗程度のステータスになる)5、コントローラは受け取ったステータスから表示すべき画面を選択し、その画面を表示するためのビューを呼び出す。6、ビューはモデルを参照し、表示すべき情報を取り出しその結果をHTMLとして出力してHTTPレスポンスとしてWebブラウザに返す。・フレームワークによるアーキテクチャーの実現フレームワークとはアーキテクチャを実現する部分は共通化し、見た目など個々のアプリケーションで異なる部分は別々に開発できるようになれば効率よくアプリケーションを開発できるようになる。この共通部品の考え方がソフトウェアにおけるフレームワークである。cf)Struts(フレームワーク)・レイヤーパターンによるデータアクセス層の分離224JavaではdbにアクセスするAPIとしてJDBCが用意されており、JDBCを使ってDBに対してSQLを発行し結果を取得する。a)データソースの取得WebアプリケーションがDBに接続するにはまず「JNDI」と呼ばれるAPIを利用してアプリケーションサーバからDataSourceクラスのオブジェクトを取得するb)コネクションの取得DataSourceが取得できたら、getConectionメソッドを呼び出してデータベースへ接続する。データベースへの接続はConnectionクラスのオブジェクトとしてあらわされる。c)SQLの発行SQLを発行するにはConnectionオブジェクトのcreateStatementメソッドを呼び出してStatementオブジェクトを取得する。引数にSQL文を指定してStatementオブジェクトのexecuteQueryメソッドを呼び出すことでSQLが発行されるd)SQL実行結果の取得SQLの実行結果はexecuteQueryメソッドの戻り値として得られるResultSetオブジェクトから取得できる。ResultSetオブジェクトではnextメソッドでレコードを呼び出し引数にgetXXXXメソッドを呼び出すことで各カラムの値を取り出すことができる。・「Layers」と呼ばれるアーキテクチャーパターン上位レイヤーが下位レイヤーの提供する機能を利用することで、各レイヤの作りを単純化していく考えである。●コントローラー・ビューが属するシステム利用者とのインターフェースを担当するレイヤ。●モデルアプリケーションが実現すべき固有の処理を実行するためのレイヤ。「業務ロジック」と訳される。ビジネスロジックは、ユーザーが入力した情報をプレゼンテーション層から受け取り、必要に応じてデータベースを利用し、処理を実行する。処理結果は、プレゼンテーション層へ返す。c)データアクセス層(cf.インテグレーション層)●モデルビジネスロジック層とデータベースの仲立ちを行うためのレイヤ。データベースへのアクセスなど面倒な処理をビジネスロジックから切り離し、データベースへの細かなアクセス手順を意識せずとも利用できるようにする。cf)DAOを使用する。・「インピーダンス・ミスマッチ」ーリレーショナルデータベースとオブジェクト指向の表現の違い。ー優れた設計の再利用。共通で必要なデータベースアクセスなどはフレームワークの規定に沿って必要なコードを作成するだけで済む点。ー生産性の向上から結果としての品質の向上。ー新たに作成されるコード自体がフレームワークによって減るため、テスト工数の削減につながる。ーフレームワークの設計者の意図した範囲ではないことを実現しようとすると難易度が高くなってしまうことなどがある。ーフレームワークは簡単に使えるように内部をブラックボックス化してしまうために、裏側で何が行われているのか知ることができなくなる。開発現場で不具合が生じた場合フレームワーク起因の可能性もある。そのために開発者はフレームワークの裏側でどのようなことが行われているのか知る必要がある。●SQLインジェクションWebフォームなどの入力インターフェースを利用してデータベースに発行されるSQLを開発者が意図しない形に変更すること。入力値のチェック(ex.バリデーション)プリペアード・ステートメント(文字列連結などでSQLを組み立てず、WHERE句など条件によって変化する部分をプレースホルダとして登録したSQLを事前に用意しあとからパラメータを割り当てる方法)●クロスサイトスクリプティング(XSS)HTML内に悪意のある動作をするJavaScriptを埋め込む。クッキーの盗難やページの改ざんなどができる。セッションハイジャックなどにつながる恐れがある。→サニタイジング(HTMLの破壊をする文字列を、無害な文字列に変換するなどの処理を行うこと。多くのプレゼンテーション層を扱うフレームワークで同様の機能を備えている。)入力チェック(受け付ける文字列を絞る)→出力時に出力対象に応じてサニタイジングを行うのが理想。●セッションハイジャッククライアントとサーバの間でやり取りされているセッションIDを第三者が盗み取ること。→1、XSS対策2、通信経路の暗号化インターネットを流れる通信は盗聴できるため、通信経路をSSLによって暗号化することが必要になる。利用者がログアウト処理を忘れてしまった場合、セッション・タイムアウトが発生するまでセッションIDも有効なため、セッションIDが盗まれた場合被害を受ける。セッション・タイムアウト時間を短めに設定することでセッションIDが悪用される可能性を低くできる4、セッションIDのランダム化セッションはアプリケーションサーバなどによって実現されているため、開発者が自分で対策することは少ない。セッションの安全性は「セッションIDが十分大きな桁の数字の中からランダムに選択された」という事実によって支えられている。自分で持っておく復号用の鍵を「暗号鍵」と呼ばれる。cf)「SSLアクセラレータ」ー暗号化処理を高速実現している。●クロスサイトリクエストフォージェリ(CSRF)攻撃者が捏造したフォームから強制的にサブミットすることで、掲示板に意図しない書き込みをされたりする攻撃。→1フォーム表示のリクエストがアプリケーションサーバに届いた際に「ワンタイムトークン」を生成2生成したワンタイムトークンを「hiddenパラメータ」に埋め込みフォームを表示3サブミットされた際に、ワンタイムトークンも送られる(→これを照合し、自サーバで生成したものであればサブミットを受け入れる)●コラム「ハッシュ関数」ハッシュ関数とは任意の長さの入力に対して「メッセージダイジェスト」と呼ばれる固定長の値を出力する関数である。情報改ざんの発見ワンタイムトークンなど推測不可能な文字列の生成パスワードの保存などに使用されている●強制ブラウズwebブラウザんぽアドレスバーにURLを直接入力することで本来表示されるべきではない画面を表示させる攻撃である。ログイン状態の確認→ログイン画面の経由をどのような画面にアクセスされても可能としなければならない。ディレクトリのファイル一覧を表示する機能が見えることもある。Digest認証(ダイジェスト認証)・ハッシュ関数を利用して、ユーザー名やパスワードを直接送受信せずに実現する(HTTP通信そのものは暗号化されないためSSL/TLSの利用が必要)・設計/実装ミスに起因する誤作動やセキュリティ問題を防ぐために●「戻る」ボタン対策1、ブラウザによるキャッシュ無効化フレームワークが提供していることも多いので一度確認する。1、jsによる対策ボタンが押されたかを変数に格納し、一度目はfalseで返し二度目以降はtrueで返すなど。・hiddenパラメータは任意の情報をフォームに格納することでリクエストをまたいだ情報の受け渡しを可能としている。これらはWebブラウザから容易にのぞくことができる。そのためログイン中かなどをアプリケーション上の状態を直接保持するなどはしない。→CSRF対策としてのワンタイムトークンを使用する。更新画面等を表示する際にサーバが発行するため、ワンタイムトークンが分からなければ捏造したhiddenパラメータを直接POSTし処理させることは困難になる。連続した攻撃に使えない・ワンタイムトークン捏造することも難しい。●デバッグ情報を出力させないエラー情報をそのままブラウザ出力せずにログファイルなど決められた場所へ出力するなど方針を決めておく▲グローバル変数に情報を持たせないどこからでもアクセスできる可能性のある変数に格納することで想定しなかったユーザに画面を表示してしまう可能性があるJavaのWebアプリケーション>アプリケーションサーバは「スレッド」という仕組みで複数のクライアントからリクエストが来ても同時に実行ができる。サーブレットのインスタンスはリクエストごとに生成されるのではなく、アプリケーションサーバの中で1つだけしか生成されない。そこで表示に使用する情報などをインスタンス変数に保持していると、同時にアクセスしているほかの利用者の情報が誤って表示されてしまう。7はてなブログをはじめよう!fallakiakino_793さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。