4

ユーザーからの投稿を編集するときは、次の URL を使用します。

../post/edit/3            //If the id of the post is 3 for example

たとえば/post/edit/5、ユーザーが意図的に URL を変更することを避けるために、次のロジックを使用して、ユーザーが権限を持っていないときに投稿を編集しないようにします。

if (//user is allowed to edit post){
    //edit post
}
else {
    throw new AccessDeniedException('You do not have the permission to edit this post');
}

これは、投稿を編集するときに使用する一般的なアプローチですか? ユーザーが URL で投稿の ID を操作できないように、何かきれいにする方法はありますか?

編集

考えれば考えるほど、セキュリティに配慮したサイトで、このような URL の ID を見たことがないことに気づきました。したがって、ID を引き続き使用して、ユーザーがこの ID を表示/表示できるかどうかを確認できることに同意しますが、それでもユーザーはすでにやりすぎている可能性があります。利用可能なアルゴリズムを使用して新しい暗号化された ID を生成できるように、ID をハッシュする方がよいのではないでしょうか。

<?php
echo hash('md5', 'id_to_edit');
?>

URLでIDを保護するための標準的なアプローチは何ですか? 一般的に、URL に ID のような情報を表示するのは良い考えですか?

4

8 に答える 8

6

Special situations may call for special measures, but in a typical situation, all that is necessary is:

  • Use SSL so that sessions can't be hijacked by eavesdroppers
  • Check the user's permissions before doing anything.

Plenty of sites do it similar to the way you described initially. For example, WordPress has URLs like https://example.com/wp-admin/post.php?post=112&action=edit. Clearly, a curious user could choose to edit the post=112 part.

So, one standard you might consider is: "Do I need to be more concerned about security and privacy than WordPress?"

If, for example, you don't want people looking at log files to know what IP addresses are editing what posts, you have a few options. Each approach has trade-offs so what the best one is will depend on what your biggest concerns are.

For example:

  • You might use a hash to conceal the post id number, like you suggest in your update to your question.
  • Or you might just send that info via a POST method (instead of GET) over SSL and not include it in your URL at all.

One advantage of the first approach is that people can use bookmarks to get back to the page. You might not want that. Or you might. Depends on your app.

One advantage of the second approach is that (for example) Google Analytics won't reveal if one post id is being accessed/edited over and over again or if many post ids are being accessed/edited. This may matter to you depending on whether such information might tell someone something and who has access to your Google Analytics stuff. Or it might not matter at all.

There are a lot of other possible considerations too, such as performance.

By the way, if you do use MD5, be sure to include something in the input that an attacker will not know. Otherwise, it will be trivial for an attacker to reverse a discovered hash via a lookup table and generate further legitimate hashes for sequential post ids. In PHP, you'd want to do something like:

hash('md5', $some_hard_to_guess_secret_string . $data_you_wish_to_hash);

There is no single best practice that applies to every situation. But in a typical situation, it is not necessary to hash the post id value or even send it through POST. In a typical situation, be sure to use SSL (so that sessions can't be hijacked) and check user permissions before doing anything and you are likely good to go.

于 2012-07-25T04:38:40.087 に答える
3

クライアントからのすべてのデータを疑わしいものとして扱う必要があります。これにはURLが含まれます。このクライアントが実際に認証されていること、および示されているアクション（URL、投稿データなど）を実行する権限があることを確認する必要があります。これは、データを変更せずに表示するだけの場合にも当てはまります。

レコードIDがURLで簡単に表示または変更できるかどうかは、重要ではありません。重要なのはそれで何ができるかです。ID自体が何らかの情報を提供しない限り（これは驚くべきことです）、IDを非表示にしたり、難読化したりする必要はありません。認証され承認されたリクエストにのみ応答するようにしてください。

于 2012-07-25T05:12:19.847 に答える
2

IDをハッシュするかどうかに関係なく、投稿を編集するときに権限を確認する必要があります。そうしないと、編集できないはずのページに誰かがつまずいて、重大な損傷を引き起こす可能性があります。これは、ランダムに推測するか、アプリを使用した別のユーザーの履歴を閲覧することによって行うことができます。

誰かが何かを編集することを許可する前に、許可を確認してください。

これは、IDをハッシュできないため、線形ではないということではありませんが、WordpressやStackOverflowなどの一般的なアプリケーションを見てください。IDを知っているかどうかに関係なく、権限がないと編集できないため、これらはすべて増分番号に基づいています。

于 2012-07-25T04:32:05.543 に答える
2
  1. 権限を確認する
  2. 検証、認証、承認に GET 値を使用しないでください。セッション、投稿変数は問題ありません。
  3. 面白くするために...編集ページに戻ったときにすべてをチェックする$x =md5(random number + post_id + userid)ように、すべての値を個別に送信します。/edit/3?id=$x&y=rand_numberそれ以外の場合は例外をスローします。db に関連するアイデアは他にもいくつかありますが、興味がある場合は.
于 2012-07-25T18:29:13.223 に答える
2

それが標準的なアプローチです。フォームの表示とフォーム送信後のアクションの両方の権限を常に確認する必要があります。

于 2012-07-20T00:28:16.437 に答える
1

そのためにはACLを使用することをお勧めします。すべてを拒否するようにアプリケーションを構成し、ACL を使用して特定のオブジェクトへのアクセスを許可することができます。

URL では ID の代わりにハッシュを使用しないのが一般的です。Clean id を使用すると、簡単なコマンドで apache ログ、アプリケーション ログを grep できます。特定のドメイン エンティティへのアクセスを許可または拒否するには、すべてのロジックをコードに含める必要があります。

于 2012-07-25T17:48:15.097 に答える
1

ID を難読化してもセキュリティは向上しません。前述のように、常にアクセス許可を確認する必要があります。

セキュリティに関心のある Web サイトでこのような URL を見たことがないという印象を持たれる理由は、これらの Web サイトの一部は通常 Java や .Net などで実行され、GUID ( http:/ /en.wikipedia.org/wiki/Globally_unique_identifier )。ただし、それらの一部は連続した ID を使用しています (たとえば、gmail は電子メールに連続した ID を使用しています)。

MD5'ing は良い考えではありません。特に md5(5684) のようなものであれば、クラッキングは非常に簡単です。ここで100.000未満の数値のハッシュをいくつか調べましたhttp://md5.noisette.ch/index.phpで、それらのすべてが見つかりました。

于 2012-07-25T05:18:00.220 に答える
0

すでに確認済みの (ログインしている) ユーザーが問題の投稿を編集する権限を持っているかどうかを確認するよりも、どれだけ安全である必要がありますか? アドレスバーにハッシュ値が表示されていれば、ハッシュアルゴリズムを見つけるのは比較的簡単で、編集しようとしている投稿を制御することができます. あいまいさによるセキュリティは、常に誤ったセキュリティ感覚になります。

于 2012-07-25T04:52:52.413 に答える