まるぼろの気ままな技術日記(時折日常)

まるぼろです。自己研鑽で学んだ知識をアウトプットしていきます。

HTTP通信とそのセキュリティ対策について

情報処理安全確保支援士の勉強で学んだことをアウトプットしていきます。 ここではWebサーバセキュリティ、特にHTTP通信とそのセキュリティについて纏めております。

目次

①HTTP通信の流れ
②GETリクエスト/POSTリクエストとセキュリティ
③Webセキュリティ対策

①HTTP通信の流れ

通常、私たちがインターネットを通して「https://~」と入力してどこかのホームページを見ている時、ブラウザとWebサーバに送るデータをHTTPリクエスといいます。HTTP通信の流れ(リクエスト)は以下の通りになります。

1.URLを解読する
2.キャッシュにIPアドレスが無いか確認する
3.DNSIPアドレスを取得する
4.IPアドレスでWebサーバにリクエストする
5.ポート番号を割り当てる
6.HTTPリクエストを送信する

②GETリクエスト/POSTリクエストとセキュリティ

GETリクエストとPOSTリクエストの一番の違いはパラメータの受け渡し方になります。 GETはパラメータをクエリストリングに挿入します。 クエリストリングとはURLの後に''?''から始まるエンコードされた文字列です。 この場合、クエリストリングを含むURLはブラウザのアドレスバーにそのまま表示され、さらにログにRefererとしても残り、リンク先にも送信されます。 故に漏洩する危険があるといわけです。

一方でPOSTではWebサーバに送信するユーザの入力情報はリクエストボディを使って送信するので少しは安全になります。ただ、この場合でも通信をキャプチャされると漏洩してしまうので、HTTPSのようにSSL/TLS等との併用が望ましいです。
GETとPOSTはセキュリティ観点で上記のような違いがあります。

③HTTP通信のセキュリティ対策

HTTPSのようにSSL/TLSで通信を暗号化するのはもちろんのことですが、 ステートレスなプロトコルであるHTTPには必須ともなるセッション管理に対するセキュリティは非常に重要です。
セッション管理に代表される手法としてCookieがありますが、このCookieセッションハイジャック等のハッキング攻撃でしばしば標的の的となります。
セッションハイジャックについては以下の記事を参考にしてください。

www.ubsecure.jp

したがってCookieを使用する際は極力安全な状態にしておくことが鉄則となります。
以下、Cookieに設定できるセキュリティ上推奨されている設定になります。

domain:指定したドメインとそのサブドメインにのみCookieを送信する。 Expires:文字通りCookieの有効期限を設定します。
Secure:設定するとHTTPS通信でないとCookie情報を送信できなくなります。
HttpOnly:CookieへのアクセスをHTTPヘッダからのみに限定できます。
これにより、Javascript等クライアント側のスクリプトからはアクセスできなくなり、悪意のある第三者XSSなどの攻撃でcookieを読み取ることを防ぐことができます。

以上まとめになります。走り書きになってしまいましたが随時内容を更新していく予定です。

SSL/TLSって何?

情報処理安全確保支援士の勉強を進めるにあたり、SSL/TLS周りの知識が何となくでしか理解できてないことに気づいたので、頭の整理もかねて体系的にまとめていきます。

まずSSLとは

SSL(Secure Socket Layer)は、インターネット上でやりとりされるデータの「盗聴」「改ざん」「なりすまし」を防止するための暗号化プロトコル(通信方法)です。 たとえばWebショッピングサイトで商品を買う際にクレジットカードで決済したとします。決済情報はブラウザを経由してクレジットカード番号等の情報が送られますが、 SSLで通信を暗号化していないと、悪意のある第三者に盗聴され、情報をを盗まれてしまう恐れがあります。

SSLからTLSの時代へ

広く普及したSSLですが、2020年7月にIPAより刊行された、「TLS暗号化設定ガイドライン」でTLSへの移行を強く推奨していることもあり、TLSを用いることが一般化になりつつあります。

www.ipa.go.jp

この契機となったのが2014年SSL3.0で発見された脆弱性”POODLE(プードル)”です。SSLの暗号化を複合し、平文から認証情報やクッキー情報を盗み出す攻撃でセキュリティ界隈では有名な攻撃手法です。 ちょうど2014年にどなたかがPOODLEについて纏めていた記事がありましたので参考に掲載します。

engineering.dena.com

SSL/TLS通信の仕組み

概要について一通り触れましたので本題のSSL/TLS通信の仕組みについて纏めていきます。

SSL/TLS通信セッションの流れ

通信を開始する前に事前にクライアントとサーバ間でセッションを確立させる必要があります。

https://cf-assets.www.cloudflare.com/slt3lc6tev37/5aYOr5erfyNBq20X5djTco/3c859532c91f25d961b2884bf521c1eb/tls-ssl-handshake.png

①3Wayハンドシェイク

SSL/TLSTCPプロトコルなので3Wayハンドシェイクをする必要があります。

SSL/TLSハンドシェイク

以下の流れで行います。
1.Client Hello
2.Server Hello
3.証明書の送付
4.共通鍵の交換
5.暗号化通信の開始

1.Client Hello

Client Helloはサーバに対して通信で使用する暗号化アルゴリズムSSL/TLSバージョン等の一覧を送信します。

2.Server Hello

Server HelloはClient Helloでクライアントから送られてきた情報の中から一番セキュリティ強度の高い組み合わせを選択し、クライアントへその情報を送信します。

3.証明書の送付

次に認証のフェーズに移ります。通信するサーバが正規のサーバか認証します。 サーバはクライアントにサーバ証明書を送信し、クライアントは送られてきたサーバ証明書の正当性を認証局(CA)の公開鍵を用いて検証します。

4.共通鍵の交換

認証が完了したら共通鍵の生成、交換が行われます。 過去SSL/TLSではハイブリット認証(共通鍵認証と公開鍵認証を組み合わせた認証方式)をとっていましたが、セキュリティの観点から見直され、 現在ではDH法(ディフィーフェルマン法)での鍵交換が主流となっています。 DH法は詳しくは以下の記事で解説されているので詳細を知りたい方は読んでみてください。

it-trend.jp

DH法は簡単に言うとクライアントとサーバ間で実際に共通鍵を配送するのではなく、パラメータを送りあうことで互いに共通鍵を作成する方法です。 送りあうパラメータはプリマスターシークレットマスターシークレットがあり、これらの情報とClient HelloとServer Helloでやり取りした値を使って共通鍵が作成されます。 ですので、送りあうのはあくまでパラメータであり、クライアントとサーバはその情報をもとにそれぞれ共通鍵を作成するので共通鍵が通信で流れることはありません。 故に第三者にによる盗聴、改ざんの危険性が無くなる訳です。

5.暗号化通信の開始

共通鍵の作成が完了したらSSL/TLSハンドシェイクを終了し、通信を開始します。