Нарушение правил веб-разработки

Question

Проверьте эта страница из " Нью - Йорк таймс ":

http://homedelivery.nytimes.com/HDS/learnMorePopUp.do ?mode=common.learnMorePopUp
&productId=NDS
&prodRate=7.40

Я был удивлен, увидев, что когда я вручную изменил prodRate параметр, страница обновлена:

• Вступительный тариф подписки.
• Обычная стоимость подписки.

Попробуйте это сами!Сейчас я не так уж много занимался веб-разработкой, но я знаю, что этого, вероятно, не должно было произойти.Так что мне интересно:

• Какая реализация могла бы вызвать такое поведение?
• Как бы вы изменили страницу, чтобы скрыть такие конфиденциальные параметры от конечного пользователя?

Answer 1

Возможно, вы захотите перефразировать свой вопрос, поскольку единственные ответы, которые я могу представить, не слишком понятны:

Q:Какая реализация могла бы вызвать такое поведение?
A:Тот, в котором разрешен пользовательский ввод для управления внутренним, доверенным поведением.Если вы спрашиваете "зачем кому-то это делать", я обычно рассматриваю это как недоразумение.Автор кода обычно не осознает, что пользователь может (а) контролировать значение и / или (б) даже обнаружить его существование.Чаще всего я видел, как это реализовано как перенаправление - вы нажимаете кнопку, сервер определяет сумму, затем перенаправляет браузер на новую страницу, которая сохраняет значение

Q:Как бы вы изменили страницу, чтобы скрыть такие конфиденциальные параметры от конечного пользователя?
A:Не храните значение таким образом, чтобы оно было доступно для редактирования конечным пользователем.Если у вас есть хранилище, доступное на сервере (например, в движке сервлетов), сохраните его в контексте сеанса.Если у вас нет хорошего механизма сеанса, вы могли бы сохранить его в подписанном файле cookie или файле HMAC'd.

Answer 2

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

Answer 3

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

Что касается других вариантов, они могли бы рассмотреть возможность либо размещения информации, либо помещения ее в файл cookie.Ни то, ни другое не является абсолютно надежным.Вы не можете открыть новое окно с сообщением, и пользователь может отключить cookies.

Answer 4

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

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

Answer 5

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