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

今日、やったこと XSS検証用サイト作成 今日のホワイトボード 前回は投稿内容を一覧表示するまで作成。 投稿を検索 GETコマンドでパス/searchをリクエストすれば検索できるように作成。 検索条件はクエリパラメータで送信。 図　検索のながれ index.html 検索条件を入力する<input>タグと検索ボタンを<form></form>内に追加。 MessageController.java @GetMapping()で、パスとメソッドを紐づけ。 @RequestParamで、クエリパラメータを引数に代入する。 検索結果の表示は、一覧表示の仕組みを使って表示。（検索のための追加処理なし） ログイン、ログオフ ポイントは同じPOSTメソッド、同じパス(/auth)で、リクエストするボタンが2つ（ログイン、ログオフ）あるところ。 コントローラ側は押されたボタンで、ログイン、ログオフ処理を呼び分ける必要がある。 図　ログイン、ログオフのビューとコントローラ index.html <form>内にボタンが２つあるが、コントローラがどちらが押されたか判断できるように、name属性を指定。 MessageController.java ログイン、ログオフ用メソッドの@PostMapping()にて、param属性に押されたボタンのname属性値を指定。この値で2つのメソッドの呼び分けをしている。 次回は 認証処理を完成させ、投稿機能を追加。  

今日、やったこと [確認テスト　解説]バッファオーバーフロー XSS検証用サイト作成 今日のホワイトボード [確認テスト　解説]バッファオーバーフロー 設問１ 配列buffの先頭アドレスはデバッガで、 ①配列buff宣言後にブレークポイントセット ②実行 ③ブレークポイントで停止したら、xコマンドで確認 でわかる。  図　配列buffの先頭アドレス 設問２ getgenre()関数からのリターンアドレスは、getgenre()呼び出しのあたりのアセンブラを確認するとわかる。 図　getgenre()呼び出しあたりのアセンブラ 配列buffはアドレス0x7f・・0番地から始まっていない点に注意！！ デバッガで確認すると、以下のように、左端は0番地ではない。 図　デバッガで確認すると 解答欄は左端が0番地、右端がf番地になるように解答してほしい。 図　正解のメモリマップ ここを間違って解答している方が多かった。 設問３ ”総記”や”哲学”の表示（prinf()呼び出し）がメモリ上のどこにロードされているかは、disasコマンドでアセンブラにして確認。 図　printf()呼び出し部分 同じ処理を行っているため、アセンブラも同じ。12バイトごとにprintf()呼び出しがある。 設問４ 設問２のメモリマップから、配列buffの先頭から13バイト目にリターンアドレスがあることが分かる...

今日、やったこと [確認テスト]バッファオーバーフロー 今日のホワイトボード 結局、確認テストだけで終わってしまった。 次回は 確認テストの解説。 つくりかけの掲示板サイトのつづき。 

今日、やったこと [確認テストもどき]バッファオーバーフロー１ XSS検証用サイト作成  今日のホワイトボード [確認テストもどき]バッファオーバーフロー１ 解答用紙に正解がくっついていたが、別の内容だった。確認が甘くてすいません。 一番ポイントになる設問3、4は下図のようになる。 図　設問３（左側）、設問4（右側） XSS検証用サイト作成  Webアプリケーション構築によく使われるSpringBootとテンプレートエンジン(Razorページと同じようなモノ）のThymeleafを使って、XSSを検証するためのWebアプリケーションを作成。 REST APIと異なり、サーバー側で完結する。 [dto]User.java ユーザー情報受け渡し用クラス。 アノテーション 役割 @Data フィールドのsetter、getterを生成。フィールドを使ったtoString()も生成。 @AllArgsConstructor 引数で全フィールドを初期化するコンストラクタを生成。 [dto]Message.java 投稿メッセージ受け渡し用クラス。 Userクラスと同じように、アノテーションを使って、setter、getter、コンストラクタを生成。 [controller]MessageController.java コントローラークラス。 クライアントからのリクエストを受け付け、処理を行い、ビューを返す。 アノテーション 役割 @Controller コントローラクラスとして動く。このクラスがクライアントからのリクエストを受け付けることになる。 @GetMapping(パス) HTTPのGETコマンドで、引数のパスでリクエストされた際に実行するメソッドに付与。 次回 バッファオーバーフローのテストをします。 サンプルアプリ...

今日、やったこと [やってみよう　解説]バッファオーバーフロー 今日のホワイトボード [やってみよう　解説]バッファオーバーフロー バッファオーバーフローの脆弱性をついて、関数のリターンアドレスを書き換える。 main()関数をアセンブラに gdbのdisasコマンドでmain()関数をアセンブラに。 図　disasコマンドでmain()関数をアセンブラに 今回は43行目のprintf()がどこにロードされるかを調べたい。 図　43行目のprintf() hasUpperCase()関数をアセンブラに 同じようにhasUpperCase()関数もアセンブラにしてみる。 図　hasUpperCase()関数をアセンブラに hasUpperCase()関数は0x00…400666番地からロードされていることがわかる。 図　hasUpperCase()関数をアセンブラに 0x00…40073a番地のretqで呼び出し元に帰る。 このとき、hasUpperCase()関数呼び出し時にスタックに書き込まれたリターンアドレスを参照する。 コードエリアにロードされたmain()関数、hasUpperCase()関数は下図のような感じ。 図　コードエリア上のmain()関数、hasUpperCase()関数 hasUpperCase()関数のローカル変数 hasUpperCase()関数のstrcpy()実行後にメモリがどのようになっているか確認。 まず、hasUpperCase()関数のローカル変数がメモリ上(スタックエリア)にどのようにエリアが確保されるか確認。 図　３つのローカル変数のメモリ番地 ３つのローカル変数のうち、配列buffが一番若いアドレスからはじまる。 配列buffの先頭から64バイト分のメモリの様子を調べると以下のようになる。 図　配列buffの先頭から64バイトの内容 配列buffの先頭から41バイト目からリターンアドレスが書き込まれていることがわかる。 バッファオーバーフローの脆弱性を使って、ここに飛ばしたいアドレスを書き込めばいい。 図　3つの変数とリターンアドレス 次回は テストをします。

今日、やったこと バッファオーバーフロー2（戻りアドレス書き換え） 今日のホワイトボード 前回はバッファオーバーフローの脆弱性を使って、関数の戻り値を変更した。 今回はバッファオーバーフローの脆弱性を使って、関数の戻りアドレスを変更する。 そもそもプログラムは コンパイルしてできた実行ファイルはメモリ上のコードエリアにロードされる。 関数を呼び出すと、コードエリアにロードされた命令を1つずつ、順に実行していく。 関数内の変数や引数のためのエリアは、関数呼び出し時にスタックエリア上に確保される。 サンプルプログラム２を実行する 前回のサンプルプログラム１の問題点を修正したサンプルプログラム２を実行する。 コマンドライン引数は、バッファオーバーフローが発生して、変数auth_flagのエリアを上書きしてしまう”12345678901234567890123456789"。 〇strcpy()実行前 変数auth_flagと配列pass_buffの位置を確認。 図　strcpy()実行後 〇return auth_flag実行前 前回のプログラムでは、変数auth_flagが上書きされているが、プログラムを修正したため、0になっている。 図　return auth_flag実行前 プログラムの実行コードを確認 デバッガのdisasコマンドを使って、実行ファイルからmain()関数をアセンブラに変換。 図　disasコマンドでアセンブラに変換 check()関数を呼び出す、main()関数に戻る 関数を呼び出す＝関数がロードされている位置から実行する。 アセンブラで確認すると、main()関数でcheck()関数の呼び出すと、callqコマンドでcheck()関数がロードされているアドレスに移動している。 check()関数の実行が終わると、再びcallqコマンドの次のコマンドから順に実行する。 ここに戻ってこれるように、スタックエリアに戻るべきアドレス番地が記録されている。 これが戻りアドレス。 図　check()関数呼び出し、main()関数に戻る 戻りアドレスを書き換える main()関数にて、check()関数の戻り値に関わらず、下図のように別に位置から実行させたい。 図　check()関数から戻る位置を変える check()関数から戻る位置 下図のように...

今日、やったこと バッファオーバーフロー１（前回からのつづき） 今日のホワイトボード  check()関数のローカル変数 デバッガで２つのローカル変数の位置を確認。 配列password_bufferの先頭から12バイトあとに変数auth_flagがあることがわかる。 図　変数auth_flagと配列password_bufferの位置 配列password_bufferの先頭から29バイト目に変数auth_flagのエリアがあるため、strcpy()で変数auth_flagのエリアを上書きすることができる。 サンプルプログラムを実行する（正常系） コマンドライン引数を"1234567890"で実行。 strcpy()実行後、メモリは下図のようになっている。 図　２つの変数の状態（正常系の場合） サンプルプログラムを実行する（異常系） コマンドライン引数を"12345678901234567890123456789"で実行。 strcpy()実行後、メモリは下図のようになっている。 図　2つの変数の状態（異常系の場合） 変数auth_flagのエリアに引数の最後の値"9"が書き込まれている。 この結果、check()関数の戻り値は0ではないため、31行目が実行される。 次回は バッファオーバーフローのつづき。

今日、やったこと バッファオーバーフロー 今日のホワイトボード この授業は ”セキュアプログラミング”と謳っているので、セキュリティ関係の話をします。 が、セキュリティは範囲が非常に広いため、プログラミングにまつわるセキュリティの話に限定。 さらに、インシデント件数の多いモノに限定。 図　授業で扱う内容 基本的に、どんな言語を使っても、どんなモノを作るにしても、 知っておかなければならない やってはいけない ことを話します。 バッファオーバーフローの演習の準備 バッファオーバーフローはC言語のプログラムで良く発生するので、C言語の演習環境(コンパイラ、デバッガ）のコンテナを用意した。 用意したコンテナには、Zドライブにアクセスできるように”mountZコマンド”を仕込んである。 図　mountZコマンドでZドライブをマウント バッファオーバーフローとは おそらく、全員一度は1年生のときにやらかしていると思われる。 以下のように、確保したメモリエリアを超えて書き込みを行った際に発生する。 図　バッファオーバーフローが起きるプログラム 運が良ければ何も起きないが、運が悪ければ”Segmentation Fault”や”Bus Address Error”が発生して、プログラムの実行が停まる。 "運が良ければ何も起きない"は中途半端なテストではエラーにならないため、一番恐ろしい。 コンピュータのメモリ コンピュータのメモリはOSが管理している。 プログラム実行に関係するのは下図の３つのエリア。 エリアに仕切りがあるわけではない。場合によってはエリアを使い果たしてしまう可能性もある。（いまどきのコンピュータはメモリが豊富にあるためまず起きないと思うけど） 図　メモリ上の３つのエリア C言語のif C言語には論理型(bool型)がない。 ifやwhileなどは　 カッコ内が0か否か 　で分岐する。 図　C言語とC#、Javaのifの違い [バッファオーバーフロー]サンプルプログラム1 サンプルプログラム"bof_sample1.c"をデバッガ上で、引数"1234567890"で実行し、check()関数実行後のメモリの様子を確認。 ローカル変数password_bufferは"0x7ff・・fea30...