2月19日(木)2コマ目

今日、やったこと

 Spring Securityで認証アプリケーション作成(前回からのつづき)

今日のホワイトボード

前回は

前回はSEC_商品マスタテーブルにアクセスするために

  • Item.java
  • ItemRepository.java
  • application.properties

を作成した。


商品一覧を表示する

商品一覧ページを表示するために以下を追加。

controller/ItemController.java

クライアントからのリクエストを受け付けて、処理を行い、ビューを返す。


index.html

このアプリケーションのトップページ。商品一覧を表示する。


実行すると

とくになにも設定していないため、全ページが認証対象になる。

Spring Securityの認証画面が表示される。

図　トップページにアクセスすると認証画面に

ユーザー情報はなにも登録していないため、Spring securityのデフォルトのユーザー"user"でログイン。パスワードもSpring Securityが生成して、コンソールに表示される。

図　ユーザーは"user"、パスワードを入力してログイン

認証に成功するとトップ画面が表示される。
図　認証成功 -> トップ画面表示

認証に失敗すると、エラー表示。
図　認証失敗 -> エラーメッセージ表示

認証不要画面、認証必要画面をわける

トップページは認証不要。
新規登録画面に進むには認証が必要に変更。
図　認証必要画面、認証不要画面

認証不要・必要はコントローラ実行前に実行されるフィルタでおこなう。
図　フィルタ

以下を追加。

config/securityFilterChain.java

認証必要・不要を切り分けるフィルタクラス。

controller/ItemController.java

トップページの”登録”リンククリック時、登録画面の"戻る"リンククリック時の処理を追加。

templates/index.html

トップページ。
”登録”リンクを追加。

templates/create.html

新規登録画面。
"戻る"リンクをクリックすると、トップページへ。

"戻る"リンククリック時はトップページにリダイレクト。
リダイレクトはHTTPの機能をつかったページ遷移方法。
フォワードはサーバーアプリケーション側でページ遷移する方法。
図　ページ遷移（リダイレクト、フォワード）

実行すると

①トップページリクエスト

トップページは認証不要。
図　トップページリクエスト

②"登録"リンククリック

新規登録画面を表示するには認証が必要。認証画面が表示される。
図　"登録"リンククリック -> 認証画面へ

認証に成功すると、新規登録画面が表示される。
図　認証成功 -> 新規登録画面表示

③"戻る"リンククリック

新規登録画面の”戻る”リンクをクリックすると、トップページへリダイレクトされる。
図　"戻る"リンククリック -> トップページへリダイレクト

次回は

つづき。完成させます。









認証はSpring Security


このブログの人気の投稿

1月13日(火)3コマ目

イメージ
今日、やったこと バッファオーバーフロー2（戻りアドレス書き換え） 今日のホワイトボード 前回はバッファオーバーフローの脆弱性を使って、関数の戻り値を変更した。 今回はバッファオーバーフローの脆弱性を使って、関数の戻りアドレスを変更する。 そもそもプログラムは コンパイルしてできた実行ファイルはメモリ上のコードエリアにロードされる。 関数を呼び出すと、コードエリアにロードされた命令を1つずつ、順に実行していく。 関数内の変数や引数のためのエリアは、関数呼び出し時にスタックエリア上に確保される。 サンプルプログラム２を実行する 前回のサンプルプログラム１の問題点を修正したサンプルプログラム２を実行する。 コマンドライン引数は、バッファオーバーフローが発生して、変数auth_flagのエリアを上書きしてしまう”12345678901234567890123456789"。 〇strcpy()実行前 変数auth_flagと配列pass_buffの位置を確認。 図　strcpy()実行後 〇return auth_flag実行前 前回のプログラムでは、変数auth_flagが上書きされているが、プログラムを修正したため、0になっている。 図　return auth_flag実行前 プログラムの実行コードを確認 デバッガのdisasコマンドを使って、実行ファイルからmain()関数をアセンブラに変換。 図　disasコマンドでアセンブラに変換 check()関数を呼び出す、main()関数に戻る 関数を呼び出す＝関数がロードされている位置から実行する。 アセンブラで確認すると、main()関数でcheck()関数の呼び出すと、callqコマンドでcheck()関数がロードされているアドレスに移動している。 check()関数の実行が終わると、再びcallqコマンドの次のコマンドから順に実行する。 ここに戻ってこれるように、スタックエリアに戻るべきアドレス番地が記録されている。 これが戻りアドレス。 図　check()関数呼び出し、main()関数に戻る 戻りアドレスを書き換える main()関数にて、check()関数の戻り値に関わらず、下図のように別に位置から実行させたい。 図　check()関数から戻る位置を変える check()関数から戻る位置 下図のように...
続きを読む

2月2日(月)4コマ目

イメージ
今日、やったこと [Webアプリケーションのセキュリティ]Cookie 今日のホワイトボード 前回までに作成したxss検証用サイトアプリケーションを使って、Webアプリケーション構築時に知っておかなければならない、セキュリティ知識を紹介。 座学メインで進めます。眠い、つまらん、ダルいと思いますが、最後に紙のテストをしますので、しっかり理解をしてください。 Cookieとは クライアント(Webブラウザ)がデータを保存する仕組み。 サーバーから Set-cookie で送信されたデータを保存する。 クライアントはサーバーにリクエストする際、Cookie保存データを送信する。 図　クライアントがCookieを保存する、サーバーに送信する SessionオブジェクトとCookie 〇Sessionオブジェクト Webアプリケーションにおいて、リクエストを跨いでデータを共有できるのが、Sessionオブジェクト。 Sessionオブジェクトはクライアント毎に生成し、ユニークなセッションIDで識別する。 〇セッションID クライアントとサーバー間で同じセッションIDを保持し、クラインとはサーバーにリクエスト送信する際に、セッションIDを送信することで、サーバー側はクライアントのセッションオブジェクトを識別している。 図　セッションオブジェクトとセッションID 〇クライアントのセッションID保存先 クライアントのセッションID保存先はCookie。 サーバーがセッション開始後、クライアントにset-cookieでセッションIDを送信。 図　セッションIDをset-cookieで送信 クライアント側で、Cookieは簡単に書き換えできる。 CookieのセッションIDを書き換えて、他人のセッションを乗っ取ることもできる。（セッションハイジャック） クライアントはサーバーにCookieを送信する(Domain属性) クライアントはサーバーにリクエスト送信する際、Cookieを送信する。 が、なんでもかんでも送るわけではない。 CookieのDomain属性がリクエスト先のサーバー名と一致するなら送信。 図　CookieのDomain属性とリクエスト先サーバー名が一致するなら送信 Domain属性とリクエスト先サーバー名が一致する、しないは 後方一致 で判断。 ”後方一致する”を簡単...
続きを読む

2月10日(火)3コマ目

イメージ
今日、やったこと クロスサイトスクリプティング(XSS) 今日のホワイトボード クロスサイトスクリプティング(XSS) スクリプトがいつ、どこで埋め込まれるかで3種類に分類される。 サーバー側で埋め込まれるのは、反射型と蓄積型。 反射型はリクエストするURLにスクリプトが含まれる。 蓄積型はスクリプトはサーバー側に保存されている。 クライアント側で埋め込まれるのは、DOM-base型。 図　3種類のクロスサイトスクリプティング クロスサイトスクリプティングを防ぐには ブラウザにHTMLとして認識されないように、<や>をそのままブラウザに送らない。 この置き換えを サニタイジング と呼ぶ。 図　サニタイジング ユーザーが入力したデータを出力する際は、サニタイジングを行う。 次回は Webのセキュリティの残り（SQLインジェクション、その他） 次々回に紙のテストをします。 
続きを読む