После того, как (корпоративный) клиент купил некоторые товары в нашем интернет-магазине, мы отправили электронное письмо с обзором того, что он купил ему.
Мы хотели бы информировать наших клиентов о полученных платежах, отслеживании пакетов и т. Д. Я бы решил эту проблему, назначив каждому заказу случайный идентификатор и добавив ссылку на каждое письмо. Ссылка может быть такой:
http://shop.foo.bar/order/rwklvc46g9wt7kvy09f1
Будете ли вы принимать дополнительные меры для защиты данных? Или выбрать совершенно другое решение?
Преимущества:
- нет анонимных обновлений статуса по почте (особенно если происходят частые обновления)
- единый источник информации (никогда не устаревший)
- поделиться (например, с его начальником или коллегами)
Недостатки:
- личные данные, представленные на общедоступном веб-сайте (например, номера телефонов, реквизиты платежа)
Ответы:
Без дополнительной безопасности нет. Случайные URL сканируются постоянно. Тем не менее, это хорошо, когда вы выполняете страницу входа для аутентификации пользователя.
Промежуточное решение - убедиться, что на странице состояния нет личных данных, а только общая информация. Например, «Оплачено по CC», а не «Оплачено по VISA 1234567891» и «Отправлено» вместо «Отправлено Джону Доу, 123 Blue Street» и т. Д.
источник
Я думаю, что вы должны защитить эти данные больше. Что касается простоты системы, я полностью согласен с тем, что общедоступных URL со случайной и уникальной строкой достаточно и удобно.
Однако, если будут отображаться способы оплаты (включая информацию о кредитной карте), электронные письма или телефоны, вам необходимо защитить эти данные. Это также зависит от того, в какой части мира вы находитесь, но в большинстве из них эта потребность распространяется на юридические вопросы и защиту данных пользователя.
То, что делает большинство веб-сайтов для покупок в подобных ситуациях, - это либо запрашивать учетные данные (логин / пароль), либо номер для отслеживания с кодом отслеживания, либо что-то, что может иметь только пользователь или доверенные лица пользователя.
источник
Да, этого достаточно, если:
Вы просто отправляете ссылку по электронной почте и не отправляете ее в Google. Но в соответствии с вашим вопросом это то, что вы делаете, поэтому у Google нет возможности узнать ссылку на нее, она никогда не будет проиндексирована / просканирована.
Вы делаете идентификатор, используемый в ссылке, случайным и достаточно длинным. Если это не случайно, но вы используете простое инкрементное целое число в качестве идентификатора, один из ваших клиентов может легко заметить, что, вводя простые инкрементные числа в ссылке, он может читать все остальные заказы. Если он случайный, но недостаточно длинный (скажем, он состоит только из 4 цифр / букв), было бы легко даже с помощью домашнего компьютера атаковать ваши приказы грубой силой, мне просто нужно попробовать (26 + 10) ^ 4 = 1 679 616 возможных комбинаций. Допустим, я запускаю скрипт, который пробует одну ссылку в секунду, и скрипту потребуется менее 20 дней, чтобы перебрать все возможные ссылки и прочитать все ваши заказы.
ВАЖНО: для повышения безопасности вы должны удалить ссылку через определенное количество дней (т.е. через 1 месяц). Это трюк, чтобы сделать его безопасным. Таким образом, даже если кто-то попытается обмануть ваши ссылки, ему понадобится огромная вычислительная мощность, иначе его атака никогда не будет достаточно быстрой, чтобы попробовать все возможные комбинации, прежде чем они будут удалены. И даже если он обладает огромной вычислительной мощностью, он вряд ли сможет протестировать более одной ссылки в секунду, потому что сервер, который обрабатывает ваши заказы, может начать отказывать в своем соединении, если он попытается установить соединение несколько раз в секунду. К вашему сведению: удаление ссылки не означает, что вы должны удалить весь заказ в БД. Вы можете использовать другой первичный ключ для таблицы заказов (простой автоинкремент int) и можете использовать поле UNIQUE (допускающее NULL) с именем link_id, которое вы вводите в ссылке. Через месяц вам просто нужно удалить значение link_id и установить его в NULL. Таким образом, заказ будет по-прежнему в таблице и доступен для просмотра из вашей админ-панели, но прямая ссылка больше не будет действительной для прямого просмотра страницы заказа.
источник