セキュアプログラミング実習 2020年度後期(2年)

今日、やったこと 「安全なWebアプリケーション構築」（セッション、サニタイジング） 今日のホワイトボード （くどいけど）セッションオブジェクトとセッションID サーバー側のセッションオブジェクトはセッションIDでどのクライアント用かを識別している。 クライアント側はサーバーにリクエストするときにセッションIDを送信することで、サーバーはクライアントを識別している。 クライアントはこのセッションIDを一般的にはWebブラウザのCookieに保存している。 ここで、 クライアントがサーバーにセッションIDを送信する=>盗聴されるとセッションハイジャックされる。 クライアントはセッションIDをCookieに保存する=>JavaScriptで読み書き可能、クロスサイトスクリプティングで読み込まれる可能性あり。 の危険がある。 図　セッションオブジェクトとセッションID [対策]ログイン後はセッションを破棄、再開 セッションIDを盗まれることを前提にすると、 同じセッションIDを使い続けないほうがいい 。 よって、ログイン後はセッションをいったん破棄して、その後再開することで、セッションIDを変更する。 図　セッションIDに係るマズいことと対策 図　セッション破棄、再開でセッションIDを変更する JSPに出力する DBから取得した内容をそのまま出力するのは危険。 たとえば、DBが以下のようになっていると ID ログイン名 表示名 パスワード ソルト 2 jiro <H1>ジロウ</H1> ・・ ・・ ...

今日、やったこと 「安全なWebサイト」構築（入力チェック） 今日のホワイトボード 入力チェック「どこで、どうやる？」 クライアント側とサーバー側の両方で行うこと。 〇クライアント側 HTML5やJavaScriptを使うと結構いろいろできる。 〇サーバー側 java.lang.Stringクラスだけではちょっとめんどくさい。 「Apache Commons Lang」ライブラリのStringUtilsクラスが便利。 ただし、 ライブラリをダウンロード、プロジェクトに追加する必要あり。 図　入力チェック「どこで、どうやる？」 入力チェック「チェックする目的は？」 基本的には入力内容が仕様に合うかどうかをチェックする。 入力チェックをする目的は単に「数値入力用フォームに文字が入力されたか」をチェックするだけではなく、 セキュリティ的な問題を発生させない 目的もある。 図　入力チェック「チェックポリシー」 入力チェック「入力パターンでチェック」 電話番号やメールアドレス入力用フォームには、入力内容が電話番号やメールアドレスであることをチェックする必要がある。 電話番号やメールアドレスはパターンがありそのパターンは 正規表現 で表すことができる。 正規表現でアルファベットの小文字は[a-z]で表すことができる。これは文字'a'から'z'をエンコードすると0x61('a')から0x7a('z')と順に並んでいるため、範囲として表現できる。 図　文字とエンコードされた値の関係 図　正規表現の例 ...

今日、やったこと DBにハッシュ化されたパスワード、ソルトを格納 DBアクセスを行い、認証を行う 「安全なWebアプリケーション構築(Java版)」実装開始 今日のホワイトボード 認証のながれ DBのパスワード情報はハッシュ化されているため、今までとは異なるので注意。 図　認証処理のながれ 今後は まずは「安全なWebアプリケーション構築(Java版)」の”入力パスワードがパスワード要件を満たしていない”以外を実装してください。 これをベースに話をしていきます。

今日の予習 アプリケーション構築にあたり、今まで学んできたことをそのまま使うと実は非常にマズいところがあります。なるべくポイントを絞って、簡単なサンプルで、としてきた結果、本来なら知らないとマズいところをスルーしてきました。 ということで、卒業に向けて取りこぼしを一気に回収していきます。 サンプルアプリケーション「ユーザー認証」 ただユーザー認証をするだけです。 [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 アプリケーションの設定ファイル。 今回はエラーページの設定のみ行っている。 今日、やったこ...

今日、やったこと スレッドの確認テスト セッション、セッションハイジャック 今日の確認テスト スレッドセーフとは「マルチスレッド環境で複数スレッドで同時に実行されても問題ない」です。 変数に注目すると ローカル変数はメソッド呼び出し毎にスタック上にエリアを確保するため、問題なし。 フィールドはインスタンス生成時にヒープ領域にエリアを確保するため、同じインスタンスから生成したスレッド間では共有する。よって、スレッドセーフではない。 クラス変数はクラスロード時にエリアを確保するため、全インスタンスでエリアを共有する。よって、スレッドセーフではない。 です。 問１ ソースコードは以下です。 １インスタンスから２つスレッドを生成しています。よって、フィールドvalを共有することになります。 問２ ソースコードは以下です。 1インスタンスから２つスレッドを生成しています。が、ローカル変数だけなので、スレッドセーフではない変数はありません。 問３ ソースコードは以下です。 1インスタンスから２つスレッドを生成しています。 クラス変数diffをスレッド間で共有することなります。が、finalがついているため、実質定数です。（初期値２が代入された後は変更不可能） よって、diffはスレッドセーフかどうかを考える必要はないです。 今日のホワイトボード まず、セッションとは Webアプリケーション等で利用者が目的を達成するために利用者(クライアント)とサーバー間の一連のやり取りで１つのセッション。データベースのトランザクションと同じような感じ。 図　そもそもセッションとは Webでセッションを 1セッションにはクライアントとサーバー間で複数回のやり取りが行われる。 が、WebのプロトコルHTTPは1往復のやり取りで完結。複数回のやり取りでデータを共有する仕組みもない。 ...

今日、やったこと Javaのスレッドと各変数 前回は サンプルプログラム「ThreadTest1.java」を使って、 各スレッド間でクラスメソッド内のローカル変数は共有しないか？ を確認しました。 結論から ローカル変数はメソッド呼び出し時にスタックエリア上にエリアが確保される。 このスタックエリア上に確保されたエリアはメソッド終了時に開放される。 です。よって、クラスメソッドだろうが、インスタンスメソッドだろうが メソッド内で宣言したローカル変数はマルチスレッド環境でもスレッド間で共有することはない です。 図　1インスタンス=>2スレッド、クラスメソッド内のローカル変数は共有する？ 今日のホワイトボード スレッド間でフィールドは共有する？① サンプルプログラム「ThreadTest2.java」で確認です。 実行するとフィールドinsSumはスレッド間で共有されていることがよくわかりました。 このプログラムのフィールドとスレッドの関係は図のとおりで、 同じインスタンスから生成されたスレッド同士ではフィールドを共有します 。 図　1インスタンス=>2スレッド、フィールドは共有する？ このような場合は、スレッド間でフィールドの上書き問題が発生します。通常のフィールドと同じ感覚で使うと危険です。 スレッド間でフィールドは共有する？② サンプルプログラム「ThreadTest2_5.java」で確認です。ぱっと見「ThreadTest2.java」に似ています。 しかし、実行するとフィールドinsSumはスレッド間で共有されていません。 プログラムをよく見ると、main()ないでインスタンスを2つ生成し、各インスタンスからスレッドを起動しています。 結局、スレッドが参照するインスタンスは別々になるため、フィールドを共有することはありません。 ...