Member 9129971 Ответов: 2

Как скрыть customerid в клиентском приложении

У меня есть угловое одностраничное приложение, которое использует api , я должен передать идентификатор клиента в качестве параметра, чтобы получить данные клиента, но это небезопасно, так как clientid открыт на переднем конце, и любой может легко изменить идентификатор пользователя и передать параметр, и он получит другие данные клиента. Как я могу защитить его так, чтобы никто не мог видеть другие клиентские данные?

Что я уже пробовал:

Исследовал его и нашел несколько способов, но для этого нужна лучшая практика.

2 Ответов

Рейтинг:
1

Richard Deeming

То, что вы описали, - это небезопасная прямая ссылка на объект:
Топ-10 2013-A4-небезопасные прямые ссылки на объекты-OWASP[^]

Использование последовательного номера для доступа к данным для различных записей делает тривиальным для злоумышленника угадать URL-адрес для данных других пользователей.

Вы можете сделать их жизнь сложнее, добавив идентификатор GUID[^] ключ к записи, и только с помощью этого ключа можно получить данные.

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

Member 9129971

Я подумал об идее guid, но, как вы сказали,она не является надежной.А для второго пункта у меня есть два варианта
первый вариант:используйте случайно сгенерированный токен
во время входа в систему пользователь предоставит логин-пароль, после успеха предоставит ему токен и для следующих вызовов api пользователь будет использовать токен.Этот токен сохраняется в базе данных вместе с идентификатором пользователя, также этот токен имеет время истечения срока действия.после истечения срока действия токен истечет, и пользователь должен будет повторно войти в систему, чтобы получить новый токен.
Теперь нам не нужно выставлять userid, и мы можем просто предоставить данные пользователю против его динамического токена expirable.

второй вариант:используйте JWT или owin identity token
Для этого пользователь предоставит имя пользователя пароль во время входа в систему и получит токен волшебным образом и генерацию токена за кулисами.

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

Richard Deeming

До тех пор, пока ваш API доступен только по протоколу HTTPS, первый вариант должен быть в порядке. Это аналогичная идея "cookie аутентификации форм", которую вы бы использовали на обычном веб-сайте, за исключением лучшего контроля над тем, когда он отправляется, и, следовательно, лучшей защиты от XSRF.

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

Рейтинг:
1

Member 12392776

@формат HTML.HiddenFor(модель=>model.Id)

Richard Deeming

Во-первых, это не помешает никому просмотреть удостоверение. Вы можете просто просмотреть источник страницы,и значение будет там.

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

Member 9129971

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