昨日、同僚と私は、認証の手段としてURLパラメーターを介してログイン資格情報を送信しても安全かどうかについて激しい議論をしました。彼は、HTTPSがサーバー側にリクエストを送信する前に、URL内のすべての非ホスト名/ポート文字を暗号化することを正しく指摘しました。
ただし、これらの資格情報を盗むことが可能であり、HTTPSPOSTを介して送信する必要があると考えているEdgeのケースがまだあると思います。これは実際にログイン/トークンデータを送信する安全な手段ですか?
要求されたURLはWebサーバーログおよびブラウザの履歴/ブックマークに表示される可能性がありますが、これは良いことではありません。
バックエンドデータベースがある場合は、追加の手順を実行します。フォームの投稿を介してユーザー名とパスワードを送信し、バックエンドにトークンを返してもらい(GUIDが行います)、トークンをデータベーステーブルに書き込み、有効期限を割り当ててから、資格情報の代わりにクエリ文字列でそのトークンを使用します。これで、システムは非常に安全になり、一意のセッション識別子がプラスになります。
資格情報の送信に関する限り、彼は正しいです。ただし、ブラウザの履歴、サーバーのログファイル、画面を見ているユーザーなど、考慮すべき点は他にもたくさんあり、その場合はリスクが伴います。
安全に大きな言葉です。 SSHは他のユーザーがそれを取得するのを防ぎますが、クエリ文字列に誰かのパスワードを表示したいですか?ユーザーの肩越しに立っている男はどうですか? SQLインジェクションはどうですか?本当に悪い考えです。少なくともフォームの投稿に入れてください。
HTTPSがURLも暗号化したことを私は知りませんでした。知っておくとよいでしょう。
ただし、セキュリティの観点からは、資格情報をURLバーで読み取ることができるという事実にもっと悩まされるでしょう。ブラウザの履歴に保存される可能性があることは言うまでもありません。
私が試している別の解決策もあります。 PHPセッション用ハンドラーを使用すると、セッションデータをそのハンドラーを使用して簡単に文字列としてデータベースに直接保存できます。DBに有効期限のあるセッションテーブルが必要です。送信したらHTTPSログインデータを介して、それが正しければ、それを$ _SESSION変数に格納できます。インターフェイスがうまく機能していれば、DBに移動します。これはPHPの外部に公開されていないため、堅牢なログインシステムが得られます。 、およびクライアントCookieには、トークン、アカウント、またはその他の機密データではなく、セッションIDのみが保存されます。
参照: http://es.php.net/manual/en/function.session-set-save-handler.php