1月10日（火）1、2コマ目

今日、やったこと

バッファオーバーフロー

今日のホワイトボード

バッファオーバーフローでリターンアドレス書き換え

前回のつづきです。

前回はサンプルプログラム「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月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のパスワードのハッシュ値と比較します。 図　ソルトを...
続きを読む