web-dev-qa-db-ja.com

ファイルハッシュと一致するCookieハッシュは安全ですか?

簡単なログインフォームを作成しました。これは、あらゆるプロジェクトで使用できるように非常に一般化されています。さて、セキュリティは十分で、私のアプローチは安全かどうか疑問に思います。

成功した​​場合

ログインに成功すると、2つのことを行います。 usernamehash(sha256)でCookieを設定しました。また、usernameおよびhash(sha256)を使用して、一時ファイルをサーバーに書き込みます。ユーザー名とハッシュの両方がCookieと一致するようになりました。

翌日にログインできます

このアプローチの理由は、1日後でもログインできるためです。パスワードをチェックする必要はなく、そのユーザー名のハッシュを照合するだけです。

簡単にハッキングできますか?

これは良いアプローチですか?そうでない場合、落とし穴は何ですか?簡単にハッキングできますか?もしそうなら、代わりを与えてください。

プロジェクトに関する詳細情報が必要な場合は、完全なフォームはこちら https://github.com/jenstornell/wall であり、ログイン部分のみがこちらです https:// github。 com/jenstornell/knock

3
Jens Törnell

これは「自分でロール」する必要のある場所ではないというnadirに同意しますが、これらの脆弱性を作成しているのはアプリの開発者であり、その方法を学ぶ必要があるため、これらがうまくいかないことについて話し始めるのは長い間遅れていると思いますそれをやめるために。

ここで私が目にする最大の問題は、システムにアクセスするために必要な正確な値を保存していることです。ある意味では、パスワードを平文で保存するようなものです。問題は、攻撃者がこのように保存されたデータにアクセスできるようにするシステムに多くの脆弱性があることです。この場合、これをファイルに保存することを計画していました。非常に一般的なエクスプロイトは path/directory traversal です。 4番目の例は、PHPの例です。これをデータベースに移動することはできますが、PHPフレームワークは SQLインジェクションの脆弱性)で悪名高いです パラメータ化されたクエリを使用したくない、または使用できないため。

これらの値が取得される可能性があるという前提で操作する必要があります。また、これらの値がシステムへのより広範囲なアクセスに使用されないようにする方法を説明します。パスワードの場合、攻撃者がシャドウファイルをハッシュでいっぱいにした場合、それらを直接使用することはできません。実際のパスワードを取得するには、(理想的には)コストのかかるクラッキングプロセスを実行する必要があります。しかし、あなたの提案では、ファイルシステムを横断してこれらのファイルを取得する方法が見つかった場合、それは基本的にゲームオーバーです。つまり、彼らはアクセス権を獲得しています。

これを、これらの問題を解決した場合、ソリューションが完全に防護されたことを意味するものではありません。セキュリティは非対称です。攻撃者は、1つまたは2つの穴を見つけるだけです。防御側はすべての穴を塞ぐ必要があります。このため、セキュリティツールはそのことに集中する人に任せるのが最善です。あなたが理解しようとするべきではないと言っているのではありません。あなたがあなた自身を構築した場合、あなたは以前に何度も犯されてきたのと同じ間違いのいくつかを犯す可能性があるというだけです。

2
JimmyJames

例えば;誰かがユーザー名を手に入れて「どういうわけか」ハッシュした場合、彼はあなたのサービスでこのユーザーになりすまして、彼女に代わって行動することができます。
「新しい」/個人的なセキュリティスキームをゼロから考案しようとすることは、ソフトウェアエンジニアとしてはなおさらです。
セキュリティは(非常に)複雑な問題であるため、既存の保守された長年のソリューションを再利用し、ベストプラクティスを使用してそれらをアプリケーションに統合することをお勧めします。

1
nadir

私にとって重要なことは3つあります。

1。予測不可能なコード:

コードは予測可能であってはなりません。 usernamehashを使用しています。このhashが静的または予測可能である場合、それは本当に重要な脆弱性です。

2。安全なコード

コードを保存する場所を保護する必要があります。 Cookie内にある場合は、 HttpOnly であり、安全なネットワーク経由で転送する必要があります。

3。無制限のアクセスを許可しない

対象ユーザーであっても、無制限のアクセスを許可しないでください。時間制限付きアクセスを提供し、必要に応じてアクセスを延長します。

1
Engineert