Там опасность к созданию UUID в клиентском JavaScript?

Memcached имеет некоторые библиотеки с открытым исходным кодом, если я не ошибаюсь поэтому, если Вы хотите пойти путем на 64 бита, Вы не можете просто перекомпилировать?

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

14
задан Community 23 May 2017 в 10:28
поделиться

4 ответа

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

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

16
ответ дан 1 December 2019 в 12:27
поделиться

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

3
ответ дан 1 December 2019 в 12:27
поделиться

Да. Риск не относится к UUID, любой идентификатор, созданный на стороне клиента, имеет определенные риски, в зависимости от того, что вы делаете с идентификатором. Проблема в том, что аутентифицировать Javascript очень сложно. Если вы принимаете идентификатор, сгенерированный клиентом, вы принимаете любые идентификаторы от хакеров.

Риски могут включать,

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

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

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

2
ответ дан 1 December 2019 в 12:27
поделиться

Есть ли причина, по которой вы не можете заставить базу данных генерировать (увеличивать) идентификатор?

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

2
ответ дан 1 December 2019 в 12:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: