WikiDer > Кассир как услуга

Cashier as a service

Кассир как услуга (CaaS) относится к использованию сторонних сервисов в качестве оплаты. Когда покупатель покупает товар в Интернете, он часто платит не продавцу напрямую, а через третью сторону - кассира. Кассиру доверяют как покупатель, так и продавец, и ожидается, что он обеспечит надежный и безопасный перевод денег. Платя продавцу через кассира, покупатели могут оплачивать товары, не сообщая продавцам свою финансовую информацию.

Покупки онлайн

При использовании CaaS при совершении покупок в Интернете участвуют три стороны: покупатель, продавец и CaaS.

Покупатель - это пользователь, который добавляет товары в корзину и платит за них продавцу.

Продавец продает товары с веб-сайта. Чтобы продавать товары, продавец должен предоставить покупателям возможность добавлять товары в корзину, предоставить покупателю возможность платить продавцу и отслеживать информацию о покупателе. Популярное торговое программное обеспечение с открытым исходным кодом включает nopCommerce и Interspire, которые обеспечивают эту функциональность и интеграцию нескольких различных CaaS.

CaaS предоставляет покупателю способ заплатить продавцу. Примеры популярных CaaS включают: PayPal, Платежи Amazon, Google Кошелек, и Venmo.[1][2]

Безопасность

Интеграция CaaS на веб-сайт продавца создает проблемы с обеспечением платежа от покупателя продавцу. С тремя сторонами вместо двух обеспечение транзакции становится значительно более сложным, особенно когда есть злонамеренный покупатель. CaaS и продавец теперь должны синхронизироваться друг с другом, чтобы иметь единообразное представление о транзакциях. Более того, покупатель может попытаться выдать себя за продавца или CaaS, чтобы обманом заставить другие стороны изменить свое состояние или передать покупателю подписанные сообщения.[3][4]

Цель безопасности - инварианты

Для успешной транзакции от покупателя S, покупающего и предмета I от продавца M, должны выполняться следующие инварианты.[5][6]

  1. M владеет I
  2. Платеж гарантированно будет переведен со счета S на счет M в системе CaaS.
  3. Оплата предназначена для покупки I и действительна только для одной I
  4. Сумма этого платежа равна цене I

Общий поток транзакций

Когда покупатель покупает товар у продавца, он вызывает общедоступные API-интерфейсы (обозначенные черными ромбами) продавца и CaaS с HTTP-запросами. Продавец и CaaS могут также вызывать API друг друга, чтобы передавать друг другу информацию. Ниже приводится подробное описание общего потока:[6][7]

RT1.a) Покупатель проверяет товары в своей корзине.

RT1.a.a) Продавец уведомляет CaaS о том, что покупатель будет платить.

RT1.a.b) CaaS признает продавца.

RT1.b) Продавец перенаправляет покупателя в CaaS, возможно, предоставляя покупателю информацию для идентификации заказа и общую информацию.

RT2.a) Покупатель предоставляет информацию, предоставленную продавцом, в CaaS.

RT2.a.a) CaaS уведомляет продавца о том, что покупатель заплатил.

RT2.a.b) Продавец признает CaaS.

RT2.b) CaaS перенаправляет покупателя к продавцу, возможно, предоставляя покупателю информацию, которую нужно передать обратно продавцу.

RT3.a) Покупатель предоставляет продавцу информацию, предоставленную CaaS.

RT3.b) После того, как продавец обновляет базу данных, он отправляет покупателю ответ с подтверждением, и транзакция завершается.

RT4.a / b) Представляет покупателя, маскирующегося под CaaS. Покупатель вызывает API продавца, который должен вызывать только CaaS.

RT5.a / b) представляет покупателя, маскирующегося под продавца. Покупатель создает торговый магазин и получает вызовы API от CaaS.

Инструменты, доступные для бреши в безопасности

Заголовки HTTP и Скрипачи два популярных инструмента отладки доступны для использования в реальных магазинах.[8][9]

Недостатки безопасности - примеры

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

Будем использоваться следующие обозначения:

  • A - покупатель / злоумышленник.
  • Т - торговец
  • C - это CaaS
  • * означает, что сообщение подписано

Интеграция nopCommerce со стандартом PayPal

В nopCommerceинтеграция PayPal По стандарту покупатель размещает заказ и перенаправляется в PayPal, учитывая идентификатор заказа и брутто от продавца. Однако эти аргументы не подписаны продавцом, поэтому покупатель может изменить эту информацию, прежде чем передать ее PayPal. Если изменить общую сумму на 0, CaaS ожидает, что покупатель заплатит эту сумму. Когда покупатель перенаправляется обратно к продавцу, продавец связывается с PayPal относительно статуса платежа для этого конкретного заказа, и PayPal ответит, что покупатель заплатил за товар. Затем продавец обновляет статус заказа на «оплачен», не сравнивая общую информацию, которую PayPal вернул, с ценой товара. Таким образом, покупатель успешно купил товар у продавца бесплатно.[6]

Интеграция nopCommerce с Amazon Simple Pay

При интеграции Amazon Simple Pay в nopCommerce покупатель разместит заказ и будет перенаправлен на Amazon. Аргументы, предоставленные продавцом, подписываются, как указано *, что предотвращает вмешательство покупателя в аргументы. Покупатель передаст эти аргументы Amazon, произведет оплату и будет перенаправлен на указанный returnURL. Продавец, который "status = PAID" завершит транзакцию. В этом случае покупатель может создать отдельную учетную запись продавца, которая может подписать сообщение, которое Amazon примет. Таким образом, когда покупатель размещает заказ в магазине продавца, покупатель не передает Amazon сообщение, предоставленное продавцом, а вместо этого создает собственное сообщение и подписывает его со своей учетной записью продавца. Аргументы в этом сообщении будут такими же, как и в сообщении продавца, но, поскольку сообщение подписано торговым аккаунтом покупателя, покупатель будет платить сам. Однако покупатель будет перенаправлен на веб-сайт продавца из-за returnURL, и продавец обновит свою базу данных о том, что заказ был оплачен, поскольку он получил подписанное сообщение от Amazon со значением «status = PAID». Покупатель успешно купил товар у продавца, заплатив себе.[6]

Интеграция Interspire со стандартом PayPal

При интеграции Interspire со стандартом PayPal покупатель размещает заказ и перенаправляется в PayPal, учитывая идентификатор заказа, брутто, merchantID и IPNHandler. IPNHandler указывает URL-адрес продавца, который PayPal будет использовать для связи с продавцом. Покупатель отправляет эти аргументы в PayPal и платит. PayPal уведомит продавца о платеже с помощью данного IPNHandler и перенаправит покупателя обратно продавцу. После этого покупатель получит обновление статуса от продавца.

Эксплойт в этом случае предполагает, что покупатель действует как все три стороны (покупатель, продавец и CaaS). Сначала покупатель создает собственную учетную запись продавца и меняет идентификатор заказа на пустой, а IPNHandler указывает на URL своего продавца. Затем PayPal отправит подписанное сообщение указанному IPNHandler, которое покупатель сохранит. Теперь покупатель может отправить это сообщение продавцу, чтобы сообщить продавцу, что он оплатил конкретный заказ. Когда продавец получает сообщение с пустым идентификатором заказа, он получает идентификатор заказа из файлов cookie, который покупатель может легко изменить. С сохраненным сообщением от PayPal покупатель теперь может бесплатно купить произвольное количество товаров по той же цене у продавца, изменив файлы cookie и воспроизведя сообщение от PayPal продавцу.[6]

Анонимность злоумышленника

Злоумышленникам может потребоваться создать свои собственные торговые счета для некоторых атак. Сюда часто входит необходимость предоставить информацию о кредитной карте. Злоумышленник может использовать подарочные карты, которые действуют как кредитные карты, но не содержат никакой личной информации. Более того, злоумышленники могут скрыть свой реальный IP-адрес, используя подделку IP-адреса или другие технологии, чтобы его IP-адрес не отслеживался.

Рекомендации

  1. ^ «Шуо Чен из Microsoft Research». Microsoft Research. Получено 26 августа 2017.
  2. ^ «Как делать покупки бесплатно в Интернете». Канал 9. Получено 26 августа 2017.
  3. ^ «Общие уязвимости системы безопасности в системах электронной коммерции - Symantec Connect». Symantec.com. Получено 26 августа 2017.
  4. ^ В. Фельметсгер, Л. Каведон, К. Крюгель и Г. Винья, «На пути к автоматическому обнаружению логических уязвимостей в веб-приложениях», в материалах симпозиума по безопасности USENIX, Вашингтон, округ Колумбия, август 2010 г.
  5. ^ «Шуо Чен из Microsoft Research». Microsoft Research. Получено 26 августа 2017.
  6. ^ а б c d е Ван, Руи; Чен, Шуо; Ван, Сяофэн; Кадир, Шаз (1 мая 2011 г.). «Как делать бесплатные покупки в Интернете - Анализ безопасности интернет-магазинов, основанных на принципах« касса как услуга »» (PDF). Microsoft Research. Получено 26 августа 2017.
  7. ^ «Шуо Чен из Microsoft Research». Microsoft Research. Получено 26 августа 2017.
  8. ^ Руи, Ван (1 февраля 2016 г.). Как делать покупки для бесплатного анализа онлайн-безопасности интернет-магазинов, основанных на принципах кассы как услуги (PDF). Университет Индианы, Блумингтон, Блумингтон, Индиана, США; Microsoft Research, Редмонд, Вашингтон, США. п. 10. Получено 1 сентября 2017.
  9. ^ Штрол, Исаак (22 февраля 2012 г.). Совершайте покупки бесплатно в Интернете - Анализ безопасности интернет-магазинов, основанных на принципах кассы как услуги - lec11 (PDF). Департамент компьютерных наук: Техасский университет в Далласе, США. п. 31 год. Получено 1 сентября 2017.