by shigemk2

当面は技術的なことしか書かない

今夜わかるHTTP 5 セキュリティ技術

読書ノート

前回
今夜わかるHTTP 4 - by shigemk2

HTTPの弱点

  • 通信は平文(暗号化しない)で行う

TCP/IPは通信を保証するだけであって、内容そのものはツールを使えば
誰でも確認出来る(つまり、盗聴が可能)
HTTPに暗号化の機能を付けくわえると、リソースが食われて
処理が重くなるからできないのが理由である。

  • 相手を確かめない

誰でもリクエストが可能であるし、
どこでもリクエストが可能である。
つまり、クライアントとサーバーのどちらでもなりすましが可能になりうる。
→対策として、証明書をSSLによって発行することが考えられる。

  • 完全性を証明できない

完全性とは、情報の正確さのことだが、
リクエストやレスポンスが第三者によって改竄されるおそれがある。
→PGP(Pretty Good Privacy)による署名とMD5によるハッシュ値提供が対策として考えれられる。
ただし、この署名やハッシュ値も、書き変えらえる可能性は否定できない。

ただし、HTTPにもアクセス認証の機能はある。
リクエスト時に、ステータスコード401 Unauthorizedとともに、
認証用の情報をWWW-Authenticateヘッダーフィールドに含めてレスポンスを返す

  • 基本認証 (Basic Authorization)

ヘッダーフィールドにユーザーIDとパスワードをbase64エンコードしたものを送信する
ただしこの方法は簡単に復号可能である

  • ダイジェスト認証 (Digest Authorization)

ヘッダーフィールドにパスワードやその他のパラメーターのMD5ダイジェストを送る。

これらにも弱点はあり、認証後の通信は暗号化されないので、盗聴も難しくない。

HTTPS
HTTPに暗号化と認証と完全性保護を加えたもの。
HTTPの通信を行う部分を、SSL(Secure Socket Layer)というプロトコルに置き換えているだけの
代物だが、SSLというプロトコルの殻をかぶったHTTPがHTTPSであるといえる。

SSLでは公開鍵認証化方式とよばれる暗号化方式を採用している。

公開鍵と秘密鍵のセットで、クライアントは公開鍵をつかってリクエストを暗号化し、
サーバーは秘密鍵を利用して復号化を行う。

サーバーは公開鍵を作り、認証機関に公開鍵を渡す。
認証機関は公開鍵にデジタル署名を施し、署名済み公開鍵を作成し、デジタル証明書を作成する。
サーバーは証明書をクライアントに送る。

HTTPSの基本的な仕組みについて

  1. クライアント 暗号スイート(使用する暗号化のアルゴリズムや鍵のサイズなどのリスト)を含むserver helloメッセージを送信する
  2. サーバー SSL通信が可能なら、同じSSLのバージョンと暗号スイートを含むserver helloメッセージで応答する
  3. サーバー 公開鍵証明書を含むCertificateメッセージを送信する。
  4. サーバー server hello doneメッセージを送信することで、最初のSSLネゴシエーションが終わったことを通知する
  5. クライアント SSLの最初のネゴシエーションが終了したら、client key exchangeメッセージで応答する。メッセージには通信を暗号化するのに使うプリマスタシークレットと呼ばれる暗号化の種が含まれている。このメッセージは公開鍵証明書から取り出した公開鍵で暗号化されている。プリマスタシークレットのやりとりにより、サーバーとクライアントの共通鍵を確認する。
  6. クライアント change cipher specメッセージを送信する。このメッセージは、これ以後の通信は暗号鍵を使って行うことを示す
  7. クライアント finishedメッセージを送信する。このメッセージは、接続全体のチェックを含む。ネゴシエーションの成功は、サーバーがこのメッセージを正しく復号化できたかどうかで決まる。
  8. サーバー change cipher specメッセージを送信する。
  9. サーバー 同じくfinishedメッセージを送信する。
  10. finishedメッセージの交換が完了したら、SSLによる接続は確立される。ここからの通信はSSLによって行われる
  11. アプリケーション層のプロトコル通信を行う
  12. 最後にクライアントの接続を閉じる。

なお、HTTPSはクライアント証明書も発行出来る(一般にクライアントの信頼性は低いのであまり行われないが)。
SSLのかわりにTLS(Transport Layer Security)が使われることもある(あまり普及していないが)
HTTPSはHTTPにくらべて2倍から100倍遅いので注意すること。
対策として、必要なページにしかHTTPSを適用しないこと、また
SSLアクセラレーターを利用してSSLの処理だけを丸投げすることが挙げられる。


狙われるwebアプリケーションの脆弱性とその対策について
攻撃の対象になるのはHTTPプロトコルそのものよりもwebアプリケーションのほうが
多い。
webアプリケーションの脆弱性top10

  1. 許可されていない入力 リクエストは直接生成出来る
  2. 不完全なアクセス制御 アクセス制御が適切に行われておらず、攻撃者が不正にアクセスする(識別子を予想されたり、認証が不在だったり、Path Traversalだったり)
  3. 認証とセッション管理が不完全 認証の仕組みの不備
  4. クロスサイトスクリプティングの欠陥 悪意のあるwebサイトに飛ばされ、悪意のあるスクリプトを実行させられてしまうこと
  5. バッファオーバーフロー プログラムが入力値以外の値を受け取ることで、バッファをはみだして動作異常を引き起こしてしまう。
  6. 挿入の欠陥 他のシステムに不正なコードを中継してしまう脆弱性のこと。悪意のあるリクエストを送られて、変なスクリプトを実行させられてしまうことが例となる。
  7. 不適切なエラー処理 想定していないエラーメッセージがそのままブラウザに表示されてしまうこと。
  8. 安全ではない保存 個人情報をバッファのどこかに保存してしまうこと。
  9. サービス妨害 過多のアクセスにより、リソースを食わせてサーバーエラーを引き起こす。DoS攻撃(田代砲など)
  10. 設定管理が安全ではない OSやサーバーの問題だが、不適切なバージョンを使用していたり、不要なサービスが起動していたりする。適切にサーバーセキュリティを高めることが重要である。

今夜わかるHTTP (Network)

今夜わかるHTTP (Network)