1月19日（木）3、4コマ目

今日、やったこと

  • ハッシュ化されたパスワードを使う
  • 空白チェック（入力チェック）

今日のホワイトボード

セキュアなWebアプリケーション構築のために気を付けなければいけないことをあげていきます。

クライアントからアクセスできる・できない

WEB-INF以下はクライアントから直接アクセスできない。

　http://・・/・・/WEB-INF/index.html => アクセスできない

図　WEB-INF/以下はアクセスできない


セッションオブジェクト取得

getSession()メソッドがあるが、セッションオブジェクトが無い場合の動きは引数の違いで変わる。 

図　getSession()メソッドの違い


入力チェック

可能な限り、クライアント、サーバーの両方で行うこと。

図　未入力チェック

ソースコード

本日作成したソースコードをあげておきます。
まだ、未完成です。

User.java

ユーザー情報受け渡し用クラス。

UserDAO.java

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

Service.java

機能提供クラス。

NotFilledException.java

未入力時にスローする検査例外クラス。

PasswordUtils.java

パスワードをハッシュ化する。

IndexSrv.java

サーブレット。ログインページ用。

index.jsp

ログインページ用JSPファイル。


次回は

つづきです。


このブログの人気の投稿

1月24日（火）1、2コマ目

イメージ
今日、やったこと 課題 今日のホワイトボード 今まで小ネタをいろいろと取り上げました。いちおう、まとめてみました。 図　まとめ１ 図　まとめ２ 図　まとめ３ じかいは 課題の締め切りです。
続きを読む

1月6日（金）1、2コマ目

イメージ
今日、やったこと バッファオーバーフロー 今日のホワイトボード バッファオーバーフローとは バッファオーバーランとも呼ばれる。 メモリ上の確保済みエリアのサイズを超えてデータをコピーすることで、未確保部分にも上書きされること。 図　バッファオーバーフロー バッファオーバーフローはセキュリティインシデントの要因ナンバー1（と思われる）。 そもそもC言語はメモリ保護がないため、簡単に不具合を作ってしまう。 また、バッファーオーバーフローが特定の場合のみ発生するため、テストで露見しにくい。 メモリは コンピュータのメモリはプログラム実行時に以下のように３つのエリアで使い分けられる。 図　メモリ サンプルプログラムでバッファオーバーフロー発生 サンプルプログラム「bof_sample1.c」はstrcpy()でバッファオーバーフローを引き起こし、変数auth_flagの値を書き換えます。 変数auth_flag、password_bufferのアドレス デバッガでプログラム実行中のメモリの状態（auth_flag、password_buffer）を確認します。 図　auth_flag、password_bufferのアドレス auth_flag、password_bufferのアドレスから、メモリ上では以下のように配置されていることがわかります。 図　メモリ上でのauth_flag、password_buffer この位置関係からpassword_bufferからオーバーフローすれば、auth_flagを上書きすることが分かります。 実際にバッファオーバーフローを引き起こしてみます。 バッファオーバーフロー発生時のメモリ[strcpy()前] メモリは以下のとおり。 図　auth_flag、password_bufferのアドレス 図　strcpy()前のメモリ password_bufferは初期化していないため、ゴミがあります。 auth_flagは0で初期化しているため、0です。（当然） バッファオーバーフローでのメモリ[strcpy()後] strcpy()で引数passwordの値を配列password_bufferにコピーすると、バッファーオーバーフローが発生します。 図　auth_flag、password_bufferのアドレス 図　strcpy()後のau...
続きを読む

1月17日（火）1、2コマ目

イメージ
今日の予習 パスワードを平文でDBに保存すると、DBからデータが漏洩した場合、パスワード漏洩につながる。 もし、DBからデータが漏洩しても、パスワード漏洩にならないようにするために、パスワードは平文ではなく、ハッシュ化して保存するのが一般的。 パスワードをハッシュ化するためのPasswordUtilクラスをあげておきます。 PasswordUtil.java   今日の予習 パスワードをハッシュ化  入力チェック 今日のホワイトボード セキュアなWebアプリケーションを構築するために守るべきルールを紹介します。  ユーザー認証 ユーザー認証にはパスワードが使われますが、パスワード以外にもユーザー認証に利用できるモノがあります。 図　ユーザー認証に使えるモノ いずれも本人しか・・なモノです。 パスワードの取り扱い 今まではDBにパスワードを平文で保存してきましたが、セキュリティ上問題ありです。 今後はパスワードをハッシュ化して保存します。 図　今までの問題点 ハッシュ化 暗号化と似てますが、 暗号化は暗号文を復号可能 ハッシュ化はハッシュ値をもとに戻せない の違いがあります。（不可逆性） 図　ハッシュ化 ハッシュ化されたパスワードで認証 DBにはハッシュ化されたパスワードを格納します。これは元のパスワードに戻すことができません。 ハッシュ化は同じ文字列を同じハッシュ関数でハッシュ化すると常に同じハッシュ値が取得できます。よって、入力されたパスワードをハッシュ化し、DBのハッシュ値と比較して認証します。 図　ハッシュ化されたパスワードで認証 ソルト ハッシュ化の際、文字列長が長いほどハッシュ値の推測が困難になります。そこで、パスワードにソルトと呼ばれる文字列を追加して文字列長を長くします。 また、パスワードが同じでもソルトが異なれば、ハッシュ値も代わり、パスワードの推測も困難になります。 図　ソルトを使ってハッシュ化 パスワード＋ソルトでハッシュ化での認証 各ユーザーはパスワードをハッシュ化する際、別々のソルトを使います。 そのため、DBには各ユーザーが利用したソルトも保存します。 認証の際は、入力されたパスワード＋DBから取得したソルトでハッシュ値を求め、DBのパスワードのハッシュ値と比較します。 図　ソルトを...
続きを読む