[情報処理安全確保支援士]HTTPに用いられる技術[無料講座・例題付き]
今回は情報処理安全確保支援士で問われるHTTPに用いられる技術について学習します。
HTTPに用いられている技術
それではHTTPに用いられている技術を確認していきましょう。
HTTPメッセージ
HTTPにおいては、HTTPメッセージによってクライアントとサーバの間でデータの受け渡しが行われます。
クライアントからサーバへ送るデータをリクエスト、サーバからクライアントに返されるデータをレスポンスと呼びます。
HTTPメッセージの構造を確認しておきましょう。
リクエスト行/ステータス行 |
メッセージヘッダ |
空行(CR+LF:改行コード) |
メッセージボディ |
それぞれの意味を見ておきましょう。
リクエスト行
リクエスト行は、HTTPメッセージの先頭行で、リクエストの場合にメソッド(GET・POST・HEADなど)の種類や、URI(Uniform Resource Identifier)、HTTPのバージョンを指定します。
メソッドについては、上記以外にもサーバのファイルを置き換えるPUTや、削除するDELETE、HTTPリクエストの内容を取得するTRACEなどがありますが、いずれもセキュリティの観点から許可されていません。
URIについては、要求するページのURLやプログラムなどを指定します。GETメソッドでは、クエリストリングがセットされます。
ステータスコード
ステータスコードは、リクエスト行と同時にHTTPメッセージの先頭であり、レスポンスの場合に、リクエストに対する処理結果を示すステータスコードが入ります。
主なステータスコードは以下の通りです。
コード | 内容 | 意味 |
200 | OK | リクエストの正常終了 |
301 | Moved Permanently | ページが恒久的に移動 |
302 | Found(Moved Temporarily) | ページが一時的に移動 |
307 | Temporary Redirect | 一時的なリダイレクト |
401 | Unauthorized | 認証が必要 |
403 | Forbidden | 要求の実行を拒否 |
404 | Not Found | 要求ページが見つかりません |
500 | Internal Server Error | サーバ内部のエラー |
503 | Service Unavailable | サービスが一時的に利用不可 |
メッセージヘッダ
メッセージヘッダは、リクエストとレスポンスの内容に応じたヘッダ情報が入ります。
主なヘッダ情報としては以下のようなものが挙げられます。
ヘッダ | 内容 |
Authorization | 認証方式や認証情報 |
Referer | リンク元のURL情報 |
User-Agent | ブラウザの名称やバージョン情報 |
Cookie | クライアントがWebサーバに提示するCookie |
Content-Type | 送信するファイルや文字セットの種類 |
Server | Webサーバのプログラム名やバージョン名 |
Set-Cookie | WebサーバがクライアントにセットするCookie |
Location | 次に参照させる先のURI情報 |
Strict-Transport-Security | ブラウザに対してHTTPの代わりにHTTPSを用いて通信するように強制する |
X-Content-Type-Options | ブラウザがファイルの中身からContentTypeを決める機能を無効化し、レスポンスヘッダのContentTypeを常に優先する |
X-Forwarded-For | プロキシサーバや負荷分散装置などを経由する場合の、実際の送信元ホストのIPアドレス情報 |
X-Frame-Options | ブラウザがframeやiframeでページ表示することの可否を指定する |
X-XSS-Protection | 反射型XSS攻撃を検出したときに、ページの読み込みを停止する |
Content-Security-Policy | コンテンツやスクリプトの読み込みを許可するドメインなどを定義することで、ブラウザの挙動などをWebサイト側で制御する |
メッセージボディ
メッセージボディには、リクエスト時にPOSTメソッドを使用した場合のサーバに送る情報が入ります。
GETメソッドやHEADメソッドの場合は、リクエスト行とメッセージヘッダのみとなり、メッセージボディはありません。
レスポンス時には、リクエスト内容とその結果に応じてサーバに返す情報(HTMLデータや画像データ)が入ります。
Webサーバとクライアントのデータの流れ
Webサーバとクライアント間のデータの流れも確認しましょう。
HTTPにおいては、ブラウザからの要求に応じてWebサーバ上のプログラムを起動する仕組みとしてCGIがあります。
CGIによってWebサーバのプログラムを起動する場合、パラメータやフォームに入力されたデータを渡す仕組みとして、GETメソッドとPOSTメソッドがあります。
GETメソッド
GETメソッドの特徴は以下の通りです。
- 入力データやパラメータをURLの後ろに付加して送信する
- 送信したデータは環境変数(QUERY_STRING)に格納される
- 送信可能なデータは255文字以下のテキストのみ
- URLからデータを盗聴されたり、改ざんされたりするリスクがある
- 入力データはWebサーバのアクセスログに記録される
- Refererログにより入力データが漏洩するリスクがある
POSTメソッド
次に、POSTメソッドの特徴も見ておきましょう。
- 入力データやパラメータをメッセージボディにセットし、サーバの標準入力を用いてデータを渡す
- 送信データのサイズに制限がない
- テキストデータに加え、バイナリデータも送信できる
- URLに入力データが含まれず、盗聴されない
- 入力データがWebサーバのアクセスログに記録されない
URLエンコード
URLエンコードは、入力データをURLで使用可能な文字列に変換する処理です。具体例を確認しておきましょう。
- “スペース”を”+”に変換
- 特殊文字を”%16進数”に変換
- ASCⅡコードの31以下および128以上の文字を”%16進数”に変換
Referer
Referer(正式にはReferrer)は、HTTPメッセージヘッダの1つで、あるページにアクセスしたときにどのリンクをたどってきたのか確認できるようにリンク元のURLがセットされるヘッダです。
Refererにセットされた情報をログに記録すると、Webサイトの管理者は自分のサイトがどのリンクから参照されたかを知ることができます。
Refererにはパラメータも含めたURLがセットされます。そのため、セッション管理情報やフォームからの入力データをクエリストリングにセットしている場合、Refererのログから情報漏洩する可能性があります。
Cookie
Cookieは、Webサーバがアクセスしてきたクライアントに対して、ブラウザを通じて一時的にデータを書き込み、相手を識別したりセッション状態を保持する仕組みです。
CookieはWebサーバがHTTPヘッダにセットすることで発行され、それ以降はサーバへのアクセス時に毎回自動的にHTTPヘッダに付加されます。
しかし、Cookieの属性によっては付加されないケースもあります。また、Cookieには以下のような制限もあります。
- 1つのCookieには最大4,096倍とのデータを記録できる
- 1つのWebブラウザに最大300個のCookieを保持できる
- 1台のWebサーバには同じコンピュータに対して最大20個のCookieを発行可能
また、Cookieには次の表に示す属性があり、Webサーバが発行するときに指定します。これらの属性を適切に設定することで、Cookieの流出や不正使用を制限することが可能となります。
属性 | 内容 | 詳細 |
expires=”日時” | 有効期限 | ・Cookieの有効期限を日時で指定 ・期限の指定がない場合、ブラウザの終了時に消滅する ・期限が指定されている場合、ブラウザの終了時にも保持 |
domain=”ドメイン名” | 有効なドメイン | ・Cookieが有効となるドメインを、「.」から始まる形式で指定する(例:.sikaku-no-iroha.co.jp) ・指定があった場合、そのドメイン名が含まれていることがCookieを創出する条件となる(サブドメイン名・ホスト名が異なってもok) ・指定がない場合、Cookieを発行したサーバとの通信のみCookieを送出 ・セキュリティ確保のため、「.co.jp」・「.com」・「.net」などの指定は無効 |
path=”ディレクトリ名” | 有効なディレクトリ | ・サーバ上でCookieが有効となるディレクトリを指定し、名称を指定する ・指定がある場合、そのディレクトリにアクセスする場合のみCookieを送出する ・指定がなかった場合、「/」となり、そのCookieを発行したページの存在するディレクトリをルートとして該当ディレクトリとその下にあるすべてのディレクトリで有効となる |
secure | secure属性 | HTTPSで通信している場合のみCookieを送出する |
HttpOnly | HttpOnly属性 | Cookieの適正範囲をHTTP/HTTPS通信だけに限定してブラウザで実行されたスクリプトが”document.cookie”を用いてアクセスすることを禁止する |
セッションIDの受け渡し
セッションIDの受け渡し手段として、次の3つの手法があります。
- クエリストリング
- hiddenフィールド
- Cookie
Webアプリケーションシステムとデータベースの連携
Webアプリケーションとデータベースを連携した場合、以下のような構成を取るケースが多いです。
セッション管理やデータベースとの連携などを行うミドルウェアの部分については各言語(Java・PHP・ASPなど)を用いて開発できますが、大規模なWebアプリを作成する場合、専用のWebアプリケーションサーバ製品を用いることが多いです。
結果として以下のようなメリットを受けられます。
- 開発生産性の向上
- 拡張性の向上
- パフォーマンスの向上
- アプリケーション品質の向上
- セキュリティの向上
HTTPに用いられている技術・例題
実際に例題を解いて問題に慣れていきましょう。
問1
ア ブラウザは,cookieの”Secure=”に続いて指定された時間を参照し,指定された時間を過ぎている場合にそのcookieを削除する。
イ ブラウザは,cookieの”Secure=”に続いて指定されたホスト名を参照し,指定されたホストにそのcookieを送信する。
ウ ブラウザは,cookieの”Secure”を参照し,HTTPS通信時だけそのcookieを送信する。
エ ブラウザは,cookieの”Secure”を参照し,ブラウザの終了時にそのcookieを削除する。
(ログイン後回答すると、ここに前回の正誤情報が表示されます)
問2
ア HTMLバージョン情報(DOCTYPE宣言)
イ POSTリクエストのエンティティボディ(POSTデータ)
ウ WebサーバとWebブラウザ間の状態を管理するクッキー(Cookie)
エ Webページのタイトル(TITLEタグ)
(ログイン後回答すると、ここに前回の正誤情報が表示されます)
HTTPに用いられている技術・まとめ
HTTPのなかでもセキュリティを確保するための取り組みは多いです。
それぞれのコード内容まで詳細に覚える必要はありませんが、CookieをはじめとするセッションIDの受け渡し方法は押さえておきましょう。
次回はスイッチとVLANについて学習します。
福井県産。北海道に行ったり新潟に行ったりと、雪国を旅してます。
経理4年/インフラエンジニア7年(内4年は兼務)/ライター5年(副業)
簿記2級/FP2級/応用情報技術者/情報処理安全確保支援士/中小企業診断修得者 など
ディスカッション
コメント一覧
まだ、コメントがありません