HTTP・Webアプリケーション(1)
HTTP
基本的な技術
HTTPメッセージの概要
HTTPでは、HTTPメッセージによってクライアントとサーバ間のデータ受渡しを行う
 リクエスト： | クライアント→サーバ |
|---|---|
| レスポンス： | サーバ→クライアント |
リクエスト行
HTTPメッセージの先頭行
- メソッド(GET、POST、HEAD等)の種類
（PUT、DELETE、TRACE等はセキュリティ上の理由から許可されていない） - URI（要求するページのURLやプログラムを指定。1つのみ指定可能）
- HTTPのバージョン（通常は"HTTP/1.1"）
(例)
ステータス行
HTTPメッセージの先頭行
| コード | 説明 | |
|---|---|---|
| 200 | OK | リクエストが正常終了 |
| 301 | Moved Permanently | ページが恒久的に移動 |
| 302 | Found | ページが一時的に移動 |
| 307 | Temporary | 一時的なリダイレクト |
| 401 | Unauthorized | 認証が必要 |
| 403 | Forbidden | 要求の実行を拒否 |
| 404 | Not Found | 要求されたページが存在しない |
| 500 | Internal Sever Error | サーバ内部でエラーが発生 |
| 503 | Service Unavailable | サービスが一時的に使用不可 |
(例)
メッセージヘッダ
リクエスト／レスポンスの内容に応じたヘッダ情報が入る(HTTPのバージョンによって異なる)
| 情報 | 説明 | リクエスト | レスポンス |
|---|---|---|---|
| Host | ブラウザからサーバにサーバ名を送信する(必須) | 〇 | |
| Authorization | 認証方式や認証情報 | 〇 | |
| Referer | リンク元のURL情報 | 〇 | |
| User-Agent | ブラウザの名称やバージョン情報 | 〇 | |
| Cookie | クライアントがWebサーバに提示するクッキー | 〇 | |
| Date | メッセージが作成された日時 | 〇 | 〇 |
| Content-Length | 返信するサイズ (バイト) | 〇 | 〇 |
| Content-Type | 返信するファイルや文字のタイプ | 〇 | 〇 |
| Server | Webサーバのプログラム名やバージョン情報 | 〇 | |
| Set-Cookie | Webサーバがクライアントにセットするクッキー | 〇 | |
| Location | 次に参照させる先のURI情報 | 〇 |
メッセージボディ
リクエスト時：
POSTメソッド→サーバに送る情報が入る
GETメソッド、HEADメソッド→なし
レスポンス時：
リクエスト内容とその結果に応じてサーバが返す情報が入る
Webサーバとクライアント間のデータ受渡し手段
HTTPでは、ブラウザからの要求によってWebサーバ上のプログラムを起動する仕組みとしてCGIがある
入力データをCGIに引き渡す方法(メソッド)として、「GET」と「POST」がある
GETメソッド
- 入力データやパラメータをURLの後ろに付加して送信する方式
(URLに付加するデータを「クエリストリング」or「URLパラメータ」と呼ぶ) - 送信したデータは環境変数「QUERY_STRING」に格納される
- 送信可能なデータはテキストのみで、サイズはURLエンコードした状態で255文字まで
- URLから入力データを読み取られたり、改ざんされたりする可能性がある
- 入力データがWebサーバのアクセスログに記録される
- Referrerログによって入力データが漏えいする可能性がある
POSTメソッド
- 入力データやパラメータをメッセージボディにセットし、サーバの標準入力を通じて渡す方式
- 送信データのサイズに制限はない
- テキストデータだけでなくバイナリデータの送信可能
- 入力データがURLに含まれないため、GETメソッドより秘匿性が高い
- 入力データがWebサーバのアクセスログに記録されない
(必要に応じてアプリケーション側でログを出力するようにする)
URLエンコード
URL/URIのファイル名やクエリ文字列などの一部としては使用できない記号や文字を、使用できる文字の特殊な組み合わせによって表記する変換規則
- 特殊文字を「％16進数(文字コード)」に変換
→半角シャープ「#」：「%23」
半角アスタリスク「*」：「%2A」
半角プラス「+」：「%2B」 - 半角スペースは例外的に「+」
- 日本語などの「％16進数(文字コード)」に変換
→Shift JISコードで「あ」：16進表記82A0であるため「%82%A0」
Referrer(HTTPヘッダではReferer)
HTTPヘッダの1つ。アクセスログに記載されている情報のひとつで、当該ファイルを取得する(ブラウザで表示する)直前に閲覧していたページのURLを内容とする情報。どこからそのページに要求が来たのかを知ることができる。リファラをログすることでウェブサイトやウェブサーバで訪問者がどこから来ているかを把握でき、プロモーションやセキュリティの目的に使うことができる
Cookie
HTTPにおけるWebサーバとブラウザ間で状態を管理するプロトコル、またそこで用いられるブラウザに保存された情報のこと。ユーザ識別やセッション管理を実現する目的などに利用される
- 少なくとも300個のクッキー
- 1cookie あたり4096バイト以上
- 一意なホスト名またはドメイン名ごとに少なくとも20個のcookie
| 属性・形式 | 情報 | 内容 |
|---|---|---|
| expires=日時 | 有効期限 | クッキーの有効期限を日時で指定する 指定がある：ブラウザが終了以降も有効期限まで保存 指定がない：ブラウザの終了後、消滅 |
| domain =ドメイン名 | 有効な ドメイン名 | クッキーが送信されるドメインを制御する 指定がある：ドメインで指定されたドメインとそのサブドメインにのみ送信 指定しない：Set-Cookieを送信したホストにのみ送信 ※「.co.jp」「.com」「.net」などの指定は無効(未指定の扱い) |
| path =ディレクトリ名 | 有効な ディレクトリ名 | ブラウザがクッキーを送信するサーバのパスを制御する 指定がある：URL内のパスがこれに前方一致する場合にのみ送信 省略した場合：アクセスしたURLに含まれるパスを使用 |
| secure | セキュア属性 | HTTPSで通信している場合にのみクッキーを送信 (盗聴によるクッキーの読取り防止) |
| httponly | httponly属性 | クッキーをJavaScriptからアクセスできないように制限 (クッキーのXSS脆弱性による読取り防止) |
セッションIDの受渡し手段
Cookies
最適だが、クライアントがCookieを受け入れない可能性がある
URLパラメータ
セッションIDを直接URLに埋め込む手法
hiddenフィールド
wwwブラウザに表示されない
Webページのソースを表示するとhiddenフィールドの内容は誰にでも参照できる
Webアプリケーションシステムの基本的構造
セッション管理の脆弱性と対策
対策と脆弱性
重要なセッション管理情報はすべてWebサーバ側で管理する
- クエリストリング、Cookie、hiddenフィールドには、セッションの識別情報(ID)のみ含める
セッションIDを発行する際、ランダムで完全にユニークな値にし、暗号化する
- 規則性を持ったセッションID(例：0001、0002、0003)だと、なりすましが発生する危険性がある
- 複数の同一セッションIDだと、同様の脅威を招いてしまう
1つのセッションが終了時・タイムアウト時に、セッション情報は破棄する
- 破棄されずにセッション情報が漏洩してしまうと、なりすましの脅威を招く危険性がある
hiddenフィールドを利用時には、POSTメソッドを使用してデータ送信を行う
- GETメソッドでデータ送信を行うと、その情報がURLのクエリ文字列に含まれるので、情報漏洩やデータ改ざんを招きやすい。POSTメソッドを使うと、送信データはブラウザのURL部に表示されずに送信されるが、盗聴の脆弱性がある場合はリスクを招く危険性がある
hiddenフィールドで重要なデータを取り扱うことは避ける
- WebサーバへのセッションID受け渡しに、hiddenフィールドを利用することができるが、hiddenフィールドは、wwwブラウザに表示されないが、Webページのソースを表示するとhiddenフィールドの内容は誰にでも参照できてしまう
URLにセッション情報を含めない
Cookieの取り扱い方に留意する
Cookie情報は悪意あるユーザに漏洩してしまう危険性があるので、Cookieの管理には注意が必要である。（XSSの脆弱性により）
- セキュア属性が設定されていないとHTTP通信でもCookieが送信され、盗聴される
- 有効期限が必要以上長く設定されている
- 有効範囲の設定が適切でないと無関係なサーバやディレクトリにもCookieが送信される
入力データに含まれるメタキャラクタのエスケープ処理を確実に行う
- XSSの脆弱性により、Cookieにセットされたセクション管理情報が盗まれる可能性がある
Webサーバで「URL Rewriting機能」を無効にする
意図的なセッション管理情報をクエリストリングにセットして使用することができる
セッション管理を確実に行う
- バグにより、本来は認証を必要とするWebページに認証プロセスなしにアクセスされる
- 認証を必要とするページが検索エンジンやキャッシュに登録されないように設定する(<meta>)
- Webアプリケーションファイアウォール(WAF)を用いて脆弱性を突いた攻撃を遮断する
ログイン後に新たなセッションIDを発行する
クロスサイトリクエストフォージェリ(CSRF)
利用者のブラウザによって、利用者の意図しないリクエストがWebサーバに送信され、ログイン中の利用者にだけ許可されたWebサイトの機能が勝手に実行される脆弱性。掲示板や問い合わせフォームなどを処理するWebアプリケーションが、本来拒否すべき他サイトからのリクエストを受信し処理してしまう
攻撃の手法・特徴
攻撃者は攻撃用Webページを準備し、ユーザがアクセスするよう誘導する
ユーザが攻撃用Webページにアクセスすると、攻撃用Webページ内にあらかじめ用意されていた不正なリクエストが攻撃対象サーバに送られる
攻撃対象サーバ上のWebアプリケーションは不正なリクエストを処理し、ユーザが意図していない処理が行われる
影響と被害
攻撃者は自身が直接攻撃対象サーバへアクセスすることなく、攻撃対象のWebアプリケーションに任意の処理を行わせることができる
- いたずら的書き込み
- 不正サイトへの誘導
- 犯罪予告といった掲示板やアンケートフォームへの不正な書き込み
- 不正な書き込みを大量に行うことによるDoS攻撃
対策
サーバ側でCSRFを防ぐには、サイト外からのリクエストの受信を拒否する必要がある
- ヘッダに含まれる情報を元に参照元が正規のページかどうかをチェックする
- フォームの一部にランダムな数値を隠しておいてアクセスの一貫性をチェックする
- コンピュータが読み取れないよう画像として表示したチェックコードの入力をユーザに要求する
- これらを組み合わせて対策を講じる
HTTP(プロトコル)の仕様による脆弱性と対策
対策と脆弱性
重要な情報を取り扱うWebページではHTTPS(SSL/TLS)によって通信する
- HTTPの場合パケット盗聴によってセッション管理情報が漏えいする場合がある
- クエリストリング、hiddenフィールド、Cookieのいずれでも可能性がある
HTTPのベーシック認証は使用せず、フォーム認証かHTTPダイジェスト認証を用いる
認証を行う画面では必ずHTTPSを使用する
- HTTPの基本認証のベーシック認証では、入力された認証情報(ユーザIDとパスワード)がBASE64エンコードされ、ネットワーク上を流れる
- ベーシック認証では、HTTPリクエストの度、認証情報が送出される
- Webサーバで認証情報を管理する必要があるため、漏えいなどの危険性が高い
フォーム認証では認証情報はWebサーバで管理せず、
データベースなどを用いて管理する
フォーム認証
認証用の入力フォームを用いる認証方法
HTTPダイジェスト認証
WebサーバとWebブラウザなどの間でユーザ認証を行う方式の一つで、認証情報をハッシュ化して送受信する方式
ブラウザからサーバへユーザ名やパスワードなどをそのまま送らずに、その場で生成したランダムな文字列などとともにMD5などでハッシュ値に変換してから送る。サーバ側では予め登録されたユーザ名・パスワードなどから同様の手順でハッシュ値を計算し、両者が一致すれば認証成功とみなす
