Вообще хорошая идея всегда хешировать уникальные идентификаторы в URL?

Question

Большинство сайтов, которые используют первичный ключ с автоинкрементом, отображают его открыто в URL.

т.е.

example.org /? ID = 5

Это позволяет любому человеку легко «паучить» на сайте и собрать всю информацию, просто увеличив значение id. Я могу понять, где в некоторых случаях это плохо, если права доступа / аутентификация не настроены правильно, и любой может посмотреть что-нибудь, просто угадав идентификатор, но всегда ли это хорошо вещь?

example.org /? ID = e4da3b7fbbce2345d7772b0674a318d5

Была ли когда-нибудь ситуация, когда хеширование идентификатора для предотвращения сканирования является плохой практикой (помимо потери времени, необходимого для настройки этой функции)? Или это тема спорная, потому что, размещая что-то в Интернете, вы рискуете быть украденным / добытым?

Answer 1

Как правило, с веб-сайтами вы пытаетесь сделать их легкими для сканирования и получить доступ ко всей информации, чтобы вы могли получить хорошие рейтинги поиска и привлечь трафик на ваш сайт. Хорошие веб-разработчики разрабатывают свои HTML с учетом поисковых систем, а также часто предоставляют такие вещи, как RSS-каналы и карты сайтов, чтобы упростить поиск контента. Поэтому, если вы пытаетесь сделать сканирование более сложным, не используя последовательные идентификаторы, то (а) вы не усложняете его, потому что сканеры работают, следуя ссылкам, а не угадывая URL, и (б) вы пытаетесь сделать что-то более сложное, что вы также тратите время, пытаясь сделать проще, что не имеет смысла.

Если вам нужна безопасность, тогда используйте фактическую безопасность . Используйте проверки принципала для авторизации или запрета доступа к ресурсам. Запутывание URL-адресов вообще не является безопасностью.

Так что я не вижу никаких проблем с использованием числовых идентификаторов или какого-либо значения при попытке их запутать.

Answer 2

Использование хеша, такого как MD5 или SHA для идентификатора, не очень хорошая идея:

• всегда есть вероятность столкновения. То есть два разных идентификатора хэша к одному и тому же значению.
• Как вы собираетесь восстановить его до действительного идентификатора?

Лучшим подходом, если вы настроены избегать увеличения идентификаторов, будет использование GUID или просто случайное значение при создании идентификатора.

Тем не менее, если безопасность вашего приложения зависит от людей, не угадывающих идентификатор, это указывает на некоторые недостатки в других частях системы. Мой совет: придерживайтесь простого и простого автоинкрементного идентификатора и примените надлежащий контроль доступа.

Answer 3

Хорошей практикой может быть хеширование или рандомизация идентификаторов или других URL-компонентов, если вы не хотите, чтобы ваши URL-адреса были доступными. Это не безопасность, но это препятствует использованию (или злоупотреблению) ресурсов вашего сервера сканерами и может помочь вам определить, когда это произойдет.

Как правило, вы не хотите раскрывать состояние приложения, например, какие идентификаторы будут распределены в будущем, поскольку это может позволить злоумышленнику использовать прогнозирование способами, которые вы не предусмотрели. Например, идентификаторы последовательной транзакции BIND были недостатком безопасности .

Если вы хотите поощрить сканирование или другой обход, более строгим способом будет предоставление ссылок, а не предоставление деталей реализации, которые могут измениться в будущем.

Использование последовательных целых чисел в качестве идентификаторов может значительно сократить ваши расходы и может стать разумным компромиссом.

Answer 4

Я думаю, что хеширование для общедоступных идентификаторов не является плохой вещью, но показ последовательных идентификаторов в некоторых случаях будет плохой вещью. Более того, используйте GUID / UUID для всех ваших идентификаторов. Вы можете даже использовать последовательные GUIDS во многих технологиях, так что это быстрее (на этапе вставки) (хотя и не так хорошо в распределенной среде)

Answer 5

Часто паутинка на сайте - это хорошо. Если вы хотите, чтобы ваша информация была доступна как можно больше, вы хотите, чтобы такие сайты, как Google, собирали данные на вашем сайте, чтобы другие могли их найти.

Если вы не хотите, чтобы люди читали ваш сайт, используйте аутентификацию и запрещайте доступ людям, у которых нет доступа.

Случайно выглядящие URL только создают впечатление безопасности, не давая реальности. Если вы поместите информацию об учетной записи (скрытую) в URL, у каждого будет доступ к учетной записи этого веб-паука.

Answer 6

Мое мнение таково: если что-то есть в сети и обслуживается без авторизации, оно было сделано с намерением сделать его общедоступным. Активная попытка усложнить доступ к нему кажется нелогичной.

Answer 7

Хеширование целого числа - плохая реализация безопасности из-за неясности, поэтому, если это цель, истинный GUID или даже «последовательный» GUID (будь то через NEWSEQUENTIALID () или алгоритм COMB) гораздо лучше.

В любом случае, никто больше не вводит URL, поэтому я не вижу особого смысла беспокоиться о разнице в длине.

Answer 8

Мое общее правило - использовать GUID, если я показываю что-то, что должно отображаться в URL, а также требуются учетные данные для доступа или уникальные для конкретного пользователя (например, идентификатор заказа). http://site.com/orders?id=e4da3b7fbbce2345d7772b0674a318d5

Таким образом, другой пользователь не сможет «заглянуть» в следующий заказ, взломав URL. Им может быть отказано в доступе к чьему-либо заказу, но бросать в них миллионы букв и цифр - довольно четкий способ сказать «не связывайтесь с этим».

Если я показываю что-то общедоступное и не привязанное к конкретному пользователю, то я могу использовать целочисленную клавишу. Например, для отображения изображений вы можете разрешить своим пользователям взломать URL, чтобы увидеть следующее изображение.

http://example.org/pictures?id=4, http://example.org/pictures?id=5 и т. Д.

(На самом деле я бы не стал использовать простой параметр GET, я бы использовал mod_rewrite (или что-то еще) для создания читаемых URL. Что-то вроде http://example.org/pictures/4 -> /pictures.php?picture_id=4 и т. Д.)