![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Большинство веб-разработчиков знают Правило Правой Руки для HTTP: если запрос меняет состояние сервера, его надо отправлять методом POST, если не меняет — можно использовать GET.
Веб-форма при отправке на сервер меняла его состояние, поэтому разработчки совершенно справедливо указали method=”POST”.
Но если обработчик обнаружил ошибки, форму надо показать снова. И признак хорошего тона — не заставлять пользователя при этом вбивать всё заново, а подставить ранее введённые им значения и показать пальцем, в каких полях ошибки. Разработчики так и сделали. Но форму у них обрабатывает один скрипт, а показывает другой, поэтому при обнаружении ошибок возврат к странице с формой делается редиректом. А POST при этом, как известно, не работает, поэтому умные разработчики передают все введённые параметры GET’ом. Попросту говоря, прямо в URL’е.
Казалось бы, ничего страшного в этом нет, показ формы никаких изменений на сервере не вызывает, поэтому использование GET в этом случае вполне допустимо.
Казалось бы… если бы не одна мелочь: в форме передаются данные про кредитные карты. Номер, CVV, срок действия, держатель… Весь набор в одном флаконе. И, естественно, при последующей отправке формы весь этот набор оседает в логах веб-сервера в виде реферера. Хуже того, особо умные пользователи могут сохранить всю эту ссылку в закладках браузера. Чтоб не набивать потом данные лишний раз.
В общем, ситуация типа “да вы здесь все молодцы…” ©.
P.S. Если кто случайно не знает прописных истин: надо либо использовать для показа формы и её обработки один и тот же скрипт (тогда редирект не понадобится), либо, если уж по каким-то причинам скриптов два, хранить параметры в сессии на сервере, а клиенту передавать только её идентификатор, да и тот лучше не в URL’е, а в куке.
Оригинал этой записи. Комментировать можно тут или там.
no subject
no subject
скажи, что ты шутишь.
no subject
Увы, шутки в этом меньше, чем хотелось бы.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
На чеке либо 1234 XXXX XXXX 5678 либо ....5678.
no subject
Одна очень крупная компания принимала оплату следующим образом - процессинговый центр кроме всего прочего мог отвечать на мыло, прошла оплата или нет. Разработчики сайта создали ящик на mail.ru (вот те плюс!), сказали процессингу сваливать туда ответ, а потом скриптом выгребали. Соответственно, пользователь об этом ничего не знал.
Причём и компания, и разработчик сайта - довольно крупные и известные у нас в городе, обычно таким доверяют.
no subject
Будучи в Петербурге нашёл билет в .... эээээ, чорт, забыл куда, в какую-то достопримечательность, к нему был приколот нестандартного размера чек, на котором было написано всё, кроме Expire date и CVV. Показал друзьям, они порадовались.
no subject
no subject
Я, правда, не в курсе, как за это взъ....ть.
no subject
no subject
no subject
no subject
я, честно говоря, не помню чтобы в банкоматных чеках был полный номер у кого, там вроде есть жесткие требования, с посовскими терминалами кажись такого требования нет, ибо тоже пытались пинать то ли на тему перекрестка, то ли на тему живого еще тогда меркадо, что у них на чеках был полный номер карты — банк-экварер послал, виза тоже отписалась … хотя может и пнули их, ибо сейчас полного номера на чеках перекрестка вроде нет …
no subject
no subject
no subject
no subject
Лет цать назад нужно было поправить dns-записи у хостера. Никто у меня не спросил никаких документов, просто "я такой-то из компании такой-то, нам надо mx поправить".
no subject
При чём тут GET и POST проблема же не в этом
Во первых, сервер и так знает все эти данные, ибо именно ему передаются реквизиты карточки. Никаким проксям это не доступно, ведь используется HTTPS, верно?
Во вторых, печатание этих реквизитов в логах это logging issue. Что мешает сервер залогировать параметры переданные POST-ом? Если бы я был разработчиком и мне надо было выдать параметры запроса, мне было бы наплевать как они переданы GET-ом или POST-ом. В сервлетах, к примеру, они вообще не различаются.
Насчёт закладок - могут быть проблемы, конечно, но надо смотреть код.
no subject
Залоггировать параметры POST'а можно, конечно, но для этого надо совершать нетривиальные телодвижения. Параметры GET'а пишутся в лог по умолчанию.
Ну и на досуге попробуйте запомнить в закладках браузера ссылочку на форму, отправляемую на сервер POST'ом, _вместе со всеми параметрами этой формы_. Когда получится - возвращайтесь, поговорим дальше.
no subject
Чего стоит эта фраза "И, естественно, при последующей отправке формы весь этот набор оседает в логах веб-сервера в виде реферера". Для кого естественно? Почему естественно? Какого веб сервера? На моих серверах никакие урлы в логах не оседают.
При чём тут подход к безопасности? Пост был про GET vs POST. С точки зрения безопасности они не различаются.
Не понимаю к чему был вопрос про закладки. Я пару раз действительно делал закладку с GET-параметрами которые должны были передаваться постом, чисто для удобства. И что?
Да, есть особенности, но никак не связанные с "дырявостью" GET-а.
no subject
Если вы действительно до сих пор не понимаете, чем различаются GET и POST с точки зрения безопасности, флаг вам в руки, продолжайте передавать параметры GET'ом. И не жалуйтесь потом, когда к вам, по примеру Мегафона, придёт Яндекс или Гугл.
А насчёт закладок - как, например, сохранить в браузере ссылку на https://passport.yandex.ru/passport?mode=passport с именем _username_ и паролем _pass_?