1

開発中のWebサイトのログインスクリプトを作成しており、PHPセッションを使用してユーザーを認証しています。

CookieにのみHTTPを使用し、セッションIDの保存にCookieのみを使用するようにスクリプトを設定しました。

基本的に2つのことを知りたい

1.ログインをより安全にするために他にすべきことはありますか？

と

2. PHPマニュアルにはsession_destroy()、セッションデータは削除されると記載されていますが、セッション変数の設定は解除されていません。この場合、実際には何が破壊されますか？ログアウト時にセッション変数の設定を手動で解除する必要がありますか？

助けてくれてありがとう

編集： 無料ホスティングを使用していますが、Apacheアドオンをインストールしたり、php.iniファイルを変更したりできません

編集： セッションIDの盗難を防ぐにはSSLを使用する必要があることを読みましたが、サーバーにOpenSSLをインストールする機能がないため、セッションIDを保護する他の方法はありますか？

4

5 に答える 5

12

覚えておくべき最も重要なこと：

クライアントから戻ってくるものは何も信用しないでください

取得している情報（フォームフィールド（非表示のフィールドも含む）、セッション変数など）が有効であると思い込まないでください。サーバー側のロジックを使用してこれらのチェックを実行してください。

1.）セッションが暗号化されていることを確認します。PHPの組み込みセッションを使用している場合、関連するエントロピー（ランダム性）は比較的高いため、問題ないはずです。

2.）セッションIDのみをCookieに保存します。その他の情報は、そのIDを使用してサーバーに関連付ける必要があります。セッションでトークン'is_admin'= trueの場合、システムエンジニアが誰かが管理者であるかどうかを判断する多くのケースを見てきました。あなたは明らかにこれの問題を見ることができます。

コストのかかる操作であると不満を言う人もいますが、アクティブなセッション用に（my）SQLテーブルを作成することをお勧めします。次に、ページが読み込まれたときに、関連するデータをテーブルからプルして、他のデータと同じように処理します。一部のフレームワーク（CodeIgnitorなど）は、1つの構成アイテムを変更することでこれを実行します。

3.）IPに対して検証します-テーブルに、現在のIPアドレスを追加します。現在のIPがセッション内のIPと一致しない場合は、誰かがハイジャックしようとしている可能性があります。強制的にログアウトして終了します。

4.）ログイン試行に制限を設定します。1秒のsleep（）;を追加します。各ログインのサーバー側は、ユーザーには事実上気づかれませんが、自動化されたシステムの場合、ブルートフォースログインを事実上不可能にします。

5.）「おしゃべりすぎる」のを見てください。ログイン時に、「ユーザー名が存在しません」や「パスワードが正しくありません」などの説明的な誤りを与えると役立つと思うかもしれません。このような情報は、ハッカーが有効なユーザー名を取得したことを示します。これにより、ハッキングがはるかに高速になります。

6.）PHPとSSLの安全性、および独自のロジックについてはあまり気にしないでください。WebサイトがSSLを使用しているからといって、それが安全になるわけではありません。有効なロジックと組み合わせたSSLはセキュリティを提供します。

7.）SUPERに関心がある場合は、専用サーバーに移動することをお勧めします。サーバーでホストされている他のWebサイトがコード/データベース情報にアクセスできる可能性があります。彼らはあなたほど安全であるために必要な措置を講じていないかもしれません。

8.）同時セッションを許可しないでください。これにより、MITM（中間者）攻撃が防止されます。DBセッションアプローチのもう1つの利点は、2つのクライアントが異なるIPから同時にログインしようとした場合に、強制的にログアウトできることです。DBアプローチのさらに別の利点は、システムをスケーラブルにすることです（セッションストレージはファイルシステムに依存するため）。

9.）add_slashesの代わりにmysql_real_escape_stringを使用します

PHPのセキュリティに関する詳細情報が必要な場合は、私の専門です。自由に連絡してください。

于 2010-12-19T02:35:53.257 に答える
1

ここで理解しておくべき重要なことは、データが保存される場所です。セッションはサーバー側に保存されるため、意図的にページに含めない限り、セッション内のデータはクライアントに送信されません。Idはランダムで非決定論的（つまり推測できない）であると想定されています。

これは、セッションを使用してキーやIDなどを保存でき、ユーザーがそれらが何であるかを知ることができることを心配する必要がないことを意味します。

するとsession_destroy()、IDと変数の間のサーバー側のリンクがクリアされ、セッションが使用できなくなります。クライアントはまだIDを持っている可能性がありますが、現在は役に立ちません。

実際に何をしているのかをある程度理解していなければ、実装の安全性についてコメントすることはできませんが、Cookieやフォームデータに直接情報を保存するよりも、セッションに情報を保存する方がはるかに優れています。

編集：SSLに関する質問：

SSLは、ほとんどすべての最新サーバーでサポートされています。（あなたは本当にそれをサポートしていないサーバーを探す必要があります）。OpenSSLは、SSLを実装する多くのソフトウェアの1つです。

SSLの基本は次のとおりです。サーバーにインストールされている証明書*を取得します。サーバーはこの証明書を使用して、すべての要求に「署名」し、クライアントとサーバー間の送信を暗号化します。

*証明書は無料で作成できますが（Googleの「自己署名証明書」）、自己署名証明書は通常、ブラウザによってはユーザーに警告/エラーを表示します（信頼のレベルがないため）。ブラウザには、「信頼できる」証明書発行者のリスト（Verisign、Thawteなど）があります。これらは、証明書を発行する定評のある会社です（通常は有料）。

証明書は一定期間有効であり、さまざまなレベルの信頼があります（たとえば、安価な証明書は電子メールアドレスが正しいことを確認するだけです。拡張検証証明書は、電話番号、パスポート、電子メールアドレス、および登録済みアドレスが発行者によって確認された後にのみ発行されます） 。

EV証明書にはいくつかの利点があります（南京錠のアイコンと同様に、緑色のアドレスバーが表示されます。www.paypal.comを参照してください）。それが自分にとってどれほど重要かを判断する必要があります。

ホストに連絡して、SSL証明書を追加できるかどうか/どのように追加できるかを尋ねる必要があります。以前はこれは通常有料アカウントでのみ利用可能でしたが、最近でははるかに一般的になっています-したがって、少しグーグルすれば無料のSSLホスティングを見つけたいと思います

于 2010-12-19T02:13:47.027 に答える
1

1）httpsを使用します。最低限、ログインページはユーザーのパスワードを保護するためにhttpsを使用する必要がありますが、Cookieの盗難を防ぐために、認証されたセッション全体でhttpsを使用することを検討する必要があります。

正しい認証トークンを含めるには、CookieとPOSTデータの両方が必要です。

セッション固定を防ぐために、リクエストごとに認証トークンを変更することも検討できます。クロスサイトリクエストフォージェリやその他の同様の攻撃を防ぐ方法を読んでおくことをお勧めします。OWASPは、一般的な攻撃とその軽減方法に関する一般的な情報を入手するための優れたリソースです。

2）session_destroy基本的にクライアントのセッションCookieを無効にするため、今後のリクエストでは同じセッションデータが表示されません。コードフローに応じてsession_destroy、クライアントに戻る前に最後に行うか、$_SESSIONスーパーグローバルコンテンツの設定を手動で解除することができます。

于 2010-12-19T02:19:48.510 に答える
0

ユーザーが特権のレベルを上げるたびに（たとえば、ログインすることによって）、 session_regenerate_id（）を使用します。SSLは使用できないとおっしゃっていましたが、送信される情報が機密性の高いものである場合は、SSLを検討する必要があります。SSLと組み合わせたsession_regenerate_id（）は、セッションハイジャックに対する最も強力な防御を提供します。機密情報を保持している場合は、無料ホスティングが本当に必要なものを提供しているかどうかを検討する必要があります。

于 2010-12-19T02:30:04.397 に答える
0

私はログインスクリプトに取り組んでおり、最初に説明したように@sethvargoによってリストされたすべての手順を実行しました。最も重要なことは、データが信頼できるソースから送信された天気を確認することです。私が通常行うこの目的は、特別なトークンを作成し、それを次のような形式で埋め込むことです。

hash('md5', 'special-phrase_' . time() . '_special-phrase');

そして、受信側では、このように機能するループを実行します。トークンは1分後には役に立たなくなります。

for ($i=0; $i<=60; $i++) {
    $phrase = hash('md5', 'special-phrase_' . (time() - $i) . '_special-phrase');
    if ($phrase == $token) {
        print('Request received from a trusted client.'); exit;
    }
}
print ('Request timeout!')!

ログインシステムでこの手法を使用していますが、信頼できるデータを処理するためのこの正しい方法はありますか？提案をお願いします。ありがとう！

于 2018-12-01T22:27:41.417 に答える