URL-адреса https з параметром маркера: наскільки це безпечно?

На нашому веб-сайті ми пропонуємо користувачам симуляцію на основі їхньої приватної інформації (надається через форму). Ми хотіли б дозволити їм пізніше повернутися до результатів моделювання, але не змушуючи їх створювати обліковий запис для входу в систему / пароль.

Ми думали надіслати їм електронний лист із посиланням, за яким вони могли б отримати свої результати. Але, природно, ми маємо захистити цю URL-адресу, оскільки йдеться про приватні дані.

Отже, ми маємо намір передавати маркер (наприклад, 40-символьну комбінацію букв і цифр або хеш MD5) у URL-адресу та використовувати SSL.

Нарешті, вони отримають такий електронний лист:

Привіт,
поверніть свої результати на https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Що ви думаєте про це? Це досить безпечно? Що б ви мені порадили для покоління лексем? А як щодо передачі параметрів URL-адреси в запиті https?

SSL захищає параметри запиту під час передачі; однак електронна пошта сама по собі не захищена, і електронна пошта може відбиватися по будь-якій кількості серверів, перш ніж дістатися до місця призначення.

Також, залежно від вашого веб-сервера, повна URL-адреса може реєструватися у файлах журналу. Залежно від того, наскільки конфіденційні дані, ви можете не хотіти, щоб ваші ІТ-працівники мали доступ до всіх маркерів.

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

Нарешті, і що робить це дуже небезпечним, це те, що URL-адреса надсилається в заголовок Referer усіх запитів на будь-який ресурс, навіть на сторонні ресурси. Отже, якщо ви використовуєте Google Analytics, наприклад, ви надішлете Google маркер URL-адреси та всі їм.

На мій погляд, це погана ідея.

Я б використав для цього файли cookie. Робочий процес повинен бути таким:

1. Користувач заходить на ваш сайт вперше.
2. Сайт встановлює файли cookie
3. Користувач вводить дані. Дані зберігаються в БД за допомогою якогось ключа, який зберігається в файлі cookie.
4. Коли користувач йде, ви надсилаєте йому електронне повідомлення із посиланням https:
5. Коли користувач повертається, сайт виявляє файл cookie і може представити користувачеві старі дані.

Тепер користувач хоче використовувати інший браузер на іншій машині. У цьому випадку запропонуйте кнопку "передати". Коли користувач натисне на цю кнопку, вона отримає "жетон". Вона може використовувати цей маркер на іншому комп’ютері для скидання файлу cookie. Таким чином, користувач вирішує, наскільки безпечно вона хоче передати маркер.

SSL захищає вміст даних, що передаються, але я не впевнений у URL-адресі.

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

Якщо електронна пошта користувача скомпрометована, і зловмисник отримує посилання першим, ну, ви готові. Але у користувача також є більші проблеми.

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

Ну, маркер захищений при передачі через SSL. Проблема, яку ви збираєтеся мати, полягає в тому, що вона доступна для людей (тих, для кого вона не призначена) завдяки можливості перегляду URL-адреси.

Якщо це приватна інформація, така як SSN, я не думаю, що я б надсилав URL-адресу електронною поштою. Я волів би, щоб вони створили ім’я користувача та пароль для сайту. Надто легко компрометувати електронну пошту з такою інформацією, яка поставлена ​​на карту для вас і для них. Якщо чийсь рахунок скомпрометований, він постане під сумнів, чия це вина насправді. Чим безпечніше, тим краще ви з суворої точки зору.

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

До речі, із запитами https взагалі не виникає проблем із параметрами.

В даний час це буде поганою ідеєю. Ви покращите безпеку за допомогою простого використання. Як вже було сказано раніше, SSL захистить лише передачу інформації між сервером та клієнтським браузером і лише запобіжить атаці середньої людини. Електронні листи дуже ризиковані та небезпечні.

Найкращою буде автентифікація імені користувача та пароля для доступу до інформації.

Мені ідея печива подобається більш-менш. Вам також слід зашифрувати інформацію про файли cookie. Вам також слід згенерувати маркер із сіллю та ключовою фразою плюс $ _SERVER ['HTTP_USER_AGENT'], щоб обмежити ймовірність атаки. Зберігайте якомога більше нечутливої ​​інформації про клієнта у файлі cookie для перевірки використання.

Ключова фраза може зберігатися в файлі cookie для зручності використання, але майте на увазі, що файл cookie також може бути вкрадений = (.

Краще дозвольте клієнту ввести ключову фразу, яку він надав, яка також зберігається в базі даних разом із його даними.

Або ключ можна використовувати у випадку, якщо особа використовує іншу машину, яка відрізняється параметрами $ _SERVER ['HTTP_USER_AGENT'] або просто пропускає файл cookie. Таким чином, файл cookie може бути переданий або встановлений.

Також переконайтеся, що конфіденційні дані зашифровані в базі даних. Ти ніколи не дізнаєшся ;)

Ви знаєте, що якщо який-небудь хакер отримає доступ до вашої бази даних, багато персональної інформації може бути надано вільно?

Після цього я б сказав, що це непогано як ідея. Я б не використовував MD5 або SHA1, оскільки вони не дуже безпечні для хешування. Їх можна досить легко «розшифрувати» (я знаю, що це не шифрування).

В іншому випадку я міг би скористатися другою інформацією, яка не буде надіслана електронною поштою паролем. Причина досить проста: якщо хтось отримає доступ до електронної пошти користувача (досить просто за допомогою Hotmail, якщо ви не вб'єте сеанс), він матиме доступ до будь-якої інформації, надісланої користувачем.

Зверніть увагу, що HTTPS захистить та зашифрує дані, що надсилаються з вашого веб-сайту кінцевому користувачеві. Нічого іншого, сприймайте це як надійний канал. Нічого більше нічого менше.

Наскільки я розумію вашу ідею, теоретично хтось міг ввести випадковий 40-символьний рядок або хеш MD5 і отримати комусь інші дані. Хоча це може бути малоймовірним, це потрібно зробити лише один раз.

Кращим рішенням може бути надсилання користувачеві маркера, а потім попросити його ввести деякі деталі, такі як ім’я, поштовий індекс, ssn або їх комбінацію.