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

今日、やったこと クロスサイトスクリプティング 今日のホワイトボード クロスサイトスクリプティング JavaScrtipはCookie中のセッションIDにアクセスできるか？ Cookie中のセッションIDはHttpOnly属性がONになっているため、JavaScriptからはアクセスできない。 図　JavaScriptはCookie中のセッションIDにアクセスできない クロスサイトスクリプティング対策 ユーザー入力データのような安全が保障されていないデータをそのまま出力していることが問題。何が書き込まれているかわからないデータはそのままブラウザに出力せず、HTMLタグを無効化するサニタイジングを行うこと。 図　クロスサイトスクリプティング対策

今日、やったこと エラーページ まとめ 今日のホワイトボード 例外がスローされると 今まで、検査例外、実行時例外いずれも キャッチする目的がないなら、キャッチせずに上位にスロー を基本ポリシーにしていました。 ただ、このままでは最終的にはエラーページ（スタックトレース画面）が表示されます。 このスタックトレース画面にはシステム構成に係る内容がふくまれることがあるため、そのまま表示することはセキュリティ的に問題があります。 図　エラー出力時 エラーページを設定する エラーが発生したら指定されたエラーページを表示する仕組みが用意されています。この仕組みを使ってスタックトレース画面を出力しないようにします。 図　エラーページと設定ファイル「web.xml」  まとめ Webアプリケーション作成時に実行すべき内容をまとめました。 入力チェック かならずチェックすること。基本的に「利用者はセキュリティ的に問題のある入力をする」が大前提。 Cookie Webブラウザがデータを保存する仕組み。 図　まとめ① 出力の無害化（サニタイジング） ユーザー入力内容やデータベースから取得したデータをそのまま出力しない。 HTMLタグはHTMLタグとして出力しない。 ユーザーの権限に応じたページを出力 未認証ユーザーが認証済みユーザーページに直接アクセスすることができないようすること。 図　まとめ② 課題 締め切りは1月19日（火）の2コマ目終了時 にします。

今日、やったこと フィルター 今日のホワイトボード 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ページ目にアクセスできます。 このような未ログインの状態でログインページ以外をリクエストした場合、ログインページに飛ばしたいです。 これを実現するにはサーブレット実行前に実行されるフィルターを使って、ログイン済みかチェッ...

今日、やったこと 「安全な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版)」の”入力パスワードがパスワード要件を満たしていない”以外を実装してください。 これをベースに話をしていきます。