Соображения о том, чтобы сделать auto_incremented идентификатор пользователя видимым? - PullRequest
2 голосов
/ 23 февраля 2012

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

Что необходимо учитывать перед реализацией аналогичного стиля генерации идентификатора пользователя?Я занимаюсь разработкой некоммерческого приложения, которое опирается на концепцию «друзей» при назначении различных разрешений между пользователями, но я бы хотел, чтобы основные профили всех пользователей были доступны для просмотра по простому URL-адресу, например app.com/users/userid.Более подробная информация о профиле будет доступна только «друзьям» этого пользователя, которые были подтверждены этим пользователем.

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

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

Ответы [ 2 ]

2 голосов
/ 24 февраля 2012

OWASP - Небезопасные ссылки на прямые объекты

Дает довольно хорошее отношение к предмету. На самом деле, я настоятельно рекомендую OWASP в целом для обеспечения безопасности при разработке веб-приложений. Я всегда оцениваю свои веб-проекты по ТОП-10 угрозам безопасности, обнаруженным на сайте.

1 голос
/ 23 февраля 2012

Это совсем не проблема. На самом деле, я бы почти сказал обратное: если вам нужно скрыть параметры в URL-адресе для обеспечения безопасности, значит, вы делаете это неправильно; безопасность должна быть обработана в коде.

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

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

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

...