1月19日(金)1、2コマ目

今日、やったこと

Webアプリケーションのセキュリティ

今日のホワイトボード

セッションオブジェクト

セッションオブジェクトはサーバー側でクライアント毎に用意する。

クライアントとセッションオブジェクトを紐づけるためにセッションIDが使われる。

図　セッションオブジェクトとセッションID


Cookie

CookieはWebブラウザがデータを保存する仕組み。Webアプリケーションでクライアント側にデータを保存する際に利用する。

〇Cookieをセットする

Cookieはサーバーのset-cookieでデータ保存。

図　サーバーがCookieをセット

〇Cookieを送信する

Webブラウザはサーバーにリクエストを送信する際にCookieも送信する。

図　クライアントがCookieを送信


〇セッションIDをクライアントに保存する

セッションオブジェクトを識別するにはクライアント側でもセッションIDを保存する必要がある。ここでCookieが使われる。

クライアントがサーバーにリクエストするとレスポンスでset-cookieを使ってセッションIDをクライアントに保存させる。

図　サーバーからのレスポンスでset-cookie
このやり取りのパケットのうち、HTTPヘッダ部はWebブラウザの開発者ツールでも確認できる。

〇クライアントがセッションIDをサーバーに送信する

クライアントはサーバーにリクエストするたびにCookieをサーバーに送信する。
サーバーはCookie中のセッションIDからこのクライアントに紐づくセッションオブジェクトを探す。
図　クライアントのリクエストのcookieで送信
このやり取りのHTTPヘッダ部もWebブラウザの開発者ツールで確認できる。

セッションハイジャック

他人のセッションを横取りする攻撃の名前。
他人のセッションIDを取得(盗聴やブラウザのツールなど）し、自分のブラウザのCookieにセットすればセッションを横取りできる。
図　セッションハイジャック

Cookieはサイトごとに用意される

同じブラウザで複数のサイトにアクセスすると、複数のCookieが保存される。
サイトAからセットされたCookieはサイトAにアクセスするときに送信する。別のサイト(サイトB、サイトC)にアクセスする際にはサイトAのCookieは送信しない。
図　送信元のCookieしか送信しない

どのCookieを送信するか？

〇Domain属性、Path属性

WebブラウザはどのCookieを送信するかは、リクエストURLとCookieのDomain属性、Path属性が一致すれば送信する。
Domain属性は後方一致(後ろから前へ比較)、Path属性は前方一致(前から後ろへ比較)で決定する。
図　Domain属性、Path属性で送信する、しないが決まる

〇secure属性、httpOnly属性

Cookieにsecure属性があれば、httpsでの通信時のみ送信。(httpsは通信を暗号化、httpは平文で通信)
httpOnly属性があれば、JavaScriptがCookieにアクセスすることを拒否する。
図　secure属性、httpOnly属性

サードパーティーCookie

リクエストしたサイトから送られたCookieはファーストパーティーCookie。
Webページ中の公告のようにリクエストしたページとは関係ないサイトから送信されたCookieがサードパーティーCookie。
図　サードパーティーCookie
今どきのWebブラウザはサードパーティーCookieを廃止する方向。


同一オリジンポリシー

Webブラウザが、ダウンロード元(Webブラウザのアドレス欄に表示されるURL)と異なるサイト（クロスオリジン)へのアクセスをコントロールする仕組み。

今どきのWebシステム

サービスを提供するサーバーがフロントエンドとバックエンドで異なるケースが多い。
フロントエンドサービス提供サーバーからダウンロードしたHTML、JavaScriptがバックエンドサービス提供サーバーにアクセスするのはクロスオリジンへのアクセス。
このアクセスは同一オリジンポリシーにて拒否される。
図　今どきのWebシステムはクロスドメインのアクセスが発生する
しかしながら、これでは困る。

CORSで解決

そこで、クロスオリジンなアクセスができるように同一オリジンポリシーに抜け穴を作る仕組みがCORS（Cross Origin Resource Sharing)。
図　CORSでクロスオリジンなアクセスを許可する

プリフライトリクエスト

同一オリジンポリシーではクロスオリジンへのリクエストは許可している。拒否するのはレスポンスの受け取り。
場合によってはリクエストも危険な場合がある。(データを更新するようなリクエスト)
そこで、リクエストの前にリクエストを送っても大丈夫かチェックするのがプリフライトリクエスト。

CSRF

クロスサイトリクエストフォージェリ―(Cross Site Request Forgery)。
意図しないリクエストを強制する攻撃手法の名前。
Amazonにログイン済み=>Cookieあり
悪意のあるサイトにアクセス=><form>でAmazonに誤発注するようになっている
悪意のあるサイトのボタンクリック=>Amazonに誤発注リクエスト、このときCookieも送信
Amazonは送信されたCookieからログイン済みユーザーとして認識し、発注を受け付ける。

CookieのSameSite属性

わりと最近追加された仕様。
CSRFのように意図せずCookieを送信することを防ぐための仕組み。

次回は

テストします。






このブログの人気の投稿

1月12日(金)1、2コマ目

イメージ
今日、やったこと エラーページ フィルター 今日のホワイトボード エラーページ 例外スローの結果、エラーページをそのまま出力すると危険。 このエラーページには サーバーの種類(Tomcat)、バージョン プログラミング言語 DBの種類 等、色々な情報が含まれるため危険。 catchブロックを用意して、そのなかでエラーページを表示するようにすればいいが、Javaサーブレットにもデフォルトのエラーページを設定することができる。 図　エラーページの設定 ①設定ファイルweb.xmlを設定 エラーの種類（HTTPのステータスコード別、Javaの例外別）、エラーページが設定できる。 ②エラーページ作成 HTMLだけでなく、JSPも可。 なお、JSPでは暗黙オブジェクトexceptionが使える。exceptionはスローされた例外。 ただ、exceptionを使うにはエラーページであることを指定する必要あり。 エラーページへの遷移はフォワードで行われる。 よって、エラーページをWEB-INF/以下に置くことも可。 リダイレクトとフォワード いずれもページ遷移の仕組みだが、以下の違いがある。 フォワードはサーバー内で遷移先ページを読み込みクライアントへ返す=>1往復 リダイレクトはステータスコード302をクライアントに返して、クライアントが再リクエスト=>2往復 図　フォワードは1往復で遷移 図　リダイレクトは2往復で遷移 認証成功後のページ追加 認証に成功するとユーザー情報を表示する。流れは下図のようになる。 ...
続きを読む

1月29日(月)3、4コマ目

イメージ
今日、やったこと [やってみよう]バッファオーバーフロー 確認テスト 今日のホワイトボード [やってみよう]バッファオーバーフローその１ hasUpperCase()関数にはバッファオーバーフローの脆弱性がある。(13行目) main()関数にてhasUpperCase()を呼び出したときにスタック上に書き込まれるリターンアドレスを43行目のprintf()に書き換える。 プログラムの動き main()関数を逆アッセンブルすると以下のようになる。 図　main()を逆アッセンブルすると 通常はhasUpperCase()実行後、0x7f…400786番地に戻ってくるが、printf()実行の0x7f…4007aa番地に戻るようにスタックエリア上のリターンアドレスを書き換えればいい。 メモリの様子 hasUpperCase()実行時のスタックエリアの様子は以下のとおり。 図　hasUpperCase()実行時のメモリの様子 変数buffの先頭から40バイト離れた(41バイト目以降)ところにリターンアドレスが書き込まれている。ここをバッファオーバーフローで書き換える。 どうすればいい？ どんな引数でもかならず”I DO NOT find UpperCase!”と出力するには、コマンドライン引数に40文字＋リターンアドレスで実行すればいい。 [やってみよう]バッファオーバーフローその２ chkString()関数にはバッファオーバーフローの脆弱性がある。(23行目) main()関数にてchkString()を呼び出したときにスタック上に書き込まれるリターンアドレスを77行目のprintf()に書き換える。 プログラムの動き main()関数を逆アッセンブルすると以下のようになっている。 図　main()関数を逆アッセンブルすると 通常はchkString()実行後、0x7f…4007e2番地に戻ってくるが、printf()実行の0x7f…400817番地に戻るようにスタックエリア上のリターンアドレスを書き換えればいい。 メモリの様子 chkString()実行時のスタックエリアの様子は以下のとおり。 図　chkString()実行時のメモリの様子 その１と同じように変数buffの先頭から41バイト目にリターンアドレスが書き込まれる。ここを書き換えればいい。 どうすればい...
続きを読む

1月9日(火)1、2コマ目

イメージ
今日、やったこと パスワードのハッシュ化 今日のホワイトボード ユーザー認証 ユーザー認証はパスワードが使われるケースが多いが、パスワード以外にもユーザー認証に使えるモノがある。 図　認証に使えるモノ ポイントは「本人しか」。 パスワードの取り扱い 今までは便宜上DBにパスワードを平文で保存していた。が、これは一般的にはありえない話。本来はDB上のデータが漏洩しても即セキュリティインシデントにつながらないようにしなければならない。 図　パスワードの取り扱い 一般的にはパスワードをハッシュ化してDBに保存する。 ハッシュ化 ハッシュ化と暗号化は同じように元の平文が推測しずらい点では一緒。暗号化は元の平文に複合できるが、ハッシュ化された文字列を元の平文に戻すことはできない。 厳密に言えば、できないわけではないが、総当たり攻撃や辞書攻撃になるため、かなり長い時間がかかる。  図　ハッシュ化 ハッシュ化ソースコード PasswordUtil.java 文字列+ソルトをアルゴリズムSHA256で10,000回ハッシュ化してハッシュ値を生成する。 Main.java PasswordUtilクラスを使ってパスワード＋ソルトのハッシュ値を生成させる。 ソルトは実行時の現在時刻のナノ秒部を利用。 ハッシュ化されたパスワードで認証するには DBにハッシュ化されたパスワードを保存する場合、認証は入力されたパスワードのハッシュ値とDBのハッシュ値を比較することになる。 図　ハッシュ化されたパスワードで...
続きを読む