https URL с параметром токена: насколько он безопасен?


89

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

Мы думали отправить им электронное письмо со ссылкой, по которой они могли бы получить свои результаты. Но, естественно, мы должны защитить этот URL, потому что на карту поставлены личные данные.

Итак, мы намереваемся передать токен (например, комбинацию букв и цифр из 40 символов или хэш MD5) в URL-адресе и использовать SSL.

Наконец, они получили бы такое письмо:

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

Что вы думаете об этом? Достаточно ли это безопасно? Что бы вы посоветовали мне для генерации токенов? А как насчет передачи параметров URL в запросе https?


Ответы:


97

SSL защитит параметры запроса при передаче; однако электронная почта сама по себе небезопасна, и электронная почта может перебраться через любое количество серверов, прежде чем попадет к месту назначения.

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

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

Наконец, что делает это очень небезопасным, URL-адрес отправляется в заголовке Referer всех запросов для любого ресурса, даже сторонних ресурсов. Так, если вы, например, используете Google Analytics, вы отправите Google токен URL и все им.

На мой взгляд, это плохая идея.


1
Я не думал о проблеме HTTP-реферера, но ссылка url будет перенаправлять на страницу результатов, это не будет правильная страница (без Google Analytics или другого стороннего скрипта).
Flackou,

5
Разве большинство браузеров не удаляют реферер при переходе с HTTPS на HTTP?
Кевин Марк

2
Это похоже на ссылку для активации пользователя (или сброса пароля), верно? Как же тогда поступить с этим делом? Многие веб-сайты отправляют URL-адреса сброса на электронную почту, POST не вариант, поскольку он должен быть интерактивным. Спасибо.
pinkpanther

3
так какое же решение?
RT

1
что, если токен в URL-адресе не совпадает с токеном, используемым для запросов api, и действует только один час, в чем тогда будет вред?
user1709076

13

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

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

Теперь пользователь хочет использовать другой браузер на другом компьютере. В этом случае предложите кнопку «перевод». Когда пользователь нажимает на эту кнопку, он получает «токен». Она может использовать этот токен на другом компьютере для сброса cookie. Таким образом, пользователь решает, насколько безопасно он хочет передать токен.


4

SSL защищает содержимое передаваемых данных, но я не уверен насчет URL.

Тем не менее, один из способов уменьшить опасность повторного использования злоумышленником этого URL-токена - убедиться, что каждый токен можно использовать только один раз. Вы даже можете установить cookie, чтобы законный пользователь мог продолжать использовать ссылку, но после первого доступа она будет работать только для тех, у кого есть cookie.

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


11
Перед передачей URL-адреса SSL-соединение защищено.
Дэвид

1

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


Точно, но многие сайты не заморачиваются по этому поводу и отправляют логины / пароли по почте. Но это не повод им подражать ...
Flackou

Я согласен, что нет причин имитировать их, но обычно они советуют вам сменить пароль после первого входа в систему.
Джейсон Пуньон

1

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

Если это частная информация, такая как SSN, я не думаю, что отправлю URL-адрес по электронной почте. Я бы предпочел, чтобы они создали имя пользователя и пароль для сайта. Слишком легко скомпрометировать электронную почту с такой информацией для вас и для них. Если чью-то учетную запись компрометируют, возникает вопрос, чья это действительно вина. С точки зрения CYA, чем выше уровень безопасности, тем лучше вы.


1
Вы правы: URL-адрес, например, останется в истории браузера
Flackou,

0

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

Между прочим, никаких проблем с параметрами в https-запросе нет.


Вы правы насчет риска атак методом грубой силы. Я не понимаю, как мы можем предотвратить атаки ботов. Запрет «настаивать» на IP-адресах не будет достаточной защитой. У вас есть идеи по этому поводу?
Flackou,

Фактически, с тем типом ключевого пространства, о котором мы говорим, поместив if (this_ip_number_has_requested_an_invalid_token_today ()) sleep (5); в вашем скрипте load_simulation вполне достаточно защиты. (Ограничение скорости - одна из характеристик хороших механизмов аутентификации.)
хаос,

Спасибо за Ваш ответ. Но я подумал, что один и тот же бот может легко получить разные IP-адреса, что сделало ограничение скорости IP-адресов недостаточным. Я ошибся?
Flackou,

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

0

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

Лучше всего будет аутентификация имени пользователя и пароля для доступа к информации.

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

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

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

Или ключ можно использовать в случае, если человек использует другую машину, которая отличается параметрами $ _SERVER ['HTTP_USER_AGENT'] или просто пропускает cookie. Таким образом, cookie может быть передан или установлен.

Также убедитесь, что конфиденциальные данные в базе данных зашифрованы. Ты никогда не узнаешь ;)


-1

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

После этого я бы сказал, что это неплохая идея. Я бы не стал использовать MD5 или SHA1, поскольку они не очень безопасны для хеширования. Их достаточно легко «расшифровать» (я знаю, что это не шифрование).

В противном случае я, возможно, использовал бы вторую информацию, которая не была бы отправлена ​​по электронной почте в виде пароля. Причина довольно проста: если кто-то получит доступ к электронной почте пользователя (это довольно просто с помощью hotmail, если вы не завершите сеанс), он получит доступ к любой информации, отправленной пользователем.

Обратите внимание, что HTTPS будет защищать и шифровать данные, отправляемые с вашего сайта конечному пользователю. Ничего другого, воспринимайте это как безопасный туннель. Ни больше, ни меньше.


Как именно расшифровывается соленый хеш SHA1 в любом смысле этого слова?
Eli

«Вы знаете, что если какой-либо хакер получит доступ к вашей базе данных, он может свободно предоставить много личной информации?» Да, но разве это не проблема для всех сайтов ??
Flackou,

@Flackou да, но если вы получите доступ к базе данных PayPal, вы не найдете четко сохраненной информации о кредитной карте, все зашифровано. @Eli: theregister.co.uk/2005/02/17/sha1_hashing_broken
Эрик,

-1

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

Лучшим решением может быть отправить пользователю токен, а затем попросить его ввести некоторые данные, такие как их имя, почтовый индекс, ssn или их комбинацию.


5
SSN? Ты серьезно? В любом случае, я предлагаю вам посчитать, сколько существует 40-символьных случайных строк. Это больше, чем просто «крайне маловероятно»,
Эли

Вы правы, нам, вероятно, следует добавить еще один параметр в URL-адрес, например, адрес электронной почты (даже если a..z + A..Z + 0..9 = 62 символа, а 62 ^ 40 - довольно большое число).
Flackou,

Ребята, 62 ^ 40 - это значительно больше, чем количество атомов во Вселенной. Это буквально непостижимо.
Eli

1
Я удивлен, как много людей не могут понять масштаб этих чисел. Если вы угадываете МИЛЛИОН жетонов в секунду, гораздо более вероятно, что солнце выгорит раньше, чем вы получите удар
Эли

4
Ричард, похоже, вы указываете на то, что обычно называют парадоксом дня рождения ... имеет значение не только количество возможных комбинаций, но и то, сколько из них используется. Что ж, в этом случае вам нужно использовать примерно 2 ^ 119 из 62 ^ 40 комбинаций, прежде чем шанс станет значительным.
erickson
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.