1月23日（月）1、2コマ目

今日、やったこと

  • サニタイジング
  • エラーページ
  • フィルター

今日のホワイトボード

サニタイジング

ユーザー入力内容をブラウザに出力する際、HTMLタグが含まれていると、問題が発生することがあります。例えば、<script>タグでJavaScriptが入力されると、JavaScriptを実行することなります。

そこで、出力の際に本来HTMLタグが含まれない箇所にHTMLタグがある場合、HTMLタグとして出力しないようにサニタイジングを行います。

例えば、<script>と入力された場合、<は&lt;へ、>は&gt;に置き換えて出力します。

図　サニタイジング

サニタイジングを自力でやるのはめんどくさいため、Apache Commons Textライブラリを利用しました。


エラーページ

いままではエラーが発生すると、そのまま出力していました。

しかし、これではサーバー情報を公開することになるため、セキュリティ上問題です。

そこで、エラーが発生したらあらかじめ用意したエラーページを表示するようにします。

図　エラーページ


リダイレクトとフォワードの違い

リダイレクトはクライアントがリダイレクト先を改めてリクエストします。よって、クライアントは2回リクエストすることになります。

フォワードはフォワード先をサーバーが読み込み、出力します。そのため、フォワード先は同じアプリケーション内に限定されます。

図　リダイレクトとフォワード


セッションIDを推測しずらくする

セッションIDが漏洩すると、セッションハイジャックにつながります。

セッションID漏洩を防ぐ手段として、前回は

  • 通信経路の暗号化（HTTPSの利用）
  • JavaScriptがCookieにアクセスできないようにする

の２つをあげました。これらに加えて、セッションIDを変更するも重要です。

図　セッションIDを変更する


フィルターを使う

非認証ユーザーが認証ユーザーのみアクセス可能なページをリクエストした際、自動的にログインページを表示するためにフィルターを利用しました。

フィルターはサーブレット（JSPも）より先に実行されます。フィルターで認証済みかチェックし、非認証なら、ログインページを表示します。

図　フィルターで認証済みかチェック


今日のソースコード

今日で完成です。

User.java

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


UserDAO.java

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


Service.java

機能提供クラス。


PasswordUtil.java

パスワードハッシュ化用クラス。


NofFilledException.java

未入力項目がある場合にスローする検査例外クラス。


InvalidPasswordException.java

パスワード要件を満たさない時にスローする検査例外クラス。


IndexSrv.java

起動直後にアクセスする。ログインボタンクリック時の処理。


UserInfoSrv.java

ログイン後、遷移する。ユーザー情報ページをフォワードする。


AuthFilter.java

UserInfoSrvをリクエストした際、認証済みか確認するフィルタ。


index.jsp

ログインページ。


userinfo.jsp

ユーザー情報表示ページ。


error.jsp

エラーページ。


web.xml

アプリケーション設定ファイル。エラーページを指定。


シーケンス

IDを採番するために利用。

図　シーケンス


次回は

課題の時間です。

このブログの人気の投稿

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のパスワードのハッシュ値と比較します。 図　ソルトを...
続きを読む