простое шифрование данных с помощью javascript/php

Question

Я пересылаю своих посетителей со страницы проверки до /store/order/view/?id=735, но я не хочу, чтобы они могли просматривать только чей-либо заказ, поэтому мне нужно зашифровать 735. Что лучше способ сделать это, чтобы Javascript мог зашифровать его, и PHP/MySQL может расшифровать его?

Как насчет вместо? Id = 735 Я делаю ?key=735-[TIMESTAMP_ORDER_WAS_PLACED], как вы думаете, это достаточно безопасно?

Answer 1

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

Answer 2

Не делайте этого, безопасного это на стороне серверавсегда, ничто не является безопасным, если вы делаете это в JavaScript - наоборот, это очень легко сломать.

С помощью сеансов или любого другого механизма, который вы хотите, сервер не должен обслуживать страницу заказа всем, кто не сможет ее увидеть.

Answer 3

Почему бы не просто сделать так, чтобы только зарегистрированные пользователи, связанные с указанным заказом, могли видеть эту страницу?

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

Answer 4

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

Однако, если вы идете по маршруту запроса и считаете, что генерируете страницу со ссылкой в ​​PHP, вы можете использовать функции mcrypt_encrypt/mcrypt_dencrypt в PHP для создания ссылки, а затем дешифровать, когда запрос приходит

При этом вам все равно потребуется уникальный ключ шифрования для шифрования/дешифрования, и это будет идентификатор сеанса PHP.

Answer 5

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

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

Answer 6

Некоторых вариантов (от наименее к наиболее preferrable) и мысль:

Вариант 1) Вы можете использовать какое-то менее угадываем хэш вместо OrderID. Это все еще не безопасно, это просто делает id труднее догадываться.

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

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

Вариант 4) Сделайте пользователей правильными учетными записями, с которыми связаны заказы.

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

md5(order_id + time() + random_salt_value) 

Наконец, сделайте все это на стороне сервера. Все, что генерируется javascript, должно рассматриваться как «вход от пользователя» и никогда не должно быть полностью доверенным. Если у вас должен быть рабочий процесс на основе javascript, у него есть ajax конечные точки для всего этого.