Зашифровать / расшифровать первичный ключ вместо использования UID?

Question

Хотя я всегда проверяю, что кому-то разрешен доступ к записи, я обычно использую UID в строках запроса, так как чувствую, что это не поощряет искушение "покопаться" в этом? Id = 1,? Id = 2.

Я нахожу, однако, что это немного усложняет поиск по нескольким таблицам, так как вам нужно хранить UID, а не только идентификатор записи.

Если бы я пропустил зашифрованную строку идентификатора через строку запроса и затем расшифровал ее для выполнения запроса к базе данных, это добавило бы огромные накладные расходы?

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

Это действительно плохая идея?

Answer 1

Почему это имеет какое-то отношение к тому, как вы получаете доступ к своим данным, доступу и отображению - это две разные сущности. Ваш ключ должен использоваться в запросе, но вам не нужно отображать его, если вы этого не хотите. Вы можете хэшировать его, вы можете переписать мод, чтобы он никогда не был виден в URL ... Есть много опций, все еще запрашивая ключ в ваших таблицах. Вы даже можете создать его на лету для отображения, если вы установите шаблон. P + IDHASH + ANATTRIBUTE или что-то. использование base64 для целого числа и декодирование для выполнения запроса не будут стоить вам больше миллисекунды или около того. помните, что вы не хэшируете свои запросы, поэтому они останутся прежними, вы закодируете / расшифруете один элемент, который не является проблемой со временем

Answer 2

Вы должны обязательно проверять разрешения на каждый запрос. Вы никогда не должны полагаться только на ввод данных для безопасности!

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

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

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

---

Поскольку теперь я увидел вашу реальную проблему в комментарии, я могу предложить использовать какой-то дополнительный хэш для каждого обновления, которое делает пользователь, и сохранить его в сеансе пользователя. Затем проверьте, использует ли пользователь тот же самый хеш, например ::1010*.

$hash = md5(microtime());
$_SESSION['secret_user_hash'] = $hash;

И поместите его в URL, например:

&z=<?php echo substr($hash, 5, 10); ?>

И после того, как пользователь сделает запрос, просто проверьте, является ли он тем же хешем.

Имейте в виду, что если вы используете тяжелый AJAX, вы всегда должны обновлять свой хэш, когда вы меняете его в сеансе. Лучший способ, которым я могу придумать, - это сохранить массив в сеансе случайного хэша (например, 5) и использовать его случайным образом для запроса. Таким образом, у вас большой пул, и вам не нужно обновляться после каждого запроса.

Answer 3

Сделайте ваш UID хешем и передайте его.

Если вы не хотите проводить рефакторинг всей своей схемы и кодовой базы, то кодируйте ее в rot13 / base64.

Answer 4

Почему бы просто не base64encode / декодировать идентификаторы? Если вы делаете это только для того, чтобы не дать законным пользователям поэкспериментировать с игрушками, с которыми у них есть разрешение на игру, на самом деле нет смысла делать что-то особенно причудливое, чтобы отговорить их.