登録時にほぼ同じメールアドレスを許可することはセキュリティ上の問題ですか？
次のすべての電子メールアドレスのアカウントを作成できるWebサイトがあるとします。
'[email protected]'
'[email protected] '
'[email protected];'
'[email protected];[email protected]'
これはセキュリティ問題と考えるべきですか？ [email protected]としてログインしているときに[email protected];sデータにアクセスできるかどうかをテストしましたcannot。
非常によく似たメールアドレスを使用して作成されたアカウントにアクセスできないという事実にもかかわらず、これは少なくとも奇妙でおそらくセキュリティの問題につながる可能性があるようですが、特定のセキュリティの問題は考えられません結果として発生する可能性があります。
誰もがこのセットアップがもたらす可能性のある特定のセキュリティ問題を提案できますか？
このアプローチの最も重要な問題は、あなたの例では、最初の1つだけが実際には構文的に有効な電子メールアドレスであることです。他の3つは違います。つまり、次の2つのオプションのいずれかが成り立ちます。
「メールアドレス」は単なる提案です。システムは一意のログイン識別子を必要としています。電子メールアドレスは、ユーザーが覚えているため、適度な識別子であり、電子メールシステムはすでに世界的な統一性を保証しています。
電子メールアドレスは、実際には電子メールアドレス（たとえば、そのアドレスに電子メールを送信するため）であると想定されており、レジストリシステムは、ユーザーが入力したものが電子メールアドレスであるかどうかの検証に完全に失敗します。
後者の場合、これは電子メールの伝達に失敗し、ユーザー入力の検証に関して開発者がずさんであることを意味します。これは、一般的に言えば、セキュリティの良い兆候ではありません。
ただし、識別子が自由形式である場合は、人間のユーザーの創造性の結果です。ログイン識別子が何のために使用されているかは問題ではありません。スペース、セミコロン...は、適切に実装されていないスクリプトやアプリケーションを破壊する可能性があります。 （SQLインジェクションが発生する可能性がある場合は、単一引用符を含むアカウント名で登録してください。）
最初のメールアドレスのみが実際に有効なアドレスです。もちろん メールアドレスの検証は難しい なので、完全な検証を実装しようとしても意味がありません。最大で、おおよその検証を行うことができます。また、使いやすさの理由から、フィルターには寛容である必要があります。このため、電子メールアドレスの有効性に基づいてセキュリティを設定しないでください。
それでも、登録にメールアドレスが必要な場合は、通常、そのアドレスに確認リンクを送信します（タイプミスなどを防ぐため、これを行わないことは実際にはセキュリティ上の問題と見なされる場合があります）。これにより、シナリオが不可能になります。
どちらにしても、これはセキュリティの問題ではありません。 あなたの認証は同様の名前に対処できるはずです、そうでなければそれは間違っています。
ただし、最初と最後のスペースには注意が必要です。スペースが途中で切り取られることがよくあり、実際に問題が発生する可能性があるためです。
それ以外には、わずか2つの小さな問題があります。
- タイプミス：ユーザーがいる可能性があります
[email protected]:123456とユーザー[email protected]:123456。そのうちの1人が誤って資格情報をタイプミスした場合、他のユーザーのアカウントになってしまう可能性があります。しかし、これはかなりの偶然であり、ユーザビリティの理由から、私はそれに対して防御しようとはしません。 - 識別：ユーザー名の代わりにメールアドレスを表示して、ユーザーが別のユーザーを模倣できるようにすることができます。例えばあなたの例では
[email protected]および[email protected]は区別が困難です。しかし、これもまた一般的なケースです。通常、ユーザー名は識別のために表示され、メールアドレスではありません。
最初のものを除くすべては、有効な電子メールアドレスではないという理由だけで拒否されます。
それらを好きなメールクライアントにそのままコピーして貼り付けると、それらはmightが期待どおりに動作しますが、最も可能性の高い動作は、それらをすべて同じように解釈することです。したがって、ユーザーを一意に識別するメールアドレスが必要な場合は、登録フォームに構文的に正しいメールアドレス（正確に1つ）を入力するように強く主張する必要があります。
ほぼ同一の電子メールアドレスの登録を許可しているプロバイダーに起因するセキュリティの問題は間違いなくあります。しかし、それはあなたの特定の例がテストしているものではありません。そして、その影響は必ずしも電子メールサービスのユーザーに限定されるものではなく、より広範囲に影響を与える可能性があります受信そのサービスのユーザーからのメール。私が話している危険は、メール受信者へのサービスのユーザーのなりすましを伴う危険です。
意味を理解するために、まず有効なメールアドレスと有効でないメールアドレス、およびユーザーのIDが実際にユーザーの外部メールアドレスと同じであるかどうかについての交絡の問題（既に十分に説明されています）を脇に置きましょう。代わりに、次のシナリオを見てみましょう。
攻撃者は、ジェーン・スミスのコンピューターにマルウェアを埋め込むことを望んでいます。攻撃者は、ジェーンスミスの電子メールアドレスを知り、ジェーンスミスがジョンアンダーソンと親しい友人であることを知り、ジョンアンダーソンがウェブメールプロバイダーmail.com（[email protected]）とアクティブな電子メールアドレスを維持していることを知っています。攻撃者はmail.comの登録プロセスを確認し、このサービスにより[email protected]（大文字なし）を有効なアドレスとして登録できることを喜んで発見します。攻撃者は、アカウントの「差出人」名を「ジョンアンダーソン」に設定し、ジェーンスミスを標的としたスピアフィッシングメールの作成を開始します。攻撃者は、PDF John AndersonとJane Smithの両方が相互に興味深いと思われる種類のアイテムのように見えるインターネット上のドキュメントを見つけ、次に [〜＃〜] set [ 〜＃〜] その文書にPDFエクスプロイトと悪意のあるペイロードを挿入します。
攻撃者がメッセージを送信します。ジェーン・スミスの最後に、彼女はアドレス "[email protected]"で "John Anderson"からメールを受信します。このメッセージは、PDF記事に転送され、Johnが1文で推奨しているメッセージです。「これで終わりです。読む価値があると思います。すべてに同意するかどうかは不明です。著者のポイントですが、非常に興味深いものです。」そして、mail.comはメッセージが実際にはそのアドレスから送信されたものであることを暗号で証明しているため、Jane Smithのメールサービスは、メッセージをスパムフォルダに送るのではなく、受信ボックスに送りました。 （攻撃者が単に「from」アドレスを偽装しただけの場合に発生する可能性があります）。
修辞的な質問：ジェーン・スミスが開く可能性はどのくらいですかPDF添付ファイル？
回答：ヤスでの漁攻撃で得られる程度の高さ。 （少なくとも、雇用主の電子メールシステムにアクセスしたり、上司になりすましたりすることなく、またはそれらに沿って何かを。）
一般的なユーザーがJohnAnderson @ mail.com、johnanderson @ mail.com、または[email protected]でさえ同じ送信者ではないことに気づく可能性はかなり低いです。 （ユーザーが一般に非常にセキュリティを意識している場合は、明らかに検出の可能性が高くなります。一部のユーザーが想定しているほどではないと思われます。）攻撃者がなりすまそうとしている実際の人物の実際の電子メールアドレスが既にある場合攻撃者の電子メールが届く前に受信者のアドレス帳で、受信者は、この特定のメッセージの送信者is n'tがあるというメッセージ通知を受信すると、受信者が期待するとおりに（可能性があります） 。そして、彼または彼女は、少し疑わしいと思うかもしれません。その一方で、彼または彼女は、おそらく、特派員が何らかの理由でわずかに異なる新しいアドレスからメールを送信していたと仮定します。または、彼/彼女の電子メールサービスのアドレス帳機能が厄介でした。または...
ポイントを得る：このフィッシングメールの偽装手法は、フィッシング/スピアフィッシング攻撃において非常に強力な（見過ごされている場合でも）ものです。
メールプロバイダーができることと、非常によく似たアドレス登録を禁止しようとする意思がある場合、メールプロバイダーが望んだとしても効果的に戦うことは難しい習慣です。また、特定のメールプロバイダーは、潜在的なユーザーの登録に「申し訳ありませんが、そのアドレス/ユーザーIDはすでに使用されています」と伝えたいと考えています。できるだけ少ない回数（十分なメッセージを受け取った場合、あきらめて、希望する名前の1つが無料かどうかを確認する）メールサービスのインセンティブは、事実上技術的に有効なメールアドレスの登録を許可することです（例外）。
最初のメールアドレスが唯一の有効なものであると述べて、他のすべての人に同意します。また、ログオン名の末尾にスペースを追加することはお勧めできません。私がこれを正しく理解している場合は、システムへのユーザー/顧客のログオンの潜在的な類似点を指摘しようとしています。
だからあなたの質問に答えて：「これはセキュリティの問題と見なされるべきですか？」私の答えは、いいえ、追加のスペースが含まれていないものです。そうでなければ、はい...しかし主に以下の理由で。
あなたの質問; 「このセットアップがもたらす可能性のある特定のセキュリティ問題を誰かが提案できますか？」私の頭の上のところでは、私が現在気付いているものよりも潜在的にいくつかある可能性がありますが、私が考慮する唯一のことは、ある種の注射の種類の問題についてです。しかし、それはあなたのコーディングで追加のスペースがどのように定義されるかにかかってきます。十分にロックダウンされていれば、問題はないはずです。しかし、繰り返しになりますが、あらゆる種類の技術が常に変化する方法で活用されています。したがって、本当に完全に安全なものはありません。したがって、より良いセキュリティを望み、それを達成することを試みることができます。