Чи достатньо захистити сторінку статусу замовлення лише випадковою URL-адресою?

Після того як (корпоративний) клієнт придбав деякі товари в нашому інтернет-магазині, ми надсилаємо електронний лист із оглядом того, що він купив йому.

Ми хотіли б повідомити свого клієнта про отримані платежі, відстеження пакетів тощо. Я б вирішив це, призначивши кожному замовлення випадковий ідентифікатор і додав посилання на кожну пошту. Посилання може бути таким: http://shop.foo.bar/order/rwklvc46g9wt7kvy09f1

Чи вживали б ви додаткові заходи щодо захисту даних? Або вибрати зовсім інше рішення?

Переваги:

• немає жодних оновлень стану оновлень на пошту (особливо якщо трапляються часті оновлення)
• єдине джерело інформації (ніколи не застаріло)
• підлягає спільному доступу (наприклад, своєму начальнику чи колегам)

Недоліки:

• приватні дані, відкриті на загальнодоступному веб-сайті (наприклад, номери телефонів, платіжні дані)

Без додаткової безпеки немає. Випадкові URL-адреси постійно сканують. Однак це добре, коли робиться зі сторінкою входу для автентифікації користувача.

Проміжне рішення - переконатися, що на сторінці статусу немає персональних даних, а лише загальна інформація. Наприклад, "PAID BY CC", а не "PAID by VISA 1234567891" та "Shipped" замість "Доставка у John Doe, 123 Blue Street" тощо.

Я думаю, ви повинні більше захищати ці дані. Що стосується простоти системи, я дуже погоджуюся, що публічних URL-адрес із випадковою та унікальною рядком достатньо та зручно.

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

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

Так, це достатньо, якщо:

1. ви просто надсилаєте посилання електронною поштою та не надсилаєте його в Google. Але відповідно до вашого питання це ви робите, тому Google не може ознайомитись із посиланням на нього, яке ніколи не буде індексуватися / сканувати.

2. ви робите ідентифікатор, який використовується у посиланні, випадковим і досить довгим. Якщо це не випадково, але ви використовуєте просте додаткове ціле число, оскільки ідентифікатор одного з ваших клієнтів може легко помітити, що, ввівши посилально прості числа, він може прочитати всі інші замовлення. Якщо це випадково, але недостатньо довго (скажімо, він складається лише з 4 цифр / букв), то навіть із домашнім ПК нападати на ваші замовлення буде легко, мені просто потрібно спробувати (26 + 10) ^ 4 = 1679,616 можливих комбінацій. Скажімо, я запускаю сценарій, який пробує одне посилання в секунду, для сценарію знадобиться менше 20 днів, щоб грубо примусити всі можливі посилання та прочитати всі ваші замовлення.

3. ВАЖЛИВО: для підвищення безпеки слід видалити посилання через певну кількість днів (тобто через 1 місяць). Це трюк, щоб зробити його надійним. Таким чином, навіть якщо хтось намагатиметься змусити ваші посилання, йому знадобиться величезна потужність кальцію, інакше його атака ніколи не буде достатньо швидкою, щоб спробувати всі можливі комбінації, перш ніж їх видалити. І навіть якщо він має величезну потужність calc, він навряд чи зможе перевірити більше однієї посилання в секунду, оскільки сервер, який обробляє ваші замовлення, може почати відмовлятися від його з'єднання, якщо він спробує підключитися кілька разів на секунду. FYI: видалення посилання не означає, що ви повинні видалити весь порядок у БД. Ви можете використовувати інший первинний ключ для таблиці замовлень (простий вкладення автоматичного збільшення), а також можна використовувати поле UNIQUE (яке дозволяє NULL) під назвою link_id, яке є тим, яке ви вводите за посиланням. Через місяць вам просто потрібно видалити значення link_id і встановити його NULL. Таким чином замовлення все ще буде в таблиці та переглядатиметься на панелі адміністратора, але пряме посилання більше не буде дійсним для прямого перегляду сторінки замовлення.