こんにちは。じゅに(@Jyu210_engineer)です。
HTTP通信で制限されている機能について調査する機会があったので、調査結果を書いていこうと思います。
HTTP通信で機能が制限されるようになった経緯
- 2014年:Googleが「HTTPSサイトをSEOで優遇する」と発表したことにより、WebのHTTPS化が注目され始める
- 2015年:Chrome、FireFoxなどえ「一部の機能をHTTPSのみで提供する」と発表
- 2016年:Service WorkerやPush APIなどの重要APIでHTTPSが必須になった
- 2017年:ChromeがHTTPページに「保護されていない通信」と警告表示をするように機能追加
- 2018年:Chrome 68ですbゔぇてのHTTPページに@「保護されていない通信」と明示的に表示されるようになり、事実上HTTPSが必須となる
HTTP通信で機能が制限されるようになった理由
ざっくり言うとセキュリティを重要視することによる制限になりますが、具体的には以下のような理由からです。
通信盗聴・改ざんを防ぐため
- HTTP通信は平文なので、第三者に盗み見られたり、改ざんされる危険がある
- ログイン情報やカメラ映像が漏洩するリスクが高い
フィッシングサイトや偽装サイトの温床になっていたため
- HTTPサイトはSSL証明書が不要なので、偽サイトを簡単に立ち上げられる
- HTTPS化していないサイトは信頼性が低いと判断されるようになった
ユーザーのプライバシー保護が求められる時代背景が変化
- 位置情報、カメラ、マイクなどの使用は個人情報深く関わるため、安全な通信路(HTTPS)でのみ許可されるようになった
ブラウザベンダーが「安全でないWebは使用させない」という方針を打ち出した
- Google(Chrome)、Mozilla(Firefox)、Apple(Safari)などブラウザ側のセキュリティが強化された
- 「HTTPSでなければ重要なAPIを使用させない」という設計が基本となった
HTTPで制限されるようになった機能(API)一覧
機能・API | 内容 | HTTPSが必要な理由 |
---|---|---|
getUserMedia | カメラ・マイクの使用 | ユーザーのプライバシー保護のため |
MediaDevices.enumerateDevices | 利用可能なデバイス(カメラ・マイクなど)の取得 | ユーザーのプライバシー保護のため |
Geolocation API(navigator.geolocation) | 位置情報の取得 | ユーザーが追跡されるリスクの排除 |
Web Bluetooth | Bluetoothデバイスとの通信 | 周辺機器との不正アクセス防止 |
WebUSB | USBデバイスとの通信 | デバイスの安全性確保 |
WebHID | Human Interfase Devices(キーボードなど) | との通信 |
Web Serial | シリアルポート通信 | デバイス制御の抑制 |
Service Workers | オフライン動作・バックグラウンド処理など | セキュアな通信を前提としたキャッシュ処理などが含まれるため |
Push API / Notifications | プッシュ通知の送信・表示 | フィシングなど悪用されるリスクが高いため |
Clipboard API(書き込み) | クリップボードへの書き込み機能(読み取りは一部制限) | 情報漏洩のリスクが高いため |
Payment Request API | ブラウザ組み込みの決済機能 | 金銭取引に対するリスクの排除 |
Storage Access API | サードパーティCookieへのアクセス許可 | トラッキング追跡を回避するため |
Background Sync | サイトが閉じられた後の同期処理 | 不正なデータ送信を防ぐため |
Credential Management API | ユーザー名・パスワードの自動入力管理 | 不正ログイン防止のため |
deviceorientation / devicemotion(一部) | スマホなどのセンサー情報の取得 | デバイス情報漏洩リスクの排除 |
これらのAPIはJavaScript用のブラウザAPIになっており、バックエンドからの使用は行えません。
(ブラウザ上でのユーザーさおうさに基づいて使用する機能であるため)
Web Bluetooth
Bluetoothデバイスと通信を行う、Web Bluetoothですが、Bluetoothデバイス(センサーなど)との通信はローカルで行われます。(Bluetooheの規格上の暗号化がされている)
その通信結果をWebサーバーに送信する時にWebサーバーがHTTPSで提供されていないと、Bluetooth通信で取得したデータが平文でネットワークに流れることになるので、情報漏洩につながる。
WebUSB
USBデバイス(USBメモリ、プリンターなど)とブラウザを介してローカルで直接通信を行う。通信はインターネットを経由せずに、物理的なUSB接続を通じて行われるため、暗号化はされていない。そのデータをWebサーバーに送信する際にHTTPSでなかったら通信内容が平文で送信されるので、情報漏洩につながる。
WebHID
WebUSBとの違いはHID(Human Interface Device)に準拠したはUSBデバイス(主にキーボード、マウス、ゲームパッドなど)との通信に使用される。それ以外はWebUSBと同様。
Web Serial
Web Serialもシリアル通信するデバイスとはローカルで通信が行われる。シリアル通信自体は暗号化されていないが、WebHIDと同じくデバイスとは物理的に接続するため問題はない。そのデータをWebサーバーに送信する時にHTTPSで提供されていないと通信内容が漏洩することにつながるため、HTTPでは使用が制限されている。
Service Workers
JavaScriptで書かれたバックグランドスクリプトで、Webページのライフサイクルから独立して動作する。これにより、Webアプリケーションにオフライン機能やプッシュ通知などを追加することができる。Service Workersはネットワークリクエストの処理を傍受して操作できる機能を負っているので、ここに情報漏洩のリスクがあるため、HTTPSが必須となっている。
Push API / Notifications API
Push APIはサーバーからブラウザへプッシュ通知を送信するためのAPIであり、Notifications APIはブラウザで通知を表示するためのAPIになるため、それぞれ単独ではプッシュ通知を行うことはできない。その橋渡しを前述したServie Workersが担っている。これもHTTPS通信でないと通知内容が漏洩する可能性があるので、HTTPSが必須となっている。
Clipboard API
JavaScriptを使用してプログラムでWebページ内からクリップボードにデータをコピーする時に使用される。Webページ上のボタンをクリックした時に自動的にテキストをコピーするなどに使用する。ユーザーがCtrl+Cを押す代わりをプログラムで実行している。Clipboard API自体は通信を行わないが、機密性が高い情報が操作されている可能性があるため、HTTPSが必須となっている。
Credential Management API
ブラウザに保存された認証情報をもとに自動的に認証を行うことができるため、ユーザーがパスワードを入力することなく、Webサイトにログインできるようになる。しかし、HTTP通信の場合はユーザー情報が漏洩する可能性があるため、HTTPS通信が必須となっている。
補足
- ローカルでの通信(http://loalhost)は開発者のために例外として許可されている
- 現状では新しいAPIは最初からHTTPS前提で設計されるようになっている
最後に
最近はHTTPS通信が当たり前になっていますが、オンプレのシステムで納入先のイントラネットが整備されていれば、いまだにHTTP通信を使用しているシステムも多くあると思います。そんなシステムでもHTTPS通信化しないと、使用できる機能(API)がどんどん減っていきそうですね。
次回は、HTTP通信からHTTPS通信に切り替える方法や、暫定的にHTTP通信でこれらの機能(API)を使用することができないかを調べてみようと思います