12月23日(水)1コマ目
今日、やったこと
「安全なWebアプリケーション構築」（セッション、サニタイジング）
今日のホワイトボード
（くどいけど）セッションオブジェクトとセッションID
サーバー側のセッションオブジェクトはセッションIDでどのクライアント用かを識別している。
クライアント側はサーバーにリクエストするときにセッションIDを送信することで、サーバーはクライアントを識別している。
クライアントはこのセッションIDを一般的にはWebブラウザのCookieに保存している。
ここで、
- クライアントがサーバーにセッションIDを送信する=>盗聴されるとセッションハイジャックされる。
- クライアントはセッションIDをCookieに保存する=>JavaScriptで読み書き可能、クロスサイトスクリプティングで読み込まれる可能性あり。
の危険がある。
|
| 図 セッションオブジェクトとセッションID |
[対策]ログイン後はセッションを破棄、再開
セッションIDを盗まれることを前提にすると、同じセッションIDを使い続けないほうがいい。
よって、ログイン後はセッションをいったん破棄して、その後再開することで、セッションIDを変更する。
|
| 図 セッションIDに係るマズいことと対策 |
|
| 図 セッション破棄、再開でセッションIDを変更する |
JSPに出力する
DBから取得した内容をそのまま出力するのは危険。
たとえば、DBが以下のようになっていると
| ID | ログイン名 | 表示名 | パスワード | ソルト |
|---|---|---|---|---|
| 2 | jiro | <H1>ジロウ</H1> | ・・ | ・・ |
表示名を出力すると<H1>タグによって大きく表示される。
掲示板サイトのようにユーザーが入力した内容を出力する場合、入力内容をそのまま出力すると上記のようなことが起きてしまう。
大きく表示されるくらいなら問題はないが、JavaScriptを実行したり、変なサイトへのリンクを張ったりとタグをそのまま出力すると結構マズいことが起きてしまう。
そこで、タグをそのまま出力せず、＜や＞をエスケープさせた文字列に変更するサニタイジングを行うことで対応する。
[おまけ]クライアントから直接アクセス可能？不可能？
これは次回。
|
| 図 クライアントからアクセス可能？不可能？ |
コメント