2016-10-15 11 views
0

私のpython Webアプリケーションのセキュリティ実装について考えています。 たとえば、私はユーザーとプロファイルを持っています。 各ユーザーは/ profile/user_idにPOSTを送信して自分のプロフィールを編集できますオブジェクトを変更するためのユーザーセキュリティを確認してください

私はセッションごとにuser_idを取得し、同じでない場合はprofile.user_idと比較できます。

しかし、私はまた、それを別のより一般的な方法を行うことができます。 各プロファイル

secret = hash(profile_data+secret_key) 

のために生成し、認証のためにレンダリングします。このようなユーザーリンク:

/profile/4?key=secret 

だから、アイデアは、編集可能なオブジェクトデータに基づいて秘密鍵を生成し、サーバ側でこのキーをチェックすることです。ユーザーが秘密鍵を知らない場合、他のプロファイルを編集するためのリンクが得られないため、変更することはできません。

この保護方法はどのように呼ばれますか? セッションベースのuser_idチェックでコンパイルに問題がありますか? ?

+0

秘密の方法が動作する可能性のある他のユーザーのプロファイルをユーザーが変更できるようにするかどうかによって、いくつかのセキュリティ攻撃とそれらを防ぐ方法(タイミング攻撃など)に注意する必要があります。別の問題はUXです。ユーザーがプロファイルを編集して秘密鍵を変更すると、以前のすべてのURLが無効になり、煩雑になります。 また、それは単なる例であるかどうかわかりませんが、組み込みの 'hash'関数に注意してください。これは、暗号的には安全ではありません。 –

+0

リンクのinvalidaionの問題は、IDのような永続的なデータに対してのみハッシュを生成することで解決できます。したがって、ハッシュ(id + secret)は、変更可能なデータを生成するのがより安全ですか? – Evg

+0

私はちょうどプロが見えない、あなたは醜いURLを取得し、秘密が漏れた場合は、すべてのユーザーのURLを更新する必要があります。 –

答えて

2

/プロフィール/ 4キー=秘密

実践的な問題:

  • それがURLに秘密を置くために、一般的に悪い考えです。 URLは、ログ、履歴、参照元などから簡単に漏洩します。また、ナビゲーションが中断されます。シークレットをクッキーまたはPOSTデータに入れる方がよいでしょう。
  • 通常、署名付きデータには時間制限が含まれるため、トークンは永久に無効になります
  • 通常、ユーザー情報と署名付きデータには何らかの種類のフラグ/カウンタ/状態が含まれるため、ユーザーは以前に発行したトークンを無効にするために何かを更新することができます(例えばパスワードを変更する)
  • 署名されたデータのライフサイクルがトークンのライフサイクルよりも長くならないようにする必要があります。トークンがまだ有効な新しいユーザー4を作成します。
  • 使用するハッシュは、サーバー側の秘密キーを使用するHMACです。

通常、パフォーマンス上または運用上の理由から、署名付き認証トークンがデータベースバックアップセッション記憶域の代替として使用されます。署名付きのトークンを使用して安全にセッションを行うことは可能ですが、すでに他の目的のためにストアされたセッションを使用している場合は、それほど多く得られません。

関連する問題