4

モデレーターがユーザーの情報を編集できるようにするアプリケーションに取り組んでいます。だから、現時点では、私はURLのようなものを持っています

http://xxx.xxx/user/1/edit
http://xxx.xxx/user/2/edit

データベースから users テーブルの主キー (id) を直接公開しているので、ここでは少し心配です。URLからIDを取得し（例：上記のURLの1と2）、IDを使用してデータベースにクエリを実行し、ユーザー情報を取得します（もちろん、入力、つまりURLからのIDをサニタイズします）。

その点に注意してください：

モデレーターがそのユーザーを編集するアクセス権を持っているかどうかを確認するために、すべてのリクエストを検証しています

これが私がやっていることです。これは安全ですか？そうでない場合、どのようにすればよいですか？

私は1つの代替案を考えることができます。つまり、25文字のキーを持つユーザーテーブル用に別の列を持ち、それらのキーでURLのキーとクエリデータベースを使用します

しかし、

  • どんな違いがあるの？（鍵が露出しているので）
  • 主キーでクエリを実行すると、他の列よりも高速に結果が得られます
4

5 に答える 5

4

管理者権限の検証が正しく、SQL インジェクションを防止できる限り、これは安全です (そして、これを行うための最良の方法のようです)。どちらもあなたが言及しているので、私はあなたが良いと思います.

于 2014-04-22T13:34:35.597 に答える
2

基本的な問題は、主キーを公開することが安全かどうかです。ほとんどの状況では安全であり、Stackoverflow も同じ方法でそれを行っていると思います。

http://stackoverflow.com/users/1/
http://stackoverflow.com/users/2/
http://stackoverflow.com/users/3/

を確認するmember forと時間が減っているのがわかりますので、数値もおそらくPKです。

とにかく、一般的なユーザーが URL に 1、2、3 などを入力するだけですべてのエントリを通過するのを避けたい状況では、PK を隠すこと535672571d2b4が役立ちます。

于 2014-04-22T13:40:48.157 に答える
0

単純な自動インクリメント ID がある場合は、データを世界に公開します。シーケンシャルではありません (たとえば、テーブル内のすべての利用可能なデータをブルートフォースするため)。ただし、DB エンティティの ID を順番に生成するのではなく、疑似ランダムな方法で生成できます。たとえば、PostgreSQL では次のようになります。

CREATE TABLE t1 (
    id bigint NOT NULL DEFAULT (((nextval('id_seq'::regclass) * 678223072849::bigint) 
    % (1000000000)::bigint) + 460999999999::bigint),
    ...
    <other fileds here>
)
于 2014-04-22T13:41:19.113 に答える