Как скрыть идентификатор базы данных из HTML / Javascript

Question

Очевидно, что в зависимости от типа / контекста данных, возвращаемых веб-интерфейсу (в моем случае это HTML / Javascript, .NET Csharp и JSON в качестве транспорта данных), если мне нужно вернутьID говорит о сообщении, которое является автоматически сгенерированным первичным ключом (Int64), каков наилучший способ «скрыть» этот настоящий идентификатор?

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

Кажется, что есть многоидей / комментариев о методах, но ничего не щелкнуло.

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

Конечно, думать, что GUID будет гораздо сложнееугадайте / получите еще один, чтобы получить доступ к записи?

Какие идеи или лучшие практики используют люди?

Заранее спасибо, Дэвид.

Answer 1

Относительно безопасности у вас есть несколько аспектов:

• Сеанс угона
• Доступ / Изменение / Создание / Удаление записей, на которые пользователь не авторизован
• Доступ без аутентификации
• Межсайтовые * атаки
• Атаки "человек посередине"
• и т.д.

Меры по их устранению зависят от вашей архитектуры и требований безопасности.

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

Некоторые пункты относительно «ID не должны быть угаданными»:

• «Правильное» решение
  Проблема исчезнет в тот момент, когда вы правильно внедрите аутентификацию + аутентификацию потому что правильно реализованы эти два убедитесь, что только аутентифицированные пользователи могут получить доступ к все что угодно И что каждый пользователь может получить доступ только к тем вещам, которые ему разрешены. Даже если аутентифицированный пользователь знает правильный идентификатор чего-то, к чему у него нет доступа, это будет безопасно, поскольку он не сможет получить к нему доступ.
  

• "слабое решение"
  создайте ConcurrentDictionary в качестве многопоточного кеша в памяти и поместите туда реальные идентификаторы плюс «временные идентификаторы» (например, при доступе к первой записи только что сгенерированных идентификаторов GUID). Вы можете объединить этот временный идентификатор с некоторой солью и / или шифрованием и / или хэшем некоторых специфических для соединения аспектов (таких как IP-адрес клиента, время и т. Д.). Затем при каждом доступе вы проверяете с помощью ConcurrentDictionary и действуете соответствующим образом ... один положительный эффект: после перезапуска приложения (например, перезапуск пула приложений) та же запись получает другой идентификатор, поскольку это только кэш в памяти ... хотя это вряд ли можно использовать в сценарии веб-фермерства

Answer 2

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

Если это так, то вам действительно нужно сделать шаг назад и пересмотреть подход к безопасности. Если пользователь может получить доступ к записям, которые он не имеет права на просмотр, вы не обеспечите надлежащую защиту ваших ссылок на объекты - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References

Подход GUID попытается обеспечить безопасность за счет неясности, см. Использует ли безопасность GUID, хотя за неясностью? относительно того, нужно ли вам это делать, исходя из своих обстоятельств.

Answer 3

Все остальные ответы (3) не охватывали вероятность того, что это будет не прошедший проверку, не прошедший проверку подлинности, не прошедший сеанс и не вошедший в систему пользователь.

Например, страница подтверждения после заказа и т. Д ...

В этом случае ваша аутентификация основана на секрете в URL.Вы используете секрет, который для всех практических целей является неосуществимым и уникальным для каждой записи.Затем вы предполагаете, что если у пользователя есть этот секрет, то у него есть доступ к указанной записи и т. Д.

Реальная задача - найти хороший способ создать секретный UUID.Многие разработчики возьмут SHA1 () из rand () + time () + uuid () + remote_ip () или что-то в этом роде (что обычно достаточно), но я уверен, что есть много документации по этому вопросу.

Да, в ситуации, когда пользователь, не прошедший проверку подлинности, получает доступ к определенной части данных или выполняет какое-либо действие (например, сброс пароля), вам необходимо иметь второй идентификатор (например, varchar 40) наваши записи с уникальным ключом (как вы обрисовали в общих чертах).Заполните его очень случайными данными, и если у них есть этот секрет, то впустите их.

Берегите себя.

Answer 4

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

В любом случае, если вы хотите испортить URL, я рекомендую заглянуть в Рейндаэль. Мы используем его здесь для раздачи токенов. По сути, этот метод шифрования позволяет как зашифровать, так и расшифровать. Поэтому вы можете зашифровать идентификатор, отправить его клиенту, клиент отправит его обратно, и вы можете просто расшифровать снова. Нет необходимости в дополнительной записи базы данных. Еще более безопасным является шифрование / дешифрование идентификатора записи с каким-то IP-адресом для текущего клиента, поэтому даже поиск URL-адресов будет уменьшенной проблемой.

См .: http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndael.aspx

Answer 5

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