3

ユーザーがサイトでアカウントを作成し、ページのリロードなしでシームレスにログインできるようにする AngularJS を使用してサイトを作成しています。このようなサイトを作成するために、AngularJS ルーティングを使用してさまざまなパーシャルをロードし、$http を使用して xhr 経由で php スクリプトにアクセスしています。既に述べたように、私はサーバー側のスクリプト作成に php を使用し、mysql を使用してデータを保存しています。

私の問題は、$http サービスを介してサーバーに送信されたデータがページのリロードなしで、firebug (または同等のツール) のネットワーク タブに表示されることです。これは、ページが閉じられるまで、パスワードなどの個人データがこれらのツールを通じて公開される可能性があることを意味します。ここで、ユーザーがどのツールでもこの​​データを表示できないようにする方法を見つけたいと思います。クライアント側のデータを暗号化できました。問題は、スクリプトがまだ公開されていることです。他の誰かがこれを問題と見なし、それを回避する方法を見つけましたか?

私が考慮する必要があるもう 1 つのことは、ユーザー セッションを angular に保存する最良の方法は何ですか? php のセッションを使用し、$http または Cookie を使用してそのステータスを取得するのが最善でしょうか? ここでも、どちらの方法にもセキュリティに関連する問題があります。Cookie の場合、コンテンツを暗号化する必要があり、セッション変数を使用して ajax を介してデータをやり取りすることで、firebug を使用してすべてにアクセスできます。繰り返しになりますが、これについて人々の意見を知りたいと思います。

4

1 に答える 1

2

パスワードの可視性の問題については、クライアント側でパスワードをハッシュすることができます。JavaScript コードは表示されますが、これは問題になりません。ハッシュ関数は一方向であるため、ハッシュ結果に基づいてパスワードを取得することはできません。シークレットではないため、javascript にソルトをハードコードすることができます ( https://stackoverflow.com/a/536756 )。

必要に応じて、データベースの値と比較する前に、サーバー側で 2 番目のハッシュを実装できます。ただし、これは、パスワード値の読み取りにつながる脆弱性があり、同じ脆弱性がデータベースの更新を許可しない場合にのみ保護を提供します.

他のデータについては、diffie-hellman 鍵交換を検討できます。

クライアント側で実行される JavaScript が実際に提供したスクリプトであることを確認するには、https が必要です。また、チャンネルを保護しますが、ブラウザーや firebug には影響しません (これは正しいですか? firebug は SSL で保護された AJAX を参照する必要がありますか? )。

angularjs と php で同様のものを実装していますが、クライアント側のハッシュまたは diffie-hellman キー交換を使用しないことにしました。あなたが自分自身を守っているシナリオは、実行するのが非常に困難です。侵入者は、ログインの前後にブラウザにアクセスできる必要があります。

于 2012-08-10T14:27:49.587 に答える