12月15日(火)2コマ目

今日の予習

アプリケーション構築にあたり、今まで学んできたことをそのまま使うと実は非常にマズいところがあります。なるべくポイントを絞って、簡単なサンプルで、としてきた結果、本来なら知らないとマズいところをスルーしてきました。

ということで、卒業に向けて取りこぼしを一気に回収していきます。

サンプルアプリケーション「ユーザー認証」

ただユーザー認証をするだけです。

[DAO]UserDAOクラス

ユーザーマスタアクセス用クラス。


[Exception]AuthFailureException

認証失敗時にスローする検査例外。


[Exception]InvalidPasswordException

入力されたパスワードがパスワード要件を満たしていないときにスローする検査例外。


[Exception]NotFilledException

未入力の項目がある際にスローされる検査例外。


[Util]PasswordUtilクラス

パスワード、ソルトをハッシュ化するために利用。

階層を横断して利用される。


[BLL]Serviceクラス

機能提供クラス。


[presentaion]IndexSrvクラス

サーブレット。

このアプリケーションのエントリポイント。


[presentation]SecondPageSrvクラス

サーブレット。

2ページ目用のサーブレット。


[presentaion]AuthFilterクラス

サーブレットより前に実行されるフィルタ。

認証済みかチェック。


[presentaion]index.jsp

1ページ目。ユーザー名、パスワードを入力し認証成功から2ページ目へ。

認証失敗ならエラーメッセージ表示


[presentaion]userinfo.jsp

2ページ目。認証に成功した場合、このページで認証済みユーザーの情報が表示される。


[presentaion]error.jsp

エラー発生時に表示される。

web.xmlにてエラー発生時にこのページが表示されるように設定されている。


web.xml

アプリケーションの設定ファイル。

今回はエラーページの設定のみ行っている。

今日、やったこと

認証

今日のホワイトボード

認証について

認証に使える情報は「本人しか持っていないモノ」、「本人しか知らないこと」。

よって、これらの情報が漏洩することは認証システムの崩壊になるため、防がなければならない。

図　認証に使える情報


今まではDBにパスワードを平文のままで格納していたが、もしDB情報が漏洩した場合、非常に危険である。よって、漏洩してもパスワード情報が守られるようにパスワードをハッシュ化して格納するのが一般的。

図　DBにパスワードを平文で保存してはダメ

ハッシュ化

図　ハッシュ化

パスワードをハッシュ化する際、より強固なハッシュ値（推測が困難なハッシュ値）にするためにソルトを追加して文字数を増やし、ストレッチングを行う。いずれも総あたり攻撃に対する対応策。

図　ソルト
パスワードをハッシュ化する際に利用したPasswordUtilクラスを載せときます。




コメント

新しいコメントは書き込めません。

このブログの人気の投稿

1月6日(水)1コマ目

イメージ
今日、やったこと フィルター 今日のホワイトボード 2020年末からのつづきです。「安全なWebアプリケーション構築」というタイトルで、認証を行うアプリケーションを構築してきました。 作成途中のWebアプリケーションをリハビリがてら以下のように改造してもらいました。 図　改造内容 いちおう、ソースコードです。 IndexSrvクラス(サーブレット) doPost()で認証OKなら [改造前]/WEB-INF/userinfo.jspへフォワード [改造後]SecondPageSrvへリダイレクト に改造。これで認証成功ならクライアントはSecondPageSrvへリダイレクトさせられる。 リダイレクト=>クライアントはリダイレクト先を再度リクエストする。 SecondPageSrvクラス(サーブレット) 追加。 doGet()で/WEB-INF/userinfo.jspへフォワード。 クライアントが直接アクセス可能？不可能？ 主にJSPやHTMLファイルですが、どこに置くか(WebContentフォルダかWEB-INFフォルダか） で、ブラウザからアクセスできる、できないのコントロールができます。 図　クライアントが直接アクセス可能？不可能？ WEB-INF以下に置いたJSP(HTMLも)はブラウザから直接アクセスできません。 WEB-INF以下のJSPの表示はサーブレット内でフォワードすることになります。 未ログインならログインページに飛ばしたい ブラウザのアドレスに2ページ目のURL(http://xxx/SecondPageSrv)を入力すると、ログインページを経由せずに2ページ目にアクセスできます。 このような未ログインの状態でログインページ以外をリクエストした場合、ログインページに飛ばしたいです。 これを実現するにはサーブレット実行前に実行されるフィルターを使って、ログイン済みかチェッ...
続きを読む

11月25日(水)1コマ目

イメージ
今日の予習 スレッドに関する内容を扱います。 スレッドのライフライクル スレッドは新規作成から終了まで下図のように状態が変わります。 新規作成 Threadクラスのインスタンス生成された時であり、まだこの時点ではシステム資源（CPU)は割り当てされていません。 実行可能状態 start()メソッドが実行されると新規作成状態から実行可能状態になります。この状態でもまだ処理は行われません。 スレッドには優先順位があり、実行可能状態のスレッドは実行可能キューで順番待ちをしています。順番が回ってくると実行中となります。 実行中 スレッドにシステム資源が割り当てられ、スレッドの処理が実行されている状態です。 「実行中」の遷移先は次の３つに分かれます。 ○より優先順位の高いスレッドが発生したとき 「実行可能状態」へ ○wait()、sleep()メソッドが実行された、入出力等で処理の遅延が発生した、排他制御でロックされたとき 「待ち状態」へ ○処理が完了したとき 「終了」へ 終了 run()メソッド内の処理が終わり、スレッドが消滅した状態や、run()メソッド実行中に例外が発生して途中で終了した状態です。 今日、やったこと バッファオーバーフロー確認テストの解説 今日のホワイトボード 確認テストの解説 先週のページ に解説を載せておきました。こちらもご参考ください。 メモリ プログラム実行のさい、メモリは下表の３つのエリアを使います。 コードエリア 実行する命令が置かれる。 メモリ番地の低位アドレスからエリアが確保される ヒープエリア 大きめのデータ用のエリア。C言語でmalloc()で確保する...
続きを読む

10月14日(水)1コマ目

イメージ
きょう、やったこと バッファオーバーフロー 今日のホワイトボード コンピュータのメモリ とりあえず下図の３つのエリアをおさえてください。 図　コンピュータのメモリ バッファオーバーフロー コンピュータシステムの重大インシデントの要因ナンバーワン（と思われる）がバッファオーバーフロー。C言語特有の「メモリ操作が簡単にできる」＋「メモリ保護がない」から簡単に発生する。いやらしいのは発生するパターンが限定されるケースが多いこと。(再現性が高くない） サンプルプログラムについて （一応）認証を行うプログラム。 コマンドライン引数にて、認証に使うパスワードを指定して実行。 なお、認証OKなパスワードは「SamplePassword」。 しかしながら、パスワード「aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa」（aを30個)を指定すると、認証OKとなる。 原因はバッファオーバーフローによるメモリ破壊。実際にメモリがどうなっているかをデバッガを使って確認してみる。 バッファオバーフローはstrcpy()で発生している デバッガで、strcpy()直後にブレークポイントを設定。 ブレークポイントで停止後、２つの変数(auth_flag、password_buffer)の中身を見てみると、以下のようになっていた。 図　strcpy()後のメモリの様子 おかしな動きをした理由はいくつかの要素が複合的に重なっているためです。 要素１　strcpy() strcpy()は 　 コピー先のサイズに関係なく、コピー元の先頭から'\0'までをコピーする ため、password_bufferのエリアを超えて、auth_flagのエリアまで上書きをしてしまった。 要素2　check()の戻り値 変数auth_flagの値を返しているが、auth_flagは 初期値0で宣言 strcmp()で”SamplePassword”と一致したら、1を代入 の2か所で代入を行っている。 strcpy()でバッファオーバーフローして上書きされても正しい値を代入することがない。 要素3　c言語のif() カッコ内が 　0なら条件不成立 　0以外なら条件成立 です。c言語にはtrue、falseがないため、このような仕様になっています。 よって、check()関数の戻り値が0以外なら認証...
続きを読む