Безопасно ли выставлять UserId клиенту? - PullRequest
Новая
       13

Безопасно ли выставлять UserId клиенту?

0 голосов
/ 06 июля 2019

Я занимаюсь разработкой веб-приложения, и мне интересно, не представляет ли клиенту UserId s потенциальную уязвимость безопасности.(Под UserId я ссылаюсь на Id пользовательского объекта Identity, созданного Identity Framework и используемого в качестве PK таблицы пользователей.)

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

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

Если это так, как мне поступить?Поможет ли хеширование UserId решить проблему или есть лучшие подходы?

EDIT

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

Ответы [ 3 ]

2 голосов
/ 08 июля 2019

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

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

Если идентификаторы UID являются просто идентификаторами для пользователей.Знание UID пользователя не дает вам никаких разрешений, связанных с этим пользователем.Совместное использование UID в URL-адресах примерно так же безопасно, как и совместное использование вашего имени пользователя на Github или вашего уникального идентификатора при переполнении стека.

Переполнение стека отображает идентификаторы пользователей в их URL-адресах, чтобы обеспечить работу поисков профиля пользователя: https://stackoverflow.com/users/10158551/xing-zou

В любом случае, это зависит от вашего дизайна, и вам нужно учесть больше, чем мы могли бы.

См. Должен ли я предоставить публичный идентификатор пользователя?

0 голосов
/ 06 июля 2019

Я бы отнес это к категории низкого риска.Предоставление идентификаторов пользователей увеличивает поверхность риска, поскольку вы правильно определили.

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

Вы можете структурировать это следующим образом, чтобы избежать воздействия низкого риска: 

GET /posts

{
  "postId": "AJDIWC",
  "isAuthor": true,
  "content": "This is a post by the user."
},
{
  "postId": "LISHWE",
  "isAuthor": false,
  "content": "This is a post by another user."
}

РЕДАКТИРОВАТЬ

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

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

0 голосов
/ 06 июля 2019

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

...