Помощь со структурой URL для принятия / отклонения ссылок

Question

Я нахожусь в процессе создания приложения, в котором клиент может добавить адреса электронной почты к событию.Это означает, что каждый адрес электронной почты отправляется 2 URL-адреса по электронной почте при добавлении в список, 1 URL-адрес, чтобы принять, а другой отклонить.URL состоит из нескольких параметров запросов, идентификаторов и т. Д.

Проблема, с которой я столкнулся, заключается в том, что я хочу предотвратить сценарий, в котором кто-то может «угадать» URL других лиц - в качестве такой гостевой комбинациипараметры и т. д. Хотя это очень маловероятно, я все еще хочу предотвратить такое.

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

Кроме того, я кодирую на C #, но я не верю, что решение этой проблемы зависит от языка.

Заранее спасибо.

Answer 1

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

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

В конце концов, вы отправляете на сервер только хешированный ключ. Поэтому, когда вы отправляете эти две ссылки, они могут выглядеть следующим образом:

http://www.url.com/newsletter/acceptsubscription.aspx?id=x1r15ff2svosdf4r2s0f1
http://www.url.com/newsletter/cancelsubscription.aspx?id=x1r15ff2svosdf4r2s0f1

Когда пользователь нажимает на такую ​​ссылку, ваш сервер ищет в базе данных запись, которая содержит предоставленный ключ. Легко реализовать и действительно безопасно, если все сделано правильно. Ни в коем случае в аду никто не может угадать ключ от другого человека. Просто помните стандартные вещи, когда делаете что-то с хешированием. Такие как:

• Не забудьте добавить соль.
• Выберите очень медленный и действительно безопасный алгоритм хеширования.
• Просто убедитесь, что никто не может выяснить свой собственный хэш, исходя из информации, которой он может обладать.
• Если вы действительно боитесь, что люди будут совершать плохие поступки, обязательно прекратите брутфорс, добавив на сайт контроль газа. Например, разрешить только X запросов в минуту. Или какая-то форма запрета на IP-адрес.

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

edit : Я должен добавить; Решение, предоставленное Тимом С., тоже хорошо. GUID действительно очень полезны для подобных ситуаций и работают так же, как мое хешированное решение выше.

Answer 2

Я согласен, что это не зависит от языка.У меня была очень похожая ситуация в течение последних нескольких лет.Это должно было быть чрезвычайно безопасно из-за детей и родителей, получающих сообщения.Самым быстрым решением было что-то вроде следующего:

1. Сначала сохраните информацию, которую вы будете использовать в URL-адресе, в качестве параметров где-нибудь в базе данных.Это должно быть относительно быстро и просто.
2. Создайте два GUID.
3. Свяжите первый GUID с данными в базе данных, которые вы использовали бы для обработки «принятия».
4. Свяжите второй GUID для записи «отклонения» в базе данных.
5. Создайте два URL-адреса только с GUID-параметрами в качестве параметров.
6. Если выбран URL-адрес принятия, используйте данные базы данных.связан с ним для обработки принятия.
7. Если щелкнуть по Отклонить, удалить данные из базы данных, или заархивировать их, или что-либо еще.
8. По истечении таймфрейма не нажимается URL-адресудалите или заархивируйте данные, связанные с этими GUID, чтобы они больше не могли быть использованы.

GUID чрезвычайно трудно угадать, и вероятность угадать тот, который действительно пригоден для использования, была бы настолько маловероятной, чтопочти невозможно.