Zenn
🫡

【初心者向け】セッションハイジャック対策 〜なぜHTTPSで通信するのか？〜

2024/01/21に公開
API
http
インフラ
Security
https
tech

久々の更新。

自分の話ですが最近転職しました。
出来て間もない歴史の浅い開発現場なので、ルール策定としてコーディング規約やフロント/バックエンド設計議論などに関するベストプラクティスを深く掘り下げて落とし込む機会が本当に増えました。
（スタートアップ的な経験が欲しかったので結構楽しんでます！）
その中で、”API設計/開発ルールも見直していこう”という話が出てきました。そして復習している時に「久々に記事書くか...」てな感じの経緯です。

本記事ではAPI開発を行う上で注意すべき事項の一つである『セキュリティ』をテーマとして取り上げてみます（全3回~5回ほど）。
初級〜中級をターゲットとした内容ではありますが、堅牢なアーキテクチャ・APIを設計する為に必要な知識かと思います。
（なお、Web API The Good Partsをベースに少し深堀りした内容を記述しています。）

今回取り上げるセキュリティ問題

今回は1について取り上げます。比較的イージーな内容になります。

  1. サーバとクライアント間での情報の不正入手　★今回★
  2. サーバの脆弱性による情報の不正入手や改ざん
  3. ブラウザからのアクセスを想定しているAPIにおける問題
  4. その他（※考え中）

サーバとクライアント間での情報の不正入手

【手段】どのように行われるか？

パケットスニッフィングという言葉をご存知でしょうか？
”コンピュータ間で通信されるデータを収集する事”を指します。
ネットワークに送信されるパケットを不正にキャプチャ、記録し、ネットワーク上に流れるIDやパスワード、IPアドレスなどの情報を取得する目的で行われます。
例えばフリーWiFIに接続されたPCがあった時、パケットスニッフィングを行うツール[1]を導入すれば、誰でも簡単に他の人の通信を覗き見出来てしまいます。

Cafe-Woman
ここで喫茶店などの公共の場所でフリーWiFiを使用するケースを考えてみましょう。フリーWiFiにはデータ通信が暗号化されていないものが多いため、

  • ネットショッピングをしていたらカード情報が抜き取られた
  • SNSが乗っ取られた

なんて事件を耳にした事はないでしょうか。特に前者のような金銭的な被害は辛いですよね。
これらは一般的に「HTTP通信を採用しているフリーWiFiを使用してしまった」事に起因しています。

あの有名なスターバックスの無料WiFiサービスでさえも、暗号化されていない事が公式HPにて明記されています。

「at_STARBUCKS_Wi2」の無線LANは暗号化しておりませんので、秘匿性の高い情報を送受信する場合には、セキュリティを確保するSSLやインターネットVPNなどを用いて通信内容を保護することをお勧めします。
http://starbucks.wi2.co.jp/pc/security_jp.html

また、これに似た攻撃として中間者攻撃またはMITM(Man-In-The-Middle)攻撃と呼ばれるものが存在します。

MITMのイメージ
攻撃者が通信を行う2者の間に割り込んで情報を受け取り、それを盗聴・改ざんした上で通信先の相手に送り出します。
今回のケースで例えると、公共フリーWiFiに装った偽WiFiを設置し、通信に介在するという方法があります。
ettercapというツールでは中間者攻撃を簡単に行えますので、これを用いて機密情報を盗み出す事も出来てしまいます。

【対策】HTTPS通信による暗号化

この問題の対策としてはHTTPSによる通信の暗号化が基本かつ最も簡単かと思います。

詳細

HTTPSは、HTTPに暗号化と検証を加えたものです（詳細は割愛します）。
SSL/TLSという暗号化プロトコルにより通信が保護されているため、HTTPSの通信に対してパケットスニッフィングを行ったとしても無意味な暗号として検出されてしまいます。なので中身を理解する事が出来ません。

しかしそれだけでは安全とは言えません。
リダイレクト危険
全てのコンテンツがHTTPS接続で表示されるよう設定し、HTTP接続後にHTTPSにリダイレクトするような仕組みを設けたとしても、初めにHTTPでアクセス出来てしまった時点で攻撃者がユーザーのCookieを傍受し個人情報を収集できてしまいます[2]。

このような場合に役立つのがHTTP Strict Transport Security(HSTS)という技術です。
これは、リクエスト元のブラウザに対して”常にHTTPS経由でアクセスするように”指示するものです。

システムでの対策イメージ

そしてこれをAPI・インフラ内で対策するならざっくりこんな感じでしょうか。
HSTS対策イメージ

ちなみにnginxとバックエンドAPI（例:django）どちらでもHSTSが設定出来ますが、両方行う事が推奨されています。

  • nginxで設定[3]した場合
    →バックエンドをバイパスして他サーバにアクセスするようなシーンでもHSTSを反映出来る
  • djangoで設定した場合
    →djangoが生成したレスポンスにHSTSヘッダーを付与できる

要は設定できるレイヤが異なるイメージです。
多層にわたって対策しておく事で、セキュリティにおける深層防御アプローチにも準拠しています。

深層防御アプローチ...多層防御、縦深防御とも呼ばれています。セキュリティ対策を複数のレイヤに設ける事でデータやシステムを保護する事を指す、いわばセキュリティ原則のようなものです。 ↩︎

AWS上で対策するなら...

大量にありますがその一例をご紹介します。

  • ACM（AWS Certificate Manager）
    AWS各サービス単位でSSL/TLSデジタル証明書の発行・管理が行うものです。ACMの証明書により通信チャネルして暗号化を行う為、今回のようなセッションハイジャックやMITM攻撃を防ぐ事が出来ます。

  • ELB
    受信時にEC2やコンテナ、Lambdaなどの様々なターゲットに対するトラフィックを自動分散させます。ELBに対しSSL/TLS証明書を設定する事で、暗号化・復号化を処理し通信の安全性を保ちます。

  • Amazon Cognito
    認証、認可、ユーザー管理を行うサービスです。サインアップ、サインイン、アクセスコントロールを手軽に設定できます。Cognitoで扱うトークンを使用する事で今回のリスクを軽減できます。また、セキュリティ強化のためのMFA（多要素認証）にも対応しています。

  • AWS WAF（Web Application Firewall）
    アプリケーションの可用性に悪影響を与えたり、セキュリティ侵害などのエクスプロイト[4]から保護するのに役立ちます。フィルタリングするルールを作成する事で今回の事例を防御できます。

【考察】HTTPSを使えば本当に安全なの？

HTTPSが正しく使われていれば前述のような攻撃を防ぐ事が出来ますが、万全かと言われるとそうでもなく、例えば以下により突破される可能性があります。

  • 暗号化機能を提供するライブラリにバグが含まれているケース
    過去にOpenSSL内で使われている暗号化ライブラリにバグが潜んでおり、使用するサーバのメモリの内容の一部を外部から読み取る事が出来てしまうという事例があったようです。
  • クラウアント側で適切に処理を行えていないケース
    • 証明書が信頼できるものではないケース
      たとえば証明書の有効期限が切れていないかなど。証明書を発行する認証局（CA）が攻撃を受け、不正に証明書を発行してしまうパターンもあります。

ちなみにコモンネーム[5]の検証を行なっていない場合も挙げられていましたが、現在は検証自体が非推奨です。詳細はこちら

まとめ

HTTPSを使用していても100%堅牢性を保つ事は難しく、攻撃手段は常に更新されていくため、常に新しい情報をキャッチアップし対策し続けていく必要があります。本記事がそのキッカケとなれば幸いです。難しい！

脚注

  1. Firesheepという、セッションハイジャックが容易に出来るツールが話題になっていたようです。おそろしあ。 ↩︎

  2. リダイレクトとHSTS ↩︎

  3. nginxでの設定方法 ↩︎

  4. エクスプロイト: 脆弱性を狙った攻撃のこと。詳細はこちら。 ↩︎

  5. コモンネーム: SSLサーバ証明書の設定項目のひとつ。サブドメインまでを含んだドメイン部分を指しています。SSL暗号化通信を行う際、"指定されたアドレス=接続先サイトの証明書のコモンネーム"が一致しているかを確認します（ただし現在、コモンネームの検証は非推奨）。 ↩︎

Discussion