それほど害が及ばないセキュリティ欠陥は許容できますか？
最近、私はビジネスWebサイトにセキュリティ欠陥を発見しました。このWebサイトにはパスワードで保護された「パートナーエリア」があり、多くのWebサイトと同様に、ユーザーのパスワードをリセットするフォームを提供しています。
ユーザーがニックネームのパスワードのリセットを要求すると、新しいパスワードがメールアドレスに送信され、そのパスワードはすぐに有効になります。問題は（これがまだ問題ではなかった場合）、すべてのユーザーに対して新しいパスワードが固定されたパスワードであることです。したがって、攻撃者はどのアカウントにも簡単にアクセスできます。
現在、パートナーエリア内でユーザーが実行できる操作は次のとおりです。
- メールアドレスの表示/変更
- パスワードを変更する
- いくつかのマニュアルとユーティリティをダウンロードします（それは明らかに分類されたものではありません）
- 修理フォームに記入します（その後、プロセスはメールで続行されます）
- マーケティング目的でロゴと画像をダウンロードする
悪意のある攻撃者が悪用するために私が見る唯一のものは次のとおりです。
- 正当なユーザーへの今後のアクセスを防止します（おそらく、電話の直後に再度取得できます）。
- 会社の顧客が誰であるかに関する情報を見つけます（ランダムなニックネームを推測し、メールアドレスを確認します）。とにかく、それは誰かが秘密にしておくものではありません。
私はいつもこのようなことに非常に悩まされていますが、この場合、それは大したことではないかもしれないことを認めなければなりません。このような欠陥は、それほど危害を加えることができない状況で、許容できる妥協点ですか？
誰かが詳細を誤解していると思うので、そのWebサイトは外部の会社に属しています。そのWebサイトの開発には責任がなく、それに関する決定を制御することはできません。
あなたの質問は次のとおりです：セキュリティの欠陥がそこから派生する害がほとんどない場合、受け入れられますか？
結果を理解しながらビジネスが決定した場合、答えはyesです。
あなたがしていることはリスク評価と呼ばれます。リスクごとに、インスタンス化されたときの会社への影響を強調する必要があります。その評価に基づいて、あなた（あなた= ビジネス決定を下す権限を持つ人）には3つの選択肢があります。
- accept it-それを修正するコストは結果の価値がないと仮定することによって
- mitigate it：結果を受け入れることができるように修正します
- insureそれに対して-リスクを他の誰かに効果的にオフロードできます。
ご想像のとおり、リスク評価にはいくつかの重要な領域があります。
1つ目は、結果と確率の評価です。それを行う方法についての本や記事は数多くありますが、結局のところ、これは激しい手振りと経験に基づいています。本のような出力は決してありません
これが発生する確率は76％で、126,653ユーロかかります
むしろ
まあ、これは私たちが対処すべきリスクだと思います
「結果」の部分は定量化できる場合がありますが（たとえば、オンラインコマースの利益の損失）、定量化できない場合があります（たとえば、会社のイメージの損失）。
リスク評価の疑わしい理論的側面に加えて、常に活用すべき大きな利点が1つあります。それは、リスクをテーブルに置き、何らかの方法で対処する必要があることです。
これは、貴族の名前を失った場所であるだけでなく、情報セキュリティへの取り組みがどこに向かうべきかを強調するための適切なツールです。また、可視性を高め（可視性を上げることができるプロアクティブなケースはそれほど多くありません）、重要なものとそうでないものについて、ハードで深く実用的な見方を強いられます。
はい。これは問題です-大きな問題です。最近、私は他の訪問者のチャートに無実のメモを挿入することを可能にするビジネスのウェブショップにデザインの欠陥を見つけました。
さらに調べてみると、これらのメモにJavascriptコード（XSS）を挿入することもできるようになるまでは、無邪気でイライラしているように見えます。つまり、言い換えれば、すべての訪問者のグラフでXSSを利用できます。私は、その設計上の欠陥、XSS、BeEF、およびMetasploitを使用して、どのような訪問者（この場合は、私自身はPoC）のコンピューターを簡単にハッキングできるかを示す簡単なPoCを作成しました。
したがって、小さな欠陥でも、結局大きなリスクにつながる可能性があります。
その上、あなたが見つけたエラーはそのウェブサイトの開発者が作った唯一のものだと誰が言っていますか？たぶん彼は他にもたくさんの間違いを犯しました。
レポートは、それが不必要に見えても、実行できる最善の方法です。
このような単純なパスワードリセットスキームで見られる問題は、プラットフォームのさらなる脆弱性を示唆していることです。セキュリティの欠陥のある概念は、1回だけ発生するほど孤立していることはめったにありません。そのような欠陥は通常、セキュリティに関する開発者の慣行に関連しているためです。少なくとも、内部のログイン手順にも同じ欠陥があり、攻撃者が通常アクセスすべきではないデータベース、コード、プロセスにアクセスできる可能性があるのではないかと思います。
そこから、サーバーのコードを変更してクリアテキストのパスワードを報告したり、追加の個人情報を収集したり、さらに別のシステムへの攻撃を許可したりすることが可能です。結局のところ、これは2016年ですが、Facebookアカウントと同じパスワードを使用しているという明らかなリスクはありますが、Facebookと同じパスワードを使用している人はまだたくさんいます。そうでない場合でも、ニックネームを電子メールアドレスに関連付けることができると、ユーザーが他のアカウントにリスクを及ぼす可能性があります。攻撃者がユーザーアカウントについて知っている情報が多いほど、同じ人物が所有している他のアカウントを破壊しようとする攻撃をより多く利用できます。
少なくとも、サイトの所有者に連絡して、問題が解決するかどうかを確認することをお勧めします。解決しない場合は、どうしても必要な場合を除き、アプリケーションを使用しないことを検討してください。また、ユーザーアカウントのメールを、気になるメールアドレスに接続されていない使い捨てアカウントに変更することをお勧めします。私たちはもはや、どうやらマイナーな欠陥が後で私たちを悩ませるために戻ることはないと想定できる時代ではありません。
このシナリオが正しければ、彼らは任意のアカウントの電子メールアドレスとパスワードを変更してから、修復フォームを開始し、メールで修復プロセスを続行できます。
サポートチームはおそらく、メールアドレスは正当であり、機密情報は受信者と交換できると想定します。それが既知の顧客であれば、Webサイト/メールで受け取った注文に取り掛かることさえできます。
別の問題は、連絡先の履歴や修理注文の履歴にアクセスできるかどうかです。顧客が修理注文に機密情報を書き込んだのでしょうか、それとも注文の数とタイプでさえ、ビジネスの問題を明らかにする可能性があるものでしょうか？
別の問題は、顧客のメールアドレスの大量のスパムである可能性があります。パスワードのリセットを100万回呼び出すと、ユーザーに100万通のメールが送信され、受信トレイがいっぱいになるだけでなく、いくつかのスパムフィルターリストが表示されます。サーバーを取得するのはかなり面倒です。その後、これらのリストから削除されました。
もちろん、ニックネームを列挙し、すべてのアカウントパスワードをリセットできれば、DoSは非常に簡単です。
しかし、最大の問題は誤った安心感です
今ある角度や問題を見落としているのかもしれません。しかし、今は問題がなくても、来年誰かがこのページに新しい機能を実装することを決定した場合はどうなりますか？多分顧客がオンラインで注文/支払うために。 -ユーザー名とパスワードでのみアクセスできるコンテキストを提供し、人々と開発者はそれに依存します。誰もが「これはアプリケーションの安全な部分であり、顧客だけがアクセスできるので、Xを実行してYに依存できる」と考えるでしょう。
アプリケーションが実質的に公開されている場合、それはそのように見えるはずです。アプリケーションが安全に見える場合、安全でなければなりません！
ここには2つの視点があります。
- ユーザーとしては、ええ、心配です。所有者に知らせます。そのサイトで機密情報を共有することは控えます。
- サイトの所有者または開発者は、潜在的なセキュリティリスクが努力を正当化できるほど深刻であるかどうかを評価する責任があります。すべてのリスクが、発生の可能性、違反の影響、およびリスクを制御するために必要な努力によって判断される、アクションを正当化するのに十分なほど深刻であるとは限りません。
この場合、（推測では）次のものが得られます。
- 重大度：低
- 可能性：中程度
- 努力：低
そして、彼らはおそらくすべきそれについて何かをします。彼らが問題に気づいていない可能性が非常に高いです。
一般的なケースでは、あなたの質問に答えて、「セキュリティの欠陥は、そこからもたらされる害がほとんどない場合、許容可能ですか？」 -はい、可能です。重大度/可能性/努力のトレードオフが問題を修正する価値があるかどうかを判断する必要があります。 「リスクを受け入れる」は、多くの場合、完全に合理的な対応です。
極端な例として、「強力な暗号を破ることができるエイリアンが地球を訪問する」は、私のビジネスが直面しているリスクです。発生する可能性が非常に低く、価値がないので、私はそのリスクを制御しないことを選択します。
これは良い質問で、簡単に答えることはできません。
すべてのセキュリティリスクはそれだけですリスク。そして、そのリスクに対処するには、コスト、混乱、リスクの危険性を、提案された修正と比較検討する必要があります。
特定の質問を見ると、サイトに「プライベート」な部分があり、そこにいくつかの情報がありますが、サイトのその部分にアクセスする人から実際に害が及ぶことはありません。また、セキュリティホールでは、ハッカーがすべてのパスワードが同じものにリセットされていることと、それが何であるかを知っている必要があります。
したがって、現在、今日、あなたの最大のリスクはゼロであるか、少なくとも低いです。
明日、最大のリスクは、プライベートセクションに機密情報が含まれる可能性があることです。
「修正」のコストはかなり小さいようです。特に、新しい「固定」パスワードをすでに郵送している場合。基本的に、パスワードの割り当てをランダムに変更するだけで、今のところ問題は「修正」されています。それは最高ではないかもしれませんが、それはより良いです。
したがって、修正コストは低くなりますが、セキュリティ上の危険性は低くなります。それをビジネスニーズと比較検討し、価値があるかどうかを判断する必要があります。
企業はその固定パスワードを信頼している可能性があることに注意してください。たとえば、サポートスタッフは、パスワードをリセットし、電話でユーザーに新しいパスワードを伝え、彼らが入ることができるまで一緒にいて、パスワードの変更を手助けするように訓練されている場合があります。コストを計算するときは、これを考慮する必要があります。
私がすること：
バグやセキュリティの問題を見つけたら、それを文書化し、修正するための開発コストを見積もります。次に、それをリストに追加して、適切な人々に知らせます。リストから外れることは決してないかもしれませんが、年に1回（または6か月ごとに）サイトの所有者とそのリストを確認し、私ができる問題に対処します。
このリスクがあると、すぐには修正されない可能性があります。多くのビジネスニーズが最初に来るのを見ることができましたが、それは問題ありません。しかし、少なくともそれは文書化されており、誰かがサイトのその部分に「秘密の」情報を入れたいと言ったら、私は彼らにリスクについて話すことができます。
このタイプのリスクは他のタイプのリスクにつながる可能性が高いことにも注意することが重要です。これがコード化されたとき、悪いセキュリティ決定がなされました。サイトは他の悪い決定がないかチェックする必要があります。
ソーシャルエンジニアリングベースの攻撃を開始するには、顧客から正当なユーザー（ある程度信頼されているものとして扱われる）を偽装するのが良い方法です。
修理フォーム->電子メールプロセスは、電子メールアドレスを管理している場合に最適です。おそらく、同様のドメインを購入して、「[email protected]」->「[email protected]」のメールアドレスを変更できます。これは、「カナダの子会社に移管したばかりなので、レコード、思い出させてくれませんか...？」
顧客/サプライヤーの履歴に関する少しの情報を得ることができれば、さらに顧客にサプライヤーを偽装することができます。多くの場合、これは「数か月前に訪問したサービスエンジニアの名前は何ですか？彼らは特定の問題で明らかに非常に役に立ちましたが、私は不在であり、私の同僚がそれらに対処しました」と尋ねるだけです。
いいえ、ユーザーがそのサイトにアクセスした場合、ユーザーはニックネームを使用して誰かのメールにアクセスできます機密データ、一部の国ではこれで十分ですNOTIFY ALL USERS誰かがDBに侵入でき、情報漏えいがあったこと。 これは信頼性と訴訟へのオープンの両方に影響を与えます。
したがって、一般にセキュリティ上の欠陥は許容されますが、これは許容可能なセキュリティ上の欠陥ではない可能性があります。また、これにより、ユーザーが突然受信する可能性のあるあらゆる種類のスパムに開放されますマルウェアおよびスパムメール。
ハッカーは常に発見した欠陥を（彼らのために）うまく利用できるように創造的です。ユーザーの身元は重要な情報ではないと想定しているが、それが不正行為のWebサイトの例である場合はそうかもしれない。また、あるユーザーが宗派/カルトに対して積極的に宣伝していて、カルトのメンバーが突然自分の身元を知ることができた場合はどうなりますか？ストーカーの犠牲者が明らかにされ、そのおかげでストーカーが彼を再び見つけることができる場合はどうなりますか？
ユーザーに警告せずにIDを漏らすことはプライバシー違反なので、注意してください。欠陥は発見され次第、修正してリスク分析する必要があります。
たとえば、私のメールアドレスへのアクセスを誰かに許可するよりも、すべてのフォーラム投稿が削除されることを望みます。
開発者は、ユーザーよりも実際のセキュリティリスクをよく理解しているかもしれません。ユーザーが自分のアカウントが乗っ取られていることに気付いた場合、権限のないユーザーが実際にアクセスできる情報よりも多くの情報にアクセスした可能性があると思われる場合があります。機密情報が実際に公開されていなくても、あなたの会社は評判の打撃を受ける可能性があります。
また、漏えいしても害のない情報がわからない場合があることも考慮してください。たとえば、ユーザーが競合する会社が理解しようとしている新しい革新的な製造プロセスがある場合はどうなりますか？新しいプロセスで使用された特別な機器を修理する必要があり、その電子メールが変更された場合、修理の注文により、他社に新しいプロセスが何であるかがわかる場合があります。
それは単純な修正のように聞こえ、最終的にはリスクを修正するコストに見合うリスクかどうかを確認するためにその評価を行う必要があります。