高級パーティーの屈強なドアマンを想像してみてください。誰かがゲストであると主張すると、ドアマンはその招待状をチェックし、リストにある名前と照合します。それが一致しない場合、その人はベルベットのロープを通過できません。しかし、ドアマンが仕事をしなかったらどうなるでしょうか?彼の失策により、パーティーに呼び込み者がオードブルを盗み、貴重品を盗む可能性があります。
もちろん完璧な例えではないが、FTCが信用情報会社Credit Karmaや映画チケットサイトFandangoと結んだ和解は、企業が機密情報の送信に使用される接続の認証と安全を確保するために設計されたオペレーティングシステムのデフォルト設定を上書きする場合の危険性を示している。
消費者がデバイスにアプリをダウンロードした後の動作は次のとおりです。暗号化された接続を確立するための業界標準プロトコルである Secure Sockets Layer (SSL) をドアマンとして考えてください。オンライン サービスがアプリに接続する必要がある場合、サービスはその ID を保証する SSL 証明書を提示します。アプリが証明書を検証すると、オンライン サービスはベルベット ロープを介して許可され、デバイスへの暗号化された接続を確立して、消費者が情報を送信できるようになります。 SSL 証明書と暗号化によるこのワンツーパンチの検証により、機密データを送信するためのより安全な方法が作成されます。
しかし、詐欺師は、なりすまし技術を使用して、いわゆる中間者攻撃を仕掛けることが知られています。アプリが SSL 証明書をチェックしない場合、攻撃者は無効な証明書を使用してドアに侵入し、接続を確立してアプリとオンライン サービス間で送信される情報を傍受する可能性があります。アプリを使用している人もオンライン サービスも、何が起こっているのかわかりません。
中間者攻撃などの脅威から個人情報の送信を保護することは非常に重要であるため、iOS および Android オペレーティング システムは、SSL を実装するための使いやすいアプリケーション プログラミング インターフェイス (API) を開発者に提供します。デフォルトでは、これらの API は SSL 証明書を自動的に検証し、証明書が無効な場合は接続を拒否します。
iOS と Android の両方のオペレーティング システムの開発者ドキュメントでは、デフォルトの検証設定を無効にしないよう特に強い言葉で警告しています。 iOS のドキュメントによると、SSL 証明書の検証に失敗すると、「安全な接続を使用することで得られるメリットがすべて失われます。結果として得られる接続は、偽のサーバーによるスプーフィングからの保護が提供されないため、暗号化されていない HTTP 経由でリクエストを送信するよりも安全ではありません。」 Android のドキュメントも言葉を切り詰めていません。SSL 証明書を検証しないアプリは、「公共の Wi-Fi ホット スポットでは誰でもユーザーを攻撃できるため、通信を暗号化していないのと同じことです。」 。 。 （そして）攻撃者はパスワードや個人データを記録することができます。」
FTCによると、Credit KarmaとFandangoはこれらの「そこには行かないでください」という警告を無視したという。 Credit Karma は、消費者がクレジット スコアを取得し、その他の金融データを監視できるようにする iOS アプリの開発中に、サービス プロバイダーがテスト目的で SSL 証明書の検証を無効にするコードを使用することを許可しました。しかしFTCは、Credit Karmaがデフォルト設定をオンに戻さずにアプリの市場投入を許可したと述べている。そのため、2012 年 7 月 18 日から 2013 年 1 月 1 日頃までの間、同社の iOS アプリは中間者攻撃に対して脆弱となり、ユーザーの社会保障番号、生年月日、信用報告書のデータが危険にさらされました。
CreditKarma はどのようにしてこの問題を発見しましたか? FTCによると、FTC独自の社内チェックや監視は行っていないという。訴状によると、ユーザーがCredit Karmaに連絡し、同社のエンジニアが2013年1月にアプリをアップデートしてデフォルト設定に戻すよう導かれたという。
しかし、クレジットカルマの話はこれで終わりではありません。しばらくして、FTC スタッフがこの問題について Credit Karma に連絡しました。その後初めて、社内チームがアプリの両方のバージョンのセキュリティ レビューを実行しました。それは複雑で、費用がかかり、時間がかかるものでしたか? いいえ、FTC によると、所要時間はわずか数時間で、費用はほとんどかからなかったそうです。そして、それが何を明らかにしたと思いますか？ 2013 年 2 月 – 後 Credit Karma は iOS の脆弱性について知らされていました。同社はまったく同じ問題を抱えたアプリの Android バージョンをリリースしました。このレビューでは、別のセキュリティ上の欠陥も明らかになりました。iOS アプリは、認証トークンとパスコードを安全でない方法でデバイスに保存していました。
Fandangoに対するFTCの訴訟では、同社も同様の失態で告発されている。 2009 年 3 月から 2013 年 3 月まで、Fandango アプリの iOS バージョンは SSL 証明書の検証に失敗し、システムのセキュリティのデフォルトを無効にしてしまいました。 FTCによると、Fandangoはリリース前にアプリがSSL証明書を検証し、クレジットカード番号、有効期限、セキュリティコードなどの消費者の個人データを安全に送信しているかどうかを確認するテストを行っていなかったという。はい、Fandango はアプリのリリースからまる 2 年後の 2011 年にいくつかの監査を委託しました。しかしそれでも、攻撃者が消費者のデバイスに物理的にアクセスした場合に生じる脅威のみを含めるように範囲を限定した。安全なデータ送信についてはテストされていません。したがって、Fandango はデフォルトをオーバーライドすることで導入された脆弱性を検出する機会を逃しました。
FTCは、Fandangoがセキュリティ問題を報告する有効な手段を持たなかったため、問題をさらに悪化させたと主張している。訴状によると、ある研究者は2012年12月に、すぐに利用できる唯一の方法であるカスタマーサービスのWebフォームを通じて同社に連絡した。研究者のメッセージには「パスワード」という用語が含まれていたため、Fandango の顧客サービス システムはそれを定期的なパスワード リセット リクエストとして扱い、定型メッセージで応答しました。その後、システムはセキュリティ警告を「解決済み」として無視しました。
Fandango が最終的に問題を解決したのはいつですか?訴状によると、同社がFTCスタッフから連絡を受けて初めて判明したという。その後初めて、Fandango は簡単なテストを実行し、アプリが SSL 証明書の検証に失敗したことを明らかにしました。 Fandango はまた、この脆弱性がサードパーティ向けにホストしている別の映画チケット アプリに影響を与えていることも発見しました。 Fandango は 3 週間以内に両方の iOS アプリのアップデートを発行し、デフォルト設定に戻し、そのセキュリティ ホールを塞ぎました。
Credit KarmaおよびFandangoとの和解案では、新製品および既存製品の開発と管理に関連するリスクに対処し、注文の対象となる情報のセキュリティ、完全性、機密性を保護するために、包括的なセキュリティプログラムを導入することが両社に求められている。他の和解と同様に、クレディ・カルマとファンダンゴは今後20年間、隔年ごとに独立した専門家による徹底的なセキュリティ監査を必要とする。もちろん、契約条項はこれらの企業にのみ適用されるが、賢明な企業は、Credit Karma と Fandango に何が求められているかを知るために提案された命令を読んでみるとよいだろう。和解案については、2014 年 4 月 28 日までにコメントを提出できます。
企業はこれらの事例から他に何を学ぶことができるでしょうか?
1. セキュリティのデフォルトを変更する場合は、細心の注意を払ってください。 企業が十分に放っておけば、オペレーティング システムのデフォルトのセキュリティによって消費者の個人情報が中間者攻撃から保護されていたでしょう。もちろん、デフォルト設定を変更することが常に違法であると言っているわけではありません。実際、「証明書の固定」として知られるさらに強力な認証方法を実装することで、デフォルトの SSL 証明書の検証をさらに上回る方法があります。しかし、セキュリティのデフォルトを変更するのは、アプリ開発における頭脳手術です。企業は自分たちが何をしているのかをしっかりと把握する必要があります。
2. アプリをリリースする前に徹底的にテストします。 大工には「二度測って、一度切る」という古い格言があります。アプリ開発者にとっての当然の結果: アプリのセキュリティをテストするために、すぐに利用できる無料または低コストの方法を活用する 前に それを消費者の手に渡すのです。
3. 人々があなたのアプリをどのように使用するかを考慮します。 モバイル環境で SSL が非常に重要であり、iOS および Android の開発者向けドキュメントでこれほど重要視されているのには理由があります。それは、人々がセキュリティで保護されていない公共 Wi-Fi ネットワーク上でモバイル アプリを使用することが多いためです。チェスプレイヤーと同じように、開発者は数手先を考える必要があります。アプリをリリースする前に、ユーザーがそのアプリをどのように使用する可能性があるかを熟考し、現実世界の考慮事項を念頭に置いてアプリを保護してください。
4. あなたは、他の人があなたに代わって行うことに対して責任を負います。 訴状によると、Credit Karma は、リリース前のテスト中に SSL 証明書の検証プロセスを無効にすることをサービスプロバイダーに許可したが、その後セキュリティ設定が復元されるよう配慮しなかった。最初の懸念事項: デフォルトをオフにしなくてもテストを実行できた可能性があります。しかし、それでも、企業が消費者がアプリを入手する前に、すべてがアップルパイの順序に戻っていることを確認することが非常に重要です。
5. 耳を地面に近づけてください。 潜在的なセキュリティ脆弱性に関する情報を共有する活発な研究コミュニティが存在します。しかし、深刻な警告に対して標準的な「トコジラミの手紙」で対応したことで、ファンダンゴは問題を解決する機会を逃した。知識のある人に連絡を取りましたか あなたの 最近、潜在的なリスクについて会社に相談しましたか?そして、そのメッセージはメールボックスに未読のまま放置されているでしょうか?
6. 利用可能なリソースを調べます。 FTC のパンフレット「Mobile App Developers: Start with Security」では、この種の脆弱性からの保護について企業にアドバイスを提供しています。
ユーザーを保護するために、開発者は SSL/TLS を HTTPS の形式で展開することがよくあります。 HTTPS または別の業界標準の方法の使用を検討してください。車輪を再発明する必要はありません。 HTTPS を使用する場合は、デジタル証明書を使用し、アプリがそれを適切にチェックしていることを確認してください。信頼できるベンダーが提供する飾り気のないデジタル証明書は安価であり、顧客が他人のサーバーではなくあなたのサーバーと通信していることを確認するのに役立ちます。ただし、標準は変化するため、現在のテクノロジーに常に注目し、最新かつ最高のセキュリティ機能を使用していることを確認してください。
FTC のプライバシーとセキュリティ ページをブックマークし、より安全なアプリの開発に関する無料の情報については、他の公的情報源を参照してください。
