Когда можно намеренно запутывать URL-адреса?

Наличие дружественных URL-адресов, как правило, хорошо. Однако иногда это кажется плохой идеей. Каково ваше эмпирическое правило?

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

Вот несколько импровизированных примеров "взламываемых" (как описано в ссылке) URL:

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

Как бы вы справились с этим?


friendly-url
person Larsenal    schedule 04.12.2008    source источник
comment
Вау, я никогда этого не знал. Спасибо. Я уверен, что люди на www.mysite.com будут очень расстроены потерей всего фиктивного трафика, который я генерировал...   -  person Jonathan S.    schedule 05.12.2008
comment
похоже, вы либо пытаетесь решить несуществующую проблему безопасности, либо верите в безопасность через неизвестность... не уверен, что именно.   -  person    schedule 05.12.2008
comment
Вопрос не в безопасности... причина, по которой я не хочу, чтобы URL-адреса можно было легко обнаружить, заключается не в том, чтобы помешать пользователю сделать что-то плохое с приложением. Единственным отличием будет отображаемое сообщение.   -  person Larsenal    schedule 05.12.2008

Ответы (10)


arrow_upward
24
arrow_downward

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

Как правило, нет веских причин намеренно запутывать URL-адреса. Используйте URL-адреса для передачи операций чтения (путь к ресурсу). Используйте запросы POST для передачи операций записи (добавление/изменение данных). Если предполагается, что пользователь не может что-то сделать через URL-адрес, это должно регулироваться на стороне сервера и через метод запроса.

person Eran Galperin    schedule 04.12.2008
comment
Абсолютная правда. Но отображение немного другого сообщения (READ) в этом случае не является сценарием высокого риска. Однако было бы неплохо параметризовать страницу простым способом. - person Larsenal; 05.12.2008
comment
Этот ответ упускает суть. OP никогда не упоминал безопасность как причину, по которой он хотел запутать URL-адреса для своего приложения, и, по-видимому, ему удобно фильтровать входные данные. Обфускация может быть хорошим методом повышения удобства использования независимо от ее влияния на безопасность. - person Chris; 05.12.2008
comment
Он беспокоился о безопасности - его причины запутывания заключались в том, чтобы защитить свои URL-адреса от взлома. Он не должен был доверять этим данным в первую очередь, так что это не должно быть проблемой. - person Eran Galperin; 05.12.2008
comment
Мне не следовало использовать термин «взломанный», поскольку он неоднозначен. Люди говорят о создании взломанных URL-адресов, чтобы сказать, что вы можете и должны быть в состоянии выяснить, как изменить URL-адрес, чтобы получить то, что вы хотите. - person Larsenal; 05.12.2008
comment
Как правило, нет веских причин намеренно запутывать URL-адреса. Если предполагается, что пользователь не может что-то сделать через URL-адрес, это должно регулироваться на стороне сервера и через метод запроса. - person Eran Galperin; 05.12.2008
comment
Наверное, хорошее правило. Добавьте это к своему ответу, и я поставлю зеленую галочку. - person Larsenal; 05.12.2008

arrow_upward
4
arrow_downward

Вы можете либо отправить данные POST, либо, если это невозможно, установить значение в переменной сеанса, а затем прочитать значение на странице успеха. Фактическая сложность кода с использованием сеанса примерно такая же, как и с использованием строки запроса.

person Jeromy Irvine    schedule 04.12.2008

arrow_upward
2
arrow_downward

Хорошо, если вы не думаете, что это проблема безопасности, поскольку вы просто отображаете другое сообщение, то почему вас волнует, можно ли его взломать или нет?

Большинство пользователей не заметят, что URL можно редактировать, так зачем запутывать? «Элитные хакеры» получат немного другое сообщение, большое дело.

Общий ответ на вопрос «Должен ли я запутать ...?» нет. Если это из соображений безопасности, черт возьми, нет, иначе зачем вы запутываетесь? Скорее всего, вы теряете время.

person Pyrolistical    schedule 04.12.2008
comment
Вы должны помнить, что вы ненормальны. Большинство людей, использующих компьютеры, не разбираются в технике, как мы с вами, так что не беспокойтесь об этом. - person Pyrolistical; 05.12.2008

arrow_upward
1
arrow_downward

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

Я бы перенаправил их в RegistrationSuccess.aspx и представил там содержимое в зависимости от состояния сеанса.

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

Еще лучший выбор, возможно, состоит в том, чтобы перенаправить их на MyRegistration.aspx, который они, возможно, хотели бы сделать фаворитом. Исходя из процесса регистрации, в нем может быть поле, объясняющее, что они успешно зарегистрировались. Если они не приходят сюда из процесса регистрации, это поле не отображается. Остальная часть страницы представляет собой сводку всех предыдущих процессов регистрации для этого пользователя.

person Guge    schedule 04.12.2008

arrow_upward
0
arrow_downward

С отправкой поста?

Если вам не нужна информация в URL-адресе, не указывайте ее в URL-адресе.

Это не всегда легко сделать...

person Karl    schedule 04.12.2008

arrow_upward
0
arrow_downward

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

Для других страниц, которые пользователи будут посещать только несколько раз в месяц или год, вы можете оставить их как обычные URL-адреса.

person azamsharp    schedule 04.12.2008

arrow_upward
0
arrow_downward

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

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

person a_hardin    schedule 04.12.2008

arrow_upward
0
arrow_downward

Почему бы не сделать сообщение об успешной регистрации последним шагом, а не менять страницы?

Для этого можно использовать Ajax или Server.Transfer().

person David Vidmar    schedule 04.12.2008

arrow_upward
0
arrow_downward

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

(Очевидно, вы можете обойти это, если вы ботаник.)

person Larsenal    schedule 04.12.2008
comment
Имейте в виду, что заголовки реферера могут быть отключены из соображений безопасности или отфильтрованы. - person phihag; 05.12.2008
comment
Кроме того, заголовки реферера легко подделать: curl --referer white.listed.url/here атака.against.url/здесь - person jamuraa; 05.12.2008
comment
Да, их легко подделать, но сценарий здесь не критичен для безопасности. Мы говорим об отображении «Спасибо за регистрацию» по сравнению с «Спасибо за регистрацию для продукта XYZ». - person Larsenal; 05.12.2008

arrow_upward
-2
arrow_downward

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

person user933    schedule 04.12.2008
comment
Если вы не сделаете что-то еще, что мешает кому-то просто переоценить контрольную сумму? - person Allain Lalonde; 05.12.2008
comment
@Аллен Лалонд: Секретная соль. - person phihag; 05.12.2008
comment
Кто-нибудь может объяснить, что в этом плохого? Не похоже, чтобы ОП особенно заботился о том, видят ли люди свой собственный идентификатор или параметр в URL-адресе, он просто не хочет, чтобы люди дурачились, угадывая их. - person user933; 05.12.2008