#security #email #email-spam #unsubscribe
#Безопасность #Адрес электронной почты #электронная почта-спам #отказаться от подписки
Вопрос:
Назовите мне несколько причин, по которым не следует указывать адреса электронной почты в текстовой форме для ссылки для отказа от подписки, которая рассылается в наших новостных рассылках.
Прямо сейчас это:
xyz.net/unsubscrible?uid=123amp;email=user@domamin.com
Я настаиваю на:
xyz.net/unsubscrible?uid=123amp;key=(encrpted_email_md5hash).
Мне не очень нравится идея добавлять адреса электронной почты в виде обычного текста, но мне нужно убедить моего менеджера в возможных угрозах.
Обновление: Хотя во всех ответах предлагалось, как я должен его защитить, а не почему я должен его защищать, я нахожу ответ do-ob наиболее подходящим.
Комментарии:
1. Это URL
http
илиhttps
?2. Есть ли у вас где-нибудь таблица, сопоставляющая uid 123 с user@domain.com ?
3. его http и yes 123 соответствуют адресу электронной почты, хранящемуся в базе данных..
Ответ №1:
Потому что тогда вы можете отказаться от подписки на кого-то другого. В идеале вы хотите использовать только ключ:
xyz.net/unsubscrible?key=<some unique cryptographic hash>
Я не должен быть в состоянии угадать идентификаторы и электронные письма и вызвать какое-либо действие для кого-то другого.
Ответ №2:
По той же причине, по которой у банков нет ссылок, таких как
bank.com/applycredit?ssn=123456789amp;name=john smithamp;dob=19500101amp;married=trueamp;address=...
его можно легко перехватить и интерпретировать.
Комментарии:
1. Не совсем корректно. Электронные письма содержат адрес назначения в виде обычного текста: в первую очередь его можно подслушать, поэтому его наличие в URL-адресах можно рассматривать как простое дублирование
2. да … но мне нужно знать, почему не включать электронную почту … поскольку это не так важно, но жизненно важно, если что-то случится… нужно что-то знать 😉
3. В этом случае хакер не узнал бы содержимое, тогда как теперь они знают, что на
user@domain.com
был подписанxyz.net
в какой-то момент и отказывается от подписки. Информация — это золото. Заменитеuser@domain
наabcd@senate
иxyz.net
наwarezxxx.net
, и вы получите золото таблоидов.
Ответ №3:
Практически в каждой новостной рассылке, которую я получаю, есть отказ от ответственности внизу, что-то вроде:
Это электронное письмо было отправлено на YourName@Domain.com . Чтобы отказаться от подписки, нажмите на эту ссылку: xxxx
Я нахожу полезным явное указание моего собственного адреса электронной почты в рассылке новостей. Мне кажется, что добавление электронной почты в ссылке для отказа от подписки не имеет значения.
Предположим, вы не публикуете адрес электронной почты в самом тексте сообщения или в ссылке для отказа от подписки. Адрес электронной почты по-прежнему указан в заголовке сообщения электронной почты. В результате я действительно не вижу необходимости скрывать его в ссылке для отмены подписки.
Комментарии:
1. Верно, так говорит мой менеджер, но я не встречал ни одной ссылки для отмены подписки (в моих подписках), которая выводила бы электронную почту в виде обычного текста … меня действительно беспокоит, что моя компания делает это в виде обычного текста, и я просто подумал, что нам следует изменить … 🙂
Ответ №4:
Почему нет? Не включайте его, потому что это не нужно. Для чего используются эти данные? Предложите нам не включать в строку запроса ничего, что нам на самом деле не нужно.
Единственное, что на самом деле требуется, это уникальный идентификатор. Похоже, у вас уже есть уникальный идентификатор в строке запроса: uid
.
Потенциальная проблема: что мешает мне автоматически создавать URL-адреса для отмены подписки и набирать ?uid=
от 1 до 10 миллионов?
Предложение: создайте пользовательский идентификатор guid для каждого пользователя в вашей таблице. Используйте его в качестве токена для отказа от подписки. Это невозможно угадать или уязвимо для автоматических атак.
foo.com/unsubscribe?u=<guid>
Комментарии:
1. Я использовал uid в качестве ключа и другой безопасный хэш, который будет использоваться, чтобы убедиться, что то, о чем вы упомянули, не произойдет… идентификаторы guid потребуют их сохранения в базе данных… неплохая идея, но было бы здорово, если бы я мог избежать этого…
2. @xoail: преимущество guid в том, что он не требует обслуживания; установите значение по умолчанию в столбце (т. Е.
NewID()
в SQL Server) или, по общему признанию, измените ваше приложение при создании нового пользователя.3. да, это хороший момент… но вернемся к моему вопросу.. почему бы не использовать адреса электронной почты в виде обычного текста? каковы были бы недостатки безопасности…
4. Это самое простое применение принципа KISS. Очевидно, что это не нужно, это не служит никакой цели и излишне усложняет код. Даже не рассматривая последствия для безопасности, вам не нужно оправдываться, почему его следует удалить. Ваш начальник должен обосновать, почему его следует добавить.
Ответ №5:
Я предполагаю, что uid — это «идентификатор пользователя». Если вы знаете идентификатор пользователя, то вы должны быть в состоянии определить адрес электронной почты по этому праву? Похоже, что наличие электронной почты в URL-адресе ничего не делает. Я думаю, если вам не нужно указывать личную информацию, то лучше этого не делать.
Ответ №6:
Я согласен, что вам не нужен адрес электронной почты, если у вас есть другой метод уникальной идентификации пользователя. Единственной причиной может быть указание пользователю адреса электронной почты, на который он / она подписан, но он также устарел, поскольку он / она, очевидно, получает электронное письмо.
Ответ №7:
Я мог бы дать вам очень сложный ответ, но вы обнаружите, что иметь полный адрес электронной почты — не такая уж плохая идея.
Наличие URL, содержащего адрес электронной почты, может быть использовано вредоносными прокси (т. Е. из общественных мест) для хранения адресов и рассылки спама. Но если я предполагаю, что в общедоступном месте есть что-то вредоносное, лучше установите кейлоггер на общедоступный компьютер и сделайте еще больше плохого.
Другой момент может заключаться в следующем: если вы отправляете электронные письма ценным клиентам, злоумышленник может подделать адреса электронной почты и отказаться от подписки на них, фактически снижая эффективность вашего общения. Для этого вы можете добавить к своему URL контрольную сумму шифрования (не требуйте CAPTCHA, людям это не нравится при отказе от подписки), но затем, зашифровав (или просто закодировав неочевидным способом) весь почтовый адрес, вы могли бы решить проблему без использования двух параметров.
Ответ №8:
Поскольку вы не используете https
, параметры запроса могут отслеживаться. Это серьезная проблема для пользователей мобильных устройств и пользователей ноутбуков в местах с бесплатным Wi-Fi, таких как кофейни.
И поскольку uid уже сопоставляется с адресом электронной почты, вам не нужно предоставлять ищейкам идентифицирующую информацию, такую как адрес электронной почты.
Вам действительно нужно убедиться, что отмена подписки не произойдет, как только пользователь нажмет на ссылку. Это URL-адрес GET, который должен быть идемпотентным (см. Раздел 9.1), что означает, что у него не должно быть полномочий на изменение базовой базы данных.
И у меня не должно быть полномочий для отмены подписки, просто зная ваш адрес электронной почты, который я мог бы сделать, подделав URL, если uid либо угадывается, либо не требуется.