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

今日、やったこと サニタイジング エラーページ フィルター 今日のホワイトボード サニタイジング ユーザー入力内容をブラウザに出力する際、HTMLタグが含まれていると、問題が発生することがあります。例えば、<script>タグでJavaScriptが入力されると、JavaScriptを実行することなります。 そこで、出力の際に本来HTMLタグが含まれない箇所にHTMLタグがある場合、HTMLタグとして出力しないようにサニタイジングを行います。 例えば、<script>と入力された場合、<は&lt;へ、>は&gt;に置き換えて出力します。 図　サニタイジング サニタイジングを自力でやるのはめんどくさいため、Apache Commons Textライブラリを利用しました。 エラーページ いままではエラーが発生すると、そのまま出力していました。 しかし、これではサーバー情報を公開することになるため、セキュリティ上問題です。 そこで、エラーが発生したらあらかじめ用意したエラーページを表示するようにします。 図　エラーページ リダイレクトとフォワードの違い リダイレクトはクライアントがリダイレクト先を改めてリクエストします。よって、クライアントは2回リクエストすることになります。 フォワードはフォワード先をサーバーが読み込み、出力します。そのため、フォワード先は同じアプリケーション内に限定されます。 図　リダイレクトとフォワード セッションIDを推測しずらくする セッションIDが漏洩すると、セッションハイジャックにつながります。 セッションID漏洩を防ぐ手段として、前回は 通信経路の暗号化（HTTPSの利用） JavaScr...

今日、やったこと 正規表現 セッション 今日のホワイトボード 正規表現 入力チェック等でパターン比較するときに使います。 図　正規表現 記号を指定する際は、正規表現の機能が与えられている記号([や{など）はエスケープシーケンス\\で正規表現の機能をキャンセルさせる必要があります。 図　記号はエスケープシーケンスが必要なモノがある セッション サーバーはクライアントを識別するためにセッションIDを生成し、クライアントと共有している。 サーバー側でクライアント毎に用意されるセッションオブジェクトは、クライアントから送信されるセッションIDを使って識別している。 クライアントはサーバーから渡されたセッションIDをブラウザのCookieに保存している。 図　セッション セッションハイジャック 盗聴やクロスサイトスクリプティングで他人のセッションIDを取得すれば、他人のセッションを横取りすることができる。これをセッションハイジャックと呼ぶ。 セッションハイジャックを防ぐには以下を行うこと。 　盗聴対策・・通信経路は暗号化。HTTPSを使う。 　JavaScriptからCookieにアクセスできないようにする・・HttpOnly属性をオン。（デフォルト） ソースコード 今日までのソースコードです。 User.java 変更なし。 UserDAO.java ユーザー情報取得用のfindUserByLoginUserName()メソッドを追加。 ...

今日、やったこと ハッシュ化されたパスワードを使う 空白チェック（入力チェック） 今日のホワイトボード セキュアな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ファイル。 次回は つづきです。

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

今日、やったこと バッファオーバーフロー 今日のホワイトボード バッファオーバーフローでリターンアドレス書き換え 前回のつづきです。 前回はサンプルプログラム「bof_sample2.c」を使って、関数呼び出しの際、呼び出し元に戻れるようにスタック上にリターンアドレスを記録すると解説をしました。 今日は実際にスタック上のリターンアドレスを書き換えてみます。 図　コマンドライン引数でリターンアドレスを書き換える strcpy()でバッファオーバーフローした結果、リターンアドレスを書き換えるには、コマンドライン引数が40バイト＋リターンアドレスで可能になります。 今回は、コマンドライン引数をperl(スクリプト言語の1種)で生成しています。 バッファオーバーフローをやってみよう　その1 サンプルプログラム「bof_sample3.c」でバッファオーバーフローを引き起こし、通常とは異なる動きをさせます。 基本的には「bof_sample2.c」と同じです。 図　やってみよう　その1　スタックエリアとコードエリア バッファオーバーフローの脆弱性をついて、リターンアドレスを下図のように書き換えます。 図　やってみよう　その1　リターンアドレス書き換え後 バッファオーバーフローをやってみよう　その2 サンプルプログラム「bof_sample4.c」でバッファオーバーフローを引き起こし、通常とは異なる動きをさせます。 こちらも基本的には「bof_sample2.c」と同じです。 図　やってみよう　その2　スタックエリアとコードエリア バッファオーバーフローの脆弱性をついて、リターンアドレスを下図のように書き換えます。 図　やってみよう　その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...