プロセスの 3 番目のステップへの直接アクセスを許可するのは奇妙です。ユーザー名、アドレスなどの他のすべてのデータはどこにありますか?
これは私が行うことのいくつかのアイデアです。完全に安全なシステム (存在しない可能性があります) は、私の単純な手順よりもはるかに複雑になります。
おそらく、最初にユーザーが自分が誰であるかを知ることができる情報(確認済みの電子メール、確認済みの電話番号など)で登録できるようにしてから、クレジットカードのことを行い、ユーザーが継続的に入力する場合間違った番号や無効な番号がある場合は、ブラックリストに登録したり、電話をかけたり、侮辱したりするなど、他のことを行うことができます.
注 2長い時間をかけて書いたので、読んで考えれば考えるほど悪くなりそうですが、書いてあるので載せておきます。
開始前の注意事項:
- /authenticate/auth.php のように、アドレスは 1 つだけです。
- プロセスには「状態」があり、これに応じて、さまざまなことを表示/実行します。
- さまざまな状態の場合、状態に応じて含まれる他の追加ファイルがあります。
- プロセスが開始されると、セッションが作成され、ユーザー IP、プロセス状態、およびユーザーに関するその他の識別可能な情報 (「User-Agent」など) とリンクされます。このデータはサーバーに保存されます。
- 別のページを使用して別の状態を表示したいようですので、そのようになります。しかし、実際には ajax 呼び出しを使用して 1 つのページで行います。
- 疑わしいIP アドレス (通常またはバグのある、または完全に間違った要求が多すぎる) のブラックリストはありません。必要に応じて追加できますが、複雑さが増します。あなたはこれをやりたいかもしれないし、やりたくないかもしれません.多分カプチャで十分でしょう..
- 場合によっては役立つ可能性のあるキャプチャはありませんが、ここで説明するセッション処理を変更する必要がある場合があります。
- おそらくやりたいと思う電子メール検証はありません。
プロセスの状態がask_name、ask_address、ask_ccなどであるとしましょう...
したがって、認証ページ (/authenticate/auth.php) へのリクエストがある場合は、次のようにすることができます。
1 'Referer' が可能なプロセス スターター (メイン ページなど) またはこのページ (/authenticate/auth.php) の 1 つから来ていない場合、メイン ページにリダイレクトします。終了。
この最初のステップにより、人々がアドレスを直接書き込んだり、信頼できないページからアクセスしたりすることを回避できます。
2 このリクエストのセッション情報がない場合:
2.1 'user_name' パラメータがあり、かつ 'Referer' がこのページ (/authenticate/auth.php) である場合
2.1.1 そのユーザー名がすでに登録されている場合は、「ユーザーはすでに登録されています」という追加の通知とともに「ask_name.php」を表示します (リダイレクトせずに含めます)。終了。
2.1.2 このユーザーのセッションを作成し、それをその IP、ユーザー エージェントなど、その他のデータとリンクします。
2.1.3 状態を ask_address (2 つ目) に設定し、「ask_address.php」を表示します。終了。
2.2 Else (パラメータがないか、「Referer」が間違っていた)
2.2.1 「ask_name.php」を表示します。終了。
この 2 番目のステップは、最初の画面 (ask_user) または 2 番目の画面 (ask_name) を表示し、ユーザーが実際に何かをしたいと確信するまでセッションの作成を遅らせます。
いくつかの問題があります。
- 一部のユーザー (またはプログラム) は、セッションなしで「user_name」を使用してリクエストを継続的に送信するため、ユーザーが有効かどうかを常に確認する必要があり、速度が低下する可能性があります。これは、キャプチャを使用するか、しばらくの間、一部の IP をブラックリストに登録するなど、いくつかの異なる手法を使用して回避できます。
- 1 人のユーザーが存在しない「user_name」を使用してプロセスを開始する可能性がありますが、プロセスが遅く、プロセスを完了するのに時間がかかります。これが発生している間、2 番目のユーザーが同じユーザー名でプロセスを開始および終了します。 'user_name' であるため、最初のユーザーが終了しようとすると、最後のステップで失敗します。これは、演習として残されているいくつかの異なる手法で回避できます。
3 このリクエストのセッション情報がある場合 (これは前のステップへのelse です)
3.1 リファラーがこのページではない場合、またはサーバーに保存されている IP が現在のリクエストと同じでない場合、またはユーザー エージェントなどの他のデータが異なる場合、または状態が無効である (状態のリストにない) 場合は、セッション ID を削除します。リクエストを削除し(ブラウザが削除します)、「デバイスが変更されたようです!!!」という追加の通知とともに「ask_name.php」を表示します。終了。
3.2状態のページを「含める」 :
3.2.1 パラメータが渡され、正しい場合は、状態を次の状態に設定し、そのページを表示します。最後の状態である場合は、最後の状態に適した何かを行います。終了。
3.2.2 この状態の同じページを表示し、ユーザーが再試行するようにエラー メッセージを表示します。終了。
この最後の手順では、要求が別のコンピューターからのものではないこと、および/またはセッション キーが盗まれたものではないことを確認しようとします。