Такие решения тоже бывают. Я вообще считаю что все взаимодействие должно происходить сервер-сервер, а пользователю должен выдаваться URL для перенаправления. Но существуют разные решения, и решение с формой и HMAC весьма популярно и много где встречается.
В теории — ОК. Но только я не понимаю, чем это решение более уязвимо, чем предложенные вами выше решение с "(а) просто идентификатором (б) идентификатором и паролем (ц) идентификатором и хэшом от пароля + nonce"
Многие их тех, кого вы назвали «криворукими у**анами» имеют хороший бэкграунд C/С++ и выбрали PHP когда только появилась четверка, и перешли на него в свою очередь с Perl. Расскажите этим людям с десятками лет стажа, какие они криворукие и как им надо перейти на новые непонятно чем «выдающиеся» технологии. Хоть убейте, меня вымораживает синтаксис руби, как и вообще синтаксис без фигурных скобок — как минимум хреново читаемый код.
Не могу говорить за всех, но HMAC тем не менее используется почти во всех API банков и платежных систем, которые мне доводилось встречать, а подключал я их очень много. Лишь у одного была проверка клиентского сертификата. И хоть убейте, я не считаю это решение практически уязвимым, брут хеша — это очень теоретическая уязвимость. На практике, после 10 неудачных попыток, любая нормальная система Ваш ip заблокирует, а инцидентом будет заниматься служба ИБ.
Обработка лимитов и алерты — это отдельная подсистема, не имеющая отношения к криптографии.
Правильно построенная система — да, заблокирует, если еще раньше не заблокирует WAF, не ограничит nginx по rate limit и т.п.
Чтобы подобрать HMAC sha256 при помощи Timing attack придется отправить огромное количество запросов. Любая нормальная система заблокирует вас намного раньше чем вы успеете первые два символа подобрать :) Но это уже выходит за рамки текущего материала.
(а) кто является атакующим — пользователь или третья сторона? Если третья сторона, то каким образом она меняет данные?
(б) зачем эта форма вообще показывается пользователю?
мне кажется, что я уже не раз ответил на все эти вопросы и мы идем на очередной круг.
По пункту номер 1:
а) сбрутили идентификатор — начали гнать запросы.
б и ц) будет работать, и будет достаточно секурно, если это сервер->сервер API взаимодействие.
По пункту номер 2:
Сценарий атаки:
Есть интернет-магазин «Ромашка» и банк «Рога и Копыта», который оказывает услуги интернет-эквайринга для Ромашки. На странице чекаута на сайте Ромашки есть форма с hidden-полями: merchant_id, order_id, amount, description. Форма сабмитится на URL банка. Лжепокупатель может изменить order_id или amount и оплатить совсем другой счет и более того — на другую сумму.
Способ защиты:
Передавать еще и HMAC, проверка которого на стороне сервера не даст пользователю изменить данные в форме.
Если клиент — это доверенная серверная часть и идентификатор такой, что его нельзя подобрать или угадать — то теоретически можно сделать так, как вы говорите. А если клиент — это форма в браузере пользователя, который может быть зловредным и изменит, скажем, сумму покупки, или идентификатор заказа, или еще какие-то данные, то без HMAC не обойтись и один лишь идентификатор передавать недостаточно.
Есть сервер платежной системы, он принимает запросы на транзакции от клиентов, которых много. Передавая просто идентификтор — мы не можем клиента аутентифицировать. Это первый случай.
Второй случай — часто платежная форма инициализируется в виде GET или POST запроса, который происходит на стороне клиента (сабмитится форма в браузере) и в этом случае сервер получающей стороны должен быть уверен что данные сформированы легитимным клиентом и не были изменены. Так понятнее?
Защита логики в формах — раз.
Аутентификация и защита от изменения пользователем запросов в API, в частности, в платежных формах и платежных API — два.
Это Ваше сугубо субъективное мнение.
Печальный для кого, для рубистов?
Правильно построенная система — да, заблокирует, если еще раньше не заблокирует WAF, не ограничит nginx по rate limit и т.п.
мне кажется, что я уже не раз ответил на все эти вопросы и мы идем на очередной круг.
По пункту номер 1:
а) сбрутили идентификатор — начали гнать запросы.
б и ц) будет работать, и будет достаточно секурно, если это сервер->сервер API взаимодействие.
По пункту номер 2:
Сценарий атаки:
Есть интернет-магазин «Ромашка» и банк «Рога и Копыта», который оказывает услуги интернет-эквайринга для Ромашки. На странице чекаута на сайте Ромашки есть форма с hidden-полями: merchant_id, order_id, amount, description. Форма сабмитится на URL банка. Лжепокупатель может изменить order_id или amount и оплатить совсем другой счет и более того — на другую сумму.
Способ защиты:
Передавать еще и HMAC, проверка которого на стороне сервера не даст пользователю изменить данные в форме.
Второй случай — часто платежная форма инициализируется в виде GET или POST запроса, который происходит на стороне клиента (сабмитится форма в браузере) и в этом случае сервер получающей стороны должен быть уверен что данные сформированы легитимным клиентом и не были изменены. Так понятнее?
Аутентификация и защита от изменения пользователем запросов в API, в частности, в платежных формах и платежных API — два.