1月11日(木)1、2コマ目

今日、やったこと

  • 入力チェック
  • セッションオブジェクト、セッションID

今日のホワイトボード

入力チェックが必要なわけ

下図のように変な値が入力されるとプログラムが停まるから入力チェックをするわけではない。（当然このような場合の入力チェックも必要）

図　入力チェックが必要なケース

下図のように入力される内容によっては重大なインシデント発生につながることを防ぐために入力チェックを行う。

図　入力チェックが必要なケース(SQLインジェクションが発生する)


空白チェック用メソッド

JavaのStringクラスにはisEmpty()やisBlank()があるが、いずれもインスタンスメソッド。

変数がnullの場合はNullPointerExceptionをスローする。よって、まずnullチェックが必要。

StringUtilsクラスのisEmpty()やisBlank()はクラスメソッド。チェック対象がnullならfalseを返すだけ。

図　空白チェック用メソッド

入力チェックで正規表現を使う

StringUtilsクラスのisXXX()メソッドには以下のようなメソッドが用意されている。
メソッド 役割
isAlpha() アルファベット(大文字・小文字)以外を含むとfalse
isNumeric() 数字以外を含むとfalse
isAlphanumeric() アルファベット(大文字・小文字)、数字以外を含むとfalse

これらのメソッドでチェックできない場合は正規表現を使う。
図　正規表現のパターン

パスワード要件は半角数字、英字(大文字・小文字)、記号を4文字以上。
記号が厄介。
文字は結局ASCIIコードに従って数値化される。よって記号もASCIIコード表を見れば、数字やアルファベットと同じように範囲で指定できる。
ただし、正規表現の機能が割り当てられている[や{はそのまま書くとNG。
本来の[や{として評価するには正規表現の機能をエスケープさせる必要がある。
正規表現の機能をエスケープするには\を使う。ただ、\自体も昨日が割り当てられているので、\\と書く必要がある。
図　半角数字、英字(大文字・小文字)、記号を4文字以上を正規表現で表す

セッションオブジェクト、セッションID

サーバー側で各クライアント毎に用意されるセッションオブジェクトを正しいクライアントと紐づけるためにサーバー側、クライアント側でセッションIDを共有している。
クライアント側はサーバーから渡されたセッションIDをCookie(クッキーと呼ぶ)に保存する。
図　セッションID、セッションオブジェクト
クライアントはサーバーにリクエストする際、Cookieも一緒に送信する。サーバーは受け取ったCookieからセッションIDを取得し、紐づけるセッションオブジェクトを探す。

セッションハイジャック

クライアントとサーバーでやり取りされるセッションIDは盗聴可能。
悪意を持った人がセッションIDを盗聴し、自分のブラウザに組み込めば(これも簡単)、他人のセッションを横取りできる。これをセッションハイジャックと呼ぶ。
図　セッションハイジャック
セッションハイジャックで他人のAmazonにログイン中のセッションを横取りすれば、他人の支払いでほしいモノを買うことができる。

HttpServletRequestのgetSession()

セッションオブジェクトを取得するためのgetSession()は引数違いで3パターンの呼び出しがある。
図　getSession()メソッド
ポイントはセッションオブジェクトがないときの振る舞い。
getSession()、getSession(true)は新規セッションオブジェクトを生成して返す。
getSession(false)だけnullを返す。
必要に応じて使い分けること。

今日のソースコード

昨日からの差分をあげておきます。

[exceptionパッケージ]NotFilledExceptionクラス

おなじみの未入力時にスローする検査例外クラス。

[exceptionパッケージ]InvalidPasswordExceptionクラス

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

[daoパッケージ]UserDAOクラス

変更なし

[bllパッケージ]Serviceクラス

変更なし

[bllパッケージ]PasswordUtilクラス

変更なし

[presentationパッケージ]IndexSrvクラス

入力チェックを追加。
認証成功後、セッションIDを変更。

[JSPページ]index.jsp

ユーザー名、パスワード入力用<input>タグに"required"属性追加=>未入力時にエラー表示。

次回は

サニタイジングとフィルタを追加。





 

このブログの人気の投稿

1月12日(金)1、2コマ目

イメージ
今日、やったこと エラーページ フィルター 今日のホワイトボード エラーページ 例外スローの結果、エラーページをそのまま出力すると危険。 このエラーページには サーバーの種類(Tomcat)、バージョン プログラミング言語 DBの種類 等、色々な情報が含まれるため危険。 catchブロックを用意して、そのなかでエラーページを表示するようにすればいいが、Javaサーブレットにもデフォルトのエラーページを設定することができる。 図　エラーページの設定 ①設定ファイルweb.xmlを設定 エラーの種類（HTTPのステータスコード別、Javaの例外別）、エラーページが設定できる。 ②エラーページ作成 HTMLだけでなく、JSPも可。 なお、JSPでは暗黙オブジェクトexceptionが使える。exceptionはスローされた例外。 ただ、exceptionを使うにはエラーページであることを指定する必要あり。 エラーページへの遷移はフォワードで行われる。 よって、エラーページをWEB-INF/以下に置くことも可。 リダイレクトとフォワード いずれもページ遷移の仕組みだが、以下の違いがある。 フォワードはサーバー内で遷移先ページを読み込みクライアントへ返す=>1往復 リダイレクトはステータスコード302をクライアントに返して、クライアントが再リクエスト=>2往復 図　フォワードは1往復で遷移 図　リダイレクトは2往復で遷移 認証成功後のページ追加 認証に成功するとユーザー情報を表示する。流れは下図のようになる。 ...
続きを読む

1月29日(月)3、4コマ目

イメージ
今日、やったこと [やってみよう]バッファオーバーフロー 確認テスト 今日のホワイトボード [やってみよう]バッファオーバーフローその１ hasUpperCase()関数にはバッファオーバーフローの脆弱性がある。(13行目) main()関数にてhasUpperCase()を呼び出したときにスタック上に書き込まれるリターンアドレスを43行目のprintf()に書き換える。 プログラムの動き main()関数を逆アッセンブルすると以下のようになる。 図　main()を逆アッセンブルすると 通常はhasUpperCase()実行後、0x7f…400786番地に戻ってくるが、printf()実行の0x7f…4007aa番地に戻るようにスタックエリア上のリターンアドレスを書き換えればいい。 メモリの様子 hasUpperCase()実行時のスタックエリアの様子は以下のとおり。 図　hasUpperCase()実行時のメモリの様子 変数buffの先頭から40バイト離れた(41バイト目以降)ところにリターンアドレスが書き込まれている。ここをバッファオーバーフローで書き換える。 どうすればいい？ どんな引数でもかならず”I DO NOT find UpperCase!”と出力するには、コマンドライン引数に40文字＋リターンアドレスで実行すればいい。 [やってみよう]バッファオーバーフローその２ chkString()関数にはバッファオーバーフローの脆弱性がある。(23行目) main()関数にてchkString()を呼び出したときにスタック上に書き込まれるリターンアドレスを77行目のprintf()に書き換える。 プログラムの動き main()関数を逆アッセンブルすると以下のようになっている。 図　main()関数を逆アッセンブルすると 通常はchkString()実行後、0x7f…4007e2番地に戻ってくるが、printf()実行の0x7f…400817番地に戻るようにスタックエリア上のリターンアドレスを書き換えればいい。 メモリの様子 chkString()実行時のスタックエリアの様子は以下のとおり。 図　chkString()実行時のメモリの様子 その１と同じように変数buffの先頭から41バイト目にリターンアドレスが書き込まれる。ここを書き換えればいい。 どうすればい...
続きを読む

1月9日(火)1、2コマ目

イメージ
今日、やったこと パスワードのハッシュ化 今日のホワイトボード ユーザー認証 ユーザー認証はパスワードが使われるケースが多いが、パスワード以外にもユーザー認証に使えるモノがある。 図　認証に使えるモノ ポイントは「本人しか」。 パスワードの取り扱い 今までは便宜上DBにパスワードを平文で保存していた。が、これは一般的にはありえない話。本来はDB上のデータが漏洩しても即セキュリティインシデントにつながらないようにしなければならない。 図　パスワードの取り扱い 一般的にはパスワードをハッシュ化してDBに保存する。 ハッシュ化 ハッシュ化と暗号化は同じように元の平文が推測しずらい点では一緒。暗号化は元の平文に複合できるが、ハッシュ化された文字列を元の平文に戻すことはできない。 厳密に言えば、できないわけではないが、総当たり攻撃や辞書攻撃になるため、かなり長い時間がかかる。  図　ハッシュ化 ハッシュ化ソースコード PasswordUtil.java 文字列+ソルトをアルゴリズムSHA256で10,000回ハッシュ化してハッシュ値を生成する。 Main.java PasswordUtilクラスを使ってパスワード＋ソルトのハッシュ値を生成させる。 ソルトは実行時の現在時刻のナノ秒部を利用。 ハッシュ化されたパスワードで認証するには DBにハッシュ化されたパスワードを保存する場合、認証は入力されたパスワードのハッシュ値とDBのハッシュ値を比較することになる。 図　ハッシュ化されたパスワードで...
続きを読む