Существует ли проблема безопасности при отображении значения ключа для пользователей в URL-адресе? - PullRequest
3 голосов
/ 06 сентября 2010

Я использую значение ключа сущностей в моем хранилище данных в качестве уникального идентификатора в URL для извлечения записи:

http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ

Это не очень привлекательное решение и не оптимизировано для SEO, но я обнаружил, что это самый простой способ уникальной идентификации сущности в App Engine / Java.

Моя главная задача, однако, заключается в том, существует ли какая-либо проблема безопасности, связанная с отображением уникального значения ключа для объекта?

Ответы [ 4 ]

5 голосов
/ 06 сентября 2010

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

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

3 голосов
/ 06 сентября 2010

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

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

Как и вы, мне не очень нравится отображать идентификаторы базы данных, но ЕСЛИ вы защищаете свое приложение должным образом не стоит беспокоиться, так как знание идентификатора сущности не будет полезным.

1 голос
/ 06 сентября 2010

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

Документация охватывает это, хотя:

Примечание: Строковый ключ может быть преобразован обратно в необработанные данные ключа.Это позволяет легко угадать другие ключи, когда один известен.Хотя строковые значения ключей безопасно включать в URL-адреса, приложение должно делать это только в том случае, если угадывание ключа не является проблемой.

Гораздо чище делать что-то вроде этого:

foo = FooModel.get_by_id(int(foo_id))

Это не мешает злоумышленникам угадывать идентификаторы, но, по крайней мере, не обманывает вас, думая, что идентификаторы "непрозрачны" (и вы можете тривиально изменить идентификатор, чтобы проверить управление доступом, вместо того, чтобы возитьсявокруг с base64-protobuf-закодированными данными).

0 голосов
/ 06 сентября 2010

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

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

...