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

今日、やったこと  Spring Securityで認証アプリケーション作成(前回からのつづき) 今日のホワイトボード 前回は 前回 はSEC_商品マスタテーブルにアクセスするために Item.java ItemRepository.java application.properties を作成した。 商品一覧を表示する 商品一覧ページを表示するために以下を追加。 controller/ItemController.java クライアントからのリクエストを受け付けて、処理を行い、ビューを返す。 index.html このアプリケーションのトップページ。商品一覧を表示する。 実行すると とくになにも設定していないため、全ページが認証対象になる。 Spring Securityの認証画面が表示される。 図　トップページにアクセスすると認証画面に ユーザー情報はなにも登録していないため、Spring securityのデフォルトのユーザー"user"でログイン。パスワードもSpring Securityが生成して、コンソールに表示される。 図　ユーザーは"user"、パスワードを入力してログイン 認証に成功するとトップ画面が表示される。 図　認証成功 -> トップ画面表示 認証に失敗すると、エラー表示。 図　認証失敗 -> エラーメッセージ表示 認証不要画面、認証必要画面をわける トップページは認証不要。 新規登録画面に進むには認証が必要に変...

今日、やったこと [確認テスト]Webのセキュリティ 今日のホワイトボード 今日はテストだけでした。 次回は Spring Securityをつかった認証。 

今日、やったこと CSRF(<form>タグのばあい) SQLインジェクション Spring Securityで認証アプリケーション作成 今日のホワイトボード CSRF(<form>タグのばあい) <form>タグは、ダウンロード元とは異なるサイト(クロスサイト)をaction属性に指定できる。 CSRF(クロスサイトリクエストフォージェリ)の脆弱性がある。 図　<form>タグにはCSRFの脆弱性がある CSRF対策 <form></form>内にCSRFトークンを埋め込む 。 AmazonのサイトからダウンロードしたページにはCSRFトークンがある。このCSRFトークンはサーバー側とクライアント側で共有する。submitボタンをクリックした際に、AmazonにはCSRFトークンが送信される。トークンが一致するなら、正しいリクエストと判断できる。 悪意のあるサイトからダウンロードしたページにはCSRFトークンがない。（悪意のあるサイトはCSRFトークンに何を指定すればいいかわからない） よって、このページからAmazonにリクエストしても、CSRFトークンがないため、Amazonはリクエストを拒否する。 図　<form>タグのCSRF対策 => CSRFトークンの埋め込み SQLインジェクション プログラム中で、SQLをクライアントから送信されたデータを使って、文字列結合で組み立てる場合に発生する。 SQLにはパラメータマーカーを使い、SQL実行時にデータをバインドすれば発生しない（と思う） 図　SQLインジェクション 認証機能をつくる Spring Securityを使って、ユーザー認証をする。 Spring Securityは認証・認可のフレームワーク。 DB中のユーザー情報 パスワードはハッシュ化された状態で保存。（漏洩対策） 図　パスワードのハッシュ値がDBに保存される 暗号化とハッシュ化は似ているが、もとに戻せるか、戻せないか（厳密には戻すのにすごく時間がかかる）が違う。 図　暗号化とハッシュ化の違い ソースコード 今日は途中まで作成。 なお、DBアク...

今日、やったこと クロスサイトスクリプティング(XSS) 今日のホワイトボード クロスサイトスクリプティング(XSS) スクリプトがいつ、どこで埋め込まれるかで3種類に分類される。 サーバー側で埋め込まれるのは、反射型と蓄積型。 反射型はリクエストするURLにスクリプトが含まれる。 蓄積型はスクリプトはサーバー側に保存されている。 クライアント側で埋め込まれるのは、DOM-base型。 図　3種類のクロスサイトスクリプティング クロスサイトスクリプティングを防ぐには ブラウザにHTMLとして認識されないように、<や>をそのままブラウザに送らない。 この置き換えを サニタイジング と呼ぶ。 図　サニタイジング ユーザーが入力したデータを出力する際は、サニタイジングを行う。 次回は Webのセキュリティの残り（SQLインジェクション、その他） 次々回に紙のテストをします。 

今日、やったこと 同一オリジンポリシー CORS(Cross Origin Resource Sharing) プリフライトリクエスト CSRF(Cross Site Request Forgeries)  今日のホワイトボード 今日も今日とて、日がな一日座学でした。 眠いし、つまらんし。 同一オリジンポリシー 前回終盤にちょこっと解説。 ダウンロードしたコンテンツ(HTMLやJavaScript、cssなど）から、 ダウンロード元と異なるサイト（クロスオリジン）へのアクセスを制限する仕組み 。 実際は、 リクエストは送信されるが、レスポンスの受け取りをブラウザが拒否する 。 同一オリジンポリシーの例外 同一オリジンポリシーに従うと、クロスサイトの画像を表示できないように思える。 が、これは例外扱い。画像の埋め込みやcss、JavaScriptファイルの埋め込みはできる。 図　埋め込み系は同一オリジンポリシーによる制限の例外 CORS（Cross Origin Resource Sharing) まったく悪意が無い場合、この同一オリジンポリシーはかえって問題。 悪意のないサイトのページ内で、悪意のないサイトのサービスを利用したくてもできない。 そこで、同一オリジンポリシーの制限（クロスオリジンからのレスポンスを受け取らない）を緩める仕組みがCORS（Cross Origin Resource Sharing）。 図　CORS クロスオリジンからのレスポンスの中に、 　 Access-Control-Allow-Origen ：ドメイン名 が含まれていたら、ブラウザはレスポンスを受け取る。 プリフライトリクエスト 同一オリジンポリシーはまだつづく。 クロスオリジンからのレスポンスは受け取らないが、リクエスト自体はしてしまう。 図　クロスサイトにリクエストはしてしまう リクエスト自体に悪意がある場合、問題。 そこで、リクエストを送信する前に、プリフライトリクエストを送信。 プリフライトリクエストを受信したサーバーは 　Access-Control-Allow-Origin を送信する。クライアント(Webブラウザ)はダウンロード元がリクエスト先に許可されているか確認してリクエスト送信する。 CSRF(Cross Site Request Forgeries) リ...

今日、やったこと  Cookieのつづき 同一オリジンポリシー 今日のホワイトボード [おさらい]クライアントはCookieを送信する？しない？ 前回のCookieのはなしで、クライアントがサーバーにCookieを送信するには、アクセス先が CookieのDomain属性と後方一致する CookieのPath属性が前方一致する の2つの条件を満たす場合のみ。 CookieのHttpOnly属性 JavaScriptでは、 　document.cookie でCookieにアクセスできる。 JavaScriptがCookieを読み取り、サーバーに送信すれば、マズい気がする。 が、CookieのHttpOnly属性がOnになっていれば、JavaScriptはアクセスNGになる。 図　CookieのHttpOnly属性 CookieのSecure属性 https通信の時だけCookieを送信する。 図　CookieのSecure属性 サードパーティCookie アクセス先以外からset-cookieされたCookie。 広告サイトのCookieがほとんど。 ユーザーが意図せず広告サイトに情報を提供することにつながるため、規制・廃止の方向。 図　サードパーティCookie オリジン オリジンとは スキーム(プロトコル) ホスト ポート番号 の組み合わせ。 パスは含まない。 同一オリジンポリシー ダウンロード元と異なるオリジンにはアクセスできないルール。 図　同一オリジンポリシー ただし、例外もあるので注意！！ 次回は まだまだつづく。 眠いし、だるいし、つまらんが。

今日、やったこと [Webアプリケーションのセキュリティ]Cookie 今日のホワイトボード 前回までに作成したxss検証用サイトアプリケーションを使って、Webアプリケーション構築時に知っておかなければならない、セキュリティ知識を紹介。 座学メインで進めます。眠い、つまらん、ダルいと思いますが、最後に紙のテストをしますので、しっかり理解をしてください。 Cookieとは クライアント(Webブラウザ)がデータを保存する仕組み。 サーバーから Set-cookie で送信されたデータを保存する。 クライアントはサーバーにリクエストする際、Cookie保存データを送信する。 図　クライアントがCookieを保存する、サーバーに送信する SessionオブジェクトとCookie 〇Sessionオブジェクト Webアプリケーションにおいて、リクエストを跨いでデータを共有できるのが、Sessionオブジェクト。 Sessionオブジェクトはクライアント毎に生成し、ユニークなセッションIDで識別する。 〇セッションID クライアントとサーバー間で同じセッションIDを保持し、クラインとはサーバーにリクエスト送信する際に、セッションIDを送信することで、サーバー側はクライアントのセッションオブジェクトを識別している。 図　セッションオブジェクトとセッションID 〇クライアントのセッションID保存先 クライアントのセッションID保存先はCookie。 サーバーがセッション開始後、クライアントにset-cookieでセッションIDを送信。 図　セッションIDをset-cookieで送信 クライアント側で、Cookieは簡単に書き換えできる。 CookieのセッションIDを書き換えて、他人のセッションを乗っ取ることもできる。（セッションハイジャック） クライアントはサーバーにCookieを送信する(Domain属性) クライアントはサーバーにリクエスト送信する際、Cookieを送信する。 が、なんでもかんでも送るわけではない。 CookieのDomain属性がリクエスト先のサーバー名と一致するなら送信。 図　CookieのDomain属性とリクエスト先サーバー名が一致するなら送信 Domain属性とリクエスト先サーバー名が一致する、しないは 後方一致 で判断。 ”後方一致する”を簡単...

今日、やったこと xss検証用サイト構築 今日のホワイトボード 前回 は認証機能の途中まで作成。 認証機能（UserDAOクラスのインスタンス生成） コントローラで認証をする際、必要になるUserDAOクラスのインスタンスは、SpringBootのDI機能を使って、インスタンスを生成。 インスタンス生成するクラス(UserDAOクラス)には、@Repositoryアノテーションを付与。 インスタンスを代入する変数(フィールド)には、@Autowiredアノテーションを付与。 図　@Repository、@Autowired UserDAO.java @Repositoryアノテーションをつけると、SpringBootのDIコンテナに登録される。 認証機能（リクエストを跨いで認証済み情報を共有したい） コントローラクラスのメソッドの引数modelはリクエスト毎にインスタンス生成されるため、リクエストを跨いで情報を共有することはできない。 一旦、認証されると、認証情報を保持したいが、引数modelではできない。 リクエストを跨いで共有できるのは、Sessionオブジェクト。 図　引数modelとSessionオブジェクトの違い SpringBootでは、Sessionオブジェクトは引数で受け取ることができる。 MessageController.java UserDAOクラス型のdaoフィールドには@Autowiredを付与することで、SpringBootがUserDAOクラスのインスタンスを代入してくれる。 login()、logoff()メソッドの引数sessionはSessionオブジェクト。SessionオブジェクトはSpringBoot側で取得し、引数に代入してくれる。 index.html Thymeleafにて、Sessionオブジェクトにアクセスするには、session...