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

Question

Проверьте this page из Нью-Йорк Таймс:

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

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

• Начальная ставка подписки.
• Обычная подписная ставка.

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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