Желательно ли шифровать параметры URL вместо того, чтобы они были в виде простого текста?

Question

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

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

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

Answer 1

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

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

Answer 2

Если вы хотите запретить пользователям возиться с аргументами GET, я бы порекомендовал следующее:

Добавьте скрытую форму на все ваши страницы.Если щелкнуть в любом месте страницы, некоторые данные будут заполнены в форме и безопасно отправлены через POST / SSL.Вдобавок к деталям отправки, передайте URL, куда вы хотите направить пользователя.

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

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

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

Answer 3

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

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

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