トークンパラメータ付きのhttps URL：どのくらい安全ですか？

StackOverflow https://stackoverflow.com/questions/643355

  •  22-07-2019
  •  | 
  •  

質問

私たちのサイトでは、個人情報に基づいたシミュレーションをユーザーに提供します（フォームで提供）。後でログイン/パスワードアカウントの作成を強制せずに、シミュレーション結果を後で取得できるようにします。

結果を取得できるリンクを記載したメールを送信することを検討しました。ただし、プライベートデータが危険にさらされているため、当然このURLを保護する必要があります。

したがって、URLでトークン（40文字の文字と数字の組み合わせ、またはMD5ハッシュなど）を渡し、SSLを使用する予定です。

最後に、彼らはそのようなメールを受け取ります：

  

こんにちは、
  結果を取り戻す    https://www.example.com/load_simulation?token=uZpxNyXyXYXYXYXJXXXXXXXXXXXXXXXXXXXXXXXXJXT

あなたはそれについてどう思いますか？十分に安全ですか？トークン生成のために何をアドバイスしますか？ httpsリクエストでURLパラメータを渡すことはどうですか？

役に立ちましたか？

解決

SSLは、送信中のクエリパラメータを保護します。ただし、メール自体は安全ではないため、メールは宛先に到達する前に任意の数のサーバーに沿ってバウンスする可能性があります。

また、Webサーバーによっては、完全なURLがログファイルに記録される場合があります。データの機密性によっては、IT担当者にすべてのトークンへのアクセスを許可したくない場合があります。

さらに、クエリ文字列を含むURLがユーザーの履歴に保存されるため、同じマシンの他のユーザーがURLにアクセスできます。

最後に、これが非常に安全でないのは、URLがすべてのリソース（サードパーティのリソースも含む）のすべてのリクエストのRefererヘッダーで送信されることです。たとえば、Googleアナリティクスを使用している場合、URLトークンをすべてGoogleに送信します。

私の意見では、これは悪い考えです。

他のヒント

そのためにCookieを使用します。ワークフローは次のようになります。

  1. ユーザーが初めてサイトにアクセスします。
  2. サイトはCookieを設定します
  3. ユーザーがデータを入力します。データは、Cookieに保存されているキーを使用してDBに保存されます。
  4. ユーザーが退出したら、https：リンク付きのメールを送信します
  5. ユーザーが戻ってくると、サイトはCookieを検出し、ユーザーに古いデータを提示できます。

今、ユーザーは別のマシンで別のブラウザーを使用したいと考えています。この場合、「転送」を提供します;ボタン。ユーザーがこのボタンをクリックすると、「トークン」が取得されます。彼女は別のコンピューターでこのトークンを使用して、Cookieをリセットできます。このようにして、ユーザーはトークンをどの程度安全に転送したいかを決定します。

SSLは転送中のデータのコンテンツを保護しますが、URLについてはわかりません。

とにかく、そのURLトークンを再利用する攻撃者を軽減する1つの方法は、各トークンが1回しか使用できないようにすることです。正当なユーザーが引き続きリンクを使用できるようにCookieを設定することもできますが、最初のアクセス後はCookieを持っているユーザーに対してのみ機能します。

ユーザーのメールが危険にさらされ、攻撃者が最初にリンクを取得した場合、あなたはうんざりしています。しかし、ユーザーには大きな問題もあります。

電子メールは本質的に安全ではありません。誰かがそのリンクをクリックしてデータにアクセスできる場合、あなたは本当にそれを保護していません。

さて、トークンはSSLを介して渡されるときに安全です。あなたが抱える問題は、URLを見ることができることで、人々（それが意図されていない人）にとって利用可能であるということです。

SSNのような個人情報の場合、メールでURLを送信するとは思わない。サイトのユーザー名とパスワードを作成してもらいたいです。あなたにとっても彼らにとっても、そのような種類の情報を使って電子メールを危険にさらすのは簡単すぎます。誰かのアカウントが脅かされている場合、それは実際に問題である質問になります。セキュリティが高いほど、厳密にCYAの観点から優れています。

私は、深刻なプライバシーの問題がある状況に十分に安全であるとは考えていません。 URLを（おそらくクリアテキストの）電子メールで送信しているという事実は、間違いなく最も弱いリンクです。その後、トークンに対するブルートフォース攻撃のリスクがあります。これは（実際の認証メカニズムの構造を欠いている）よく構築されたユーザー名とパスワードのセットアップよりも脆弱です。

ちなみに、httpsリクエストのパラメーターにはまったく問題はありません。

現状では、それは悪い考えです。簡単に使用できるため、セキュリティが脅かされます。前に述べたように、SSLはサーバーとクライアントのブラウザー間の情報の転送のみを保護し、仲介者の攻撃を防ぐだけです。メールは非常に危険で安全ではありません。

最善の方法は、情報にアクセスするためのユーザー名とパスワードの認証です。

Cookieのアイデアはだいたい好きです。 Cookie情報も暗号化する必要があります。 また、ソルトとキーフレーズに加えて$ _SERVER ['HTTP_USER_AGENT']を含むトークンを生成して、攻撃の可能性を制限する必要があります。検証用のCookieに、クライアントに関する機密情報をできるだけ多く保存します。

キーフレーズは、簡単に使用できるようにCookieに保存できますが、Cookieが盗まれる可能性があることに注意してください=（。

クライアントが提供したキーフレーズをクライアントに入力させると、データもデータベースに保存されます。

または、$ _ SERVER ['HTTP_USER_AGENT']パラメーターが異なる別のマシンを使用するか、単にCookieを紛失した場合に、キーを使用できます。そのため、Cookieは転送または設定できます。

また、機密データがデータベースで暗号化されていることを確認してください。あなたは決して知らない;）

ハッカーがデータベースにアクセスした場合、多くの個人情報が自由に与えられることをご存知ですか？

その後、これは考えとして悪いことではないと言うでしょう。 MD5またはSHA1はハッシュに対してあまり安全ではないため、使用しません。それらは「復号化」できます。 （暗号化ではないことは知っています）非常に簡単です。

それ以外の場合は、メールのようなパスワードでは送信されない2番目の情報を使用します。その理由は非常に簡単です。誰かがユーザーの電子メールにアクセスできれば（セッションを強制終了しなければhotmailでも簡単です）ユーザーが送信した情報にアクセスできます。

HTTPSは、サイトからエンドユーザーに送信されるデータを保護および暗号化することに注意してください。他には何もありません、安全なトンネルとしてそれを取るそれほど害のないものはありません。

私があなたの考えを理解していることから、理論的には誰かがランダムな40文字の文字列またはMD5ハッシュを入力して、他の人の詳細を取得できます。これは非常にまれですが、一度だけ実行する必要があります。

より良い方法は、ユーザーにトークンを送信し、名前、郵便番号、ssn、またはこれらの組み合わせなどの詳細の入力を求めることです。

所属していません StackOverflow
scroll top