今後WebシステムをインターフェースとするIoTデバイスが続々と出てくると思われます。その中で特に危惧しているセキュリティ問題があります。その１つがリクエストフォージェリです。

リクエストフォージェリとは？

リクエストフォージェリと聞いてCSRF（クロスサイトリクエストフォージェリ）を思い浮かべる方はWeb開発者でしょう。リクエストフォージェリについては既にリクエストフォージェリ – SSRFとCSRFを書きました。簡単に言うとシステム／ユーザーが持っている権限を利用して不正に機能を使う攻撃です。認証／認可を正しく管理していても、システム構成やプロトコルなどによって権限を悪用できる脆弱性ががリクエストフォージェリです。

Web開発者が注意しなければならないリクエストフォージェリはCSRF（あえてクライアントサイドリクエストフォージェリとします）だけではありません。SSRF（サーバーサイドリクエストフォージェリ）にも注意が必要です。

実際に攻撃されているSSRF

SSRFは実際の攻撃に利用され、SAPやSCADAなどの脆弱なシステムに対して有効であることが知られています。SSRFは現実の脅威であり、Webシステム開発者が注意しないと将来のIoTデバイスの脅威にもなります。

リクエストフォージェリに脆弱なデバイスへの攻撃

IoTデバイスはWebサーバーになります。現在考えられている標準規格のアーキテクチャーは以下のようなものです。

フレームワークなどはセキュリティを十分考慮して作られるものと思いますが、プラグインなどは自由に開発できます。フレームワークがあるからといっても、普通のWebアプリケーションフレームワークと同じく、何もセキュリティを考えないで使って良いものではありません。

DeviceConnectのGitHubドキュメントには以下の説明が記載されています。

DeviceConnect WebAPI について

Device Connect WebAPIはスマートフォン上で仮想サーバとして動作するWebAPIで、様々なウェアラブルデバイスやIoTデバイスをWebブラウザやアプリから統一的な記述で簡単に利用することができます。

• 動作環境として、Android、iOSに対応しています。WebブラウザとしてはChrome、Safari(擬似的な仕組み)、Firefoxで動作を確認しています。
  ※それぞれの動作環境で利用できる対応デバイスは異なります。
• 仮想サーバによるREST/WebSocketのWebAPIにより、任意の開発環境がご利用いただけます。
• コンテンツ開発を容易にするために、Javascript用SDK、Android用SDK、iOS用SDKを用意しています。
• 機能拡張のためのプラグイン開発用SDKを用意しております。任意のWebAPI機能の追加が可能です。
• 同じローカルネットワーク上にあるDeviceConnect WebAPIがセットアップされたAndroid端末も設定変更で利用できます（セキュリティ上のリスクについてご留意いただく必要があります）。

当然ですが、セキュリティに関する注意事項も書かれています。

外部からのアクセスについて

• demoWebSiteのURLにIPアドレスのパラメータを付加することで、ローカルネットワーク上の他の端末で動作するDeviceConnect WebAPIの操作も可能になります。ただし、操作される側の端末に以下の設定が必要です。※遠隔で意図しない端末の操作およびデータ参照をされるリスクが伴います。信頼が出来ないローカルネットワーク環境では利用しないでください。

1. 上記の動作確認と同様の手順で、操作対象の端末にDeviceConnect WebAPIをセットアップしてください。
2. DeviceConnectManagerをAndroidのランチャーから起動し、DeviceConnectManagerを一旦OFFにしてください。
3. Allow External IPのチェックを有効化し、DeviceConnectManagerをONにしてください。
4. 操作する側（PC等）のdemoWebSiteからHTMLを開き、操作対象のIPアドレスのパラメータを付加してください。

    [例] file:///C:/demoWebSite/demo/index.html?ip=192.168.13.3

※遠隔で意図しない端末の操作およびデータ参照をされるリスクが伴います。信頼が出来ないローカルネットワーク環境に接続される可能性がある場合はDeviceConnectManagerのAllow External IPのチェックを無効化してください

SlideShareの標準化動向を見ると、さまざまな団体が様々な規格を作っていることが分かります。リクエストフォージェリを利用すれば攻撃可能になってしまうデバイスも出てくることが予想されます。

こういった標準化団体のフレームワークに則ったIoTデバイスならまだマシだと思います。これらを使わなくてもIoTは可能です。ほぼPCやスマートフォンと変わらない小型デバイスが続々発表されています。これらは必ずしも比較的セキュアなIoTフレームワークを利用しなくても構いません。普通のサーバーの様に構成し、上で動作するアプリは普通のWebアプリケーションのように作ってしまうことも可能です。

脆弱なWebシステムに対するSSRFはHTTPリクエストのリダイレクトで簡単に行えます。オープンリダイレクト（URLをバリデーションせずにリダイレクトする問題）はセキュリティ問題として知られています。経験のあるWeb開発者であればオープンリダイレクトは行わないと思いますが、IoTデバイスを開発する開発者がWebアプリケーションに詳しいとは限りません。また”ローカルネットワークなら安全”と誤った仮定をするかも知れません。

HTTPリダイレクトにホストやIPをチェックしているアプリでも、パラメータまではチェックしていないWebアプリがほとんどです。不要なパラメータが付加されていないかチェックしていないWebアプリは潜在的に危険です。リスクを軽減するためにもWebアプリのパラメータは入力直後に、不必要なパラメータの有無も含め、厳格にバリデーションしてから全ての処理を行うべきです。

Webサーバーを利用しなくてもJavaScriptを利用して様々な攻撃も可能です。CORSも問題になりますが、JSONPを利用するだけでも脆弱なシステムなら簡単に攻撃できます。JavaScriptでLANをスキャンするjslanscannerのような便利なツールもあります。

Webブラウザから攻撃できるなら、IoTのWebサーバーにも対応は必要ない、と考えるのはプロフェッショナルな作り方ではないと思います。プロなら不正なリクエストはそもそも受け付けないのは勿論、不正なリクエストを記録し、ユーザーが一覧できるような仕組みを作っておくべきです。こうするだけでユーザーが行いの悪いデバイスを少しでも早く見つけることを手助けできます。

参考：

• ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイド

色々やってもIoTが攻撃者にとって宝の山のような存在になることは避けられないと思います。少なくとも自分がIoTデバイスのWebアプリ部分を作る機会があったら、脆弱なプログラムを作らないように心がけて頂きたいです。

まとめ

書きかけのような中途半端なブログですが、書かないブログなのでご容赦ください。要するに言いたい事は、今後続々登場するIoTデバイスによって家庭内／企業内LANのセキュリティはどんどんリスクが増す、ということです。

リクエストフォージェリに気をつけるべき、と考え言っている私自身でさえWebサーバーからファイアーウォールの制御を行っているスクリプトに関してはIPベースで操作を許可しています。（これは近日中にHTTPS+API KEY方式に変えるつもりです）管理者が完全に全てのデバイスを管理／制御している環境ならこれでも一応の安全性は維持できますが、様々なIoTデバイスが管理されていない状態でネットワークに接続される状況を想像してみてください。リクエストフォージェリの脅威が無視できないほど大きいリスクであることが解ると思います。（完全な乗っ取りは更に怖いです。例えば2012年のBlackHatではHTML5対応ブラウザだけでルーターファームウェアを書き換えて完全に乗っ取る方法（PDF）も公開されています）

ということでSOHOでも家庭内でもVLANが必要になる時代になってきたと思います。一昔前ならVLANと高価なイメージでしたがNetGearのVLAN対応HUBはとても安価でVLAN無しHUBとあまり変わりません。私もこのシリーズを使っています。お勧めです。

備考：Unmanaged+とUnmanagedの2種類があります。Unmanaged+の方がVLAN対応です。Unmanagedの方を買う意味はあまりないと思います。

こういったVLAN対応HUBやVLAN対応WiFiアクセスポイントやポートベースVLANを使ってWiFiアクセスポイント使い分ける、などの環境構築は素人にはほとんど無理でしょう。マルチSSIDで使い分けする、くらいが現実的だろうと思いますがこれさえも難しいと思います。

参考

• https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Cross_Origin_Resource_Sharing
• https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny