最初の質問は、安全なログイン ページを提供するための標準的な手順についてです。私がよく知っている 2 つのことは、誰かが肩越しに監視するのを防ぐためにパスワード フィールドを配置することと、https 経由でデータを送信することです。完全に安全なログイン サイトを作成するために含める必要があるものは他にありますか?
さらに、ログインすると、セッションはどのように維持されるのでしょうか。つまり、ユーザーがクリックすると、サーバーはユーザーベースのコンテンツを再び生成する必要があることを認識しますか? 誰がログインしているのかを考えると、https やその他のセキュリティ対策を維持する必要はありますか?
ご回答ありがとうございます
私はそれについて本を書くことができるのではないかと心配しています...
セッションの質問のみに対処する：セッションは通常、連続するリクエストごとに送信されるCookieによって維持されます。また、ユーザーがログオンしているかどうかの情報はセッションCookie（またはスタンドアロンユーザーCookie）に基づいているため、盗まれたCookieを使用してログインを偽装することができます。したがって、セッションの残りの部分（Cookieを保護するため）でhttps接続を維持するか、少なくともいくつかのマイナーなセキュリティ対策（セッションが以前と同じIPアドレスからのものであるかどうかを確認するなど）を行う必要があります。
サイトをより安全にするためにできることはたくさんありますが、それらすべてを行ったとしても、サイトが「完全に」安全であるという保証はありません.
たとえば、ユーザーのログイン情報をデータベースに保存している場合: SQL インジェクションに対する保護を導入しましたか? ログインページに登録フォームも含まれている場合: XSS エクスプロイトに対する保護はありますか? パスワードが満たさなければならない最小要件はありますか? または、ユーザーが独自の (多くの場合非常に悪質で推測しやすい) パスワードを作成できますか? 自分で解決できる問題もいくつかありますが、残念ながら、実際に悪用されるまでは (誰も思いつかなかったので) 保護しようとは思わないものも常にあります。サイトへの攻撃経路は無数にあり、それらを防御する方法は同量あります。それらすべてを掘り下げるには、あまりにも長い時間がかかります (私自身がそれほどセキュリティに精通しているわけではありません)。
他の回答が指摘しているように、セッションはクライアント側の Cookie に保存されるセッション ID によって維持されます。セッションが開始されると、ID が生成されます。この ID は、クライアントのブラウザによって使用され、サーバー側に保存されているデータがそのブラウザに属するものとして識別されます。この ID が盗まれるのを防ぐには、HTTPS を使用して接続を暗号化する必要があります。ただし、ページに外部リソースへの参照がある場合 (例: 別のサイトの画像、別のサイトのスクリプトなど)、接続は部分的にしか暗号化されないことに注意してください (つまり、外部リソースではない部分)。明らかな理由から、これは完全な暗号化よりも安全性が低くなります。これを防ぐために、可能な限りすべての外部リソースをローカル ディレクトリにダウンロードします。
はい、パスワードフィールドとhttpsは間違いなくログインへの良いアプローチです。パスワードを推測しようとするロボットスクリプトではないことを確認するために、キャプチャを除いて、今のところ他に何もすることは考えられません。
セッション管理について：「$ _ SESSION」変数があります。これはすべての接続に固有であり、「session_start（）;」を呼び出した後、PHPによって自動的に維持されます。スクリプトの最初に。
このコマンドは非常に重要です。そうでない場合、$ _ SESSIONは常に空になります...私が間違っていない場合は、ブラウザに識別情報（SessionIDなど）を要求し、保存されている情報をそれに一致させますセッションID。
このセッション変数は、他のスーパーグローバルと同様に使用します。
$_SESSION['ID'] = $ID;
$_SESSION['AccessRights'] = $AR;
等々。実際のセッションデータはサーバー側にのみ保存され、PHPスクリプト以外から変更することはできません。ユーザーについて知っておく必要のあるすべてのものを$_SESSIONに保存すれば、問題はありません。
「HTTPSの維持」について：すべての「重要なデータ」がすでに転送されているという理由だけで、これは必要ありません。
ただし、機密データや個人データ（パスワードの変更など）を処理したら、もう一度HTTPSに戻りたい場合があります。ただし、経験から、HTTPSの実際のオーバーヘッドは、今日のシステムではかなり小さいものであり、大量のトラフィックを予期していない限り、「オン」のままにしておくことは決して悪い考えではありません。
さて、私はこの問題に関して間違っているかもしれませんが、それはこの問題についての私の意見です。
@Kubaが言ったように-それは大きなトピックです。セッションの固定、セッションの保存、Cookie の保護、パスワードのセキュリティ、無効なログインへの応答時間、セキュリティで保護されていない方法でのログイン ページへのアクセス、XSS、SQL インジェクション、そしておそらくさらに何千もの私にはわかりません。
私のアドバイス：自分でやらないでください。考えられるすべての言語に対応するセキュリティ フレームワークがたくさんあります。1 つ選んで、ハウツー ページを読んで、それを使用してください。最も一般的なタスクに役立ちます。しかし、アプリケーションのセキュリティはログインページで終わりではありません。アプリケーション全体を保護するには、適切に記述して保護する必要があります。