Есть ли недостатки в формах оплаты кредитной картой через iframe? [закрытый]
Общая особенность, которую я вижу на многих сайтах электронной коммерции малого бизнеса, заключается в том, что когда я нажимаю на кнопку "Оформить заказ", меня забирают с сайта и перенаправляют на url-адрес платежного шлюза третьей стороны, такого как paypal, authorize.net и т.д... После того, как я совершу платеж на этом стороннем сайте, я буду перенаправлен обратно на сайт электронной коммерции малого бизнеса.
Я хотел бы упростить этот процесс для нескольких моих клиентов. Я планирую сделать платежную форму, которую другие могут встроить в свои сайт через iframe. Платежная форма будет находиться за SSL. Когда моя платежная форма получит информацию, я передам ее торговому шлюзу, такому как paypal, и перезагрузлю iframe с ответом success/fail.
Есть ли какие-либо серьезные проблемы в этом подходе iframe? Я спрашиваю, потому что не помню, чтобы платежные шлюзы, такие как paypal, предлагали коды вставки iframe для своих платежных страниц, хотя это кажется тривиальным. Если они могут предложить URL-адрес для оформления заказа владельцам веб-сайтов, чтобы встраиваясь в свою страницу, они должны так же легко предлагать код вставки iframe.
2 ответа:
Фундаментальным аспектом безопасности HTTPS-соединения является проверка подлинности удаленной стороны. Одно дело-тайно обмениваться данными с кем-то, но нужно знать, с кем именно.
С технической точки зрения идентичность сервера проверяется с помощью его сертификата:
Однако технический аспект является лишь частью решения. Пользователь должен иметь возможность видеть, к какому сайту браузер пытается подключиться. Это проблема пользовательского интерфейса, и только пользователь может проверить, что браузер пытается сделать, в пределах того, что его пользовательский интерфейс отображает (нереалистично ожидать, что большинство пользователей будут использовать инструменты разработчика).
- , он должен быть надежным, т. е. клиент может проверяться он был выдан органом, которым он доверяет (РЧЦ 3280/5280).
- он должен быть выдан субъекту-клиенту. хочет поговорить, то есть имя хоста должно быть проверено (RFC 2818, раздел 3.1).
Использование iframe скрывает имя сайта к которому пользователь фактически подключен для этого iframe (в адресной строке отображается только адрес главной страницы). Это предотвращает выполнение пользователем этой проверки.
Кроме того, было бы еще хуже, если бы iframe HTTPS находился внутри страницы HTTP, и в этом случае пользователь даже не мог бы проверить, используется ли HTTPS вообще.
Есть плохой пример встроенных iframe, в частности 3-D Secure , потому что (а) он рекомендует использовать iframe и (б) даже если iframe название обычно не имеет ничего общего с банком пользователя, торговым сайтом или компанией, выпускающей кредитные карты.
Одна потенциальная проблема (с которой я действительно столкнулся, как пользователь) заключается в том, что хостинговая страница, вероятно, не будет использовать SSL и будет иметь маленькие "подсказки", которые люди должны искать в статьях о том, чтобы быть опытным интернет-покупателем. Это может привести к потере продаж в последнюю минуту из-за осторожности пользователей.
Существуют также потенциальные проблемы с междоменными сценариями. Это огромная тема, и делать это даже тогда, когда Вы Хотите , чтобы это было возможно, может быть очень и очень сложно, но не невозможно, так что есть некоторый потенциал для злоупотреблений.