Какой ущерб можно нанести с помощью логина и ключа транзакции API платежного шлюза?

Question

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

Я хотел бы знать обо всех сценариях «что если», относящихся к типу ущерба, который можно нанести с помощью этой информации. Очевидно, он может обрабатывать кредитные карты, но деньги поступают на банковский счет владельца сайта, поэтому я не уверен, какой ущерб это может причинить. Кто-нибудь может подумать о каких-либо других возможных сценариях?

ОБНОВЛЕНИЕ: используется платежный шлюз Authorize.net.

Answer 1

Им действительно нужен доступ к вашим производственным площадкам?

Не храните ключ в своем коде, не храните его в производственной базе данных или в файле на рабочем сервере.

Answer 2

Некоторые хорошие ответы здесь, я просто добавлю, что у вас, вероятно, будут некоторые проблемы с PCI.
PCI-DSS, в частности, диктует разделение обязанностей, изоляцию производственных сред от dev / test, защиту ключей шифрования от всех, кому это не требуется, и многое другое. Как сказал @Matthew Watson, переосмыслите это и не предоставляйте доступ к продуктам разработчикам.

Кроме того, если он может напрямую обращаться к API, как вы гарантируете, что "деньги поступят на банковский счет владельца сайта"? Не говоря уже о доступе ко всем данным кредитной карты ...

Answer 3

Возмещается ли процесс сайта? Будет ли это когда-нибудь в будущем?

Если речь идет о гнусном использовании, то владелец сайта может быть расследован, если будет совершено много несанкционированных покупок. Как это повлияет на вас , если его владелец будет расследован?

Answer 4

Позволяет ли платежный шлюз отменить сборы? Если это так, существует вероятность запуска нескольких мошенников.

Answer 5

С любым шлюзом, с которым я работал, обработчик платежей связывает ключ API с конкретным диапазоном IP-адресов или IP-адреса сайта продавца. При этом, если только вредоносный (?) Код, о котором идет речь, не выполняется на том же сервере, что и продавец, в этом отношении не должно быть проблем безопасности.

Если это не относится к вашему торговому сайту - свяжитесь с ними и спросите, возможно ли это.

Answer 6

Если разработчик получает доступ к необработанным номерам кредитных карт, которые могут стать более серьезной проблемой, поскольку ваш сайт может быть связан с мошеннической деятельностью, предполагая, что разработчик - плохое яблоко. (Они могут перенаправить номера счетов, CCV, дату истечения срока действия на другой сайт, хотя это должно быть обнаружено с помощью сетевых инструментов и всестороннего анализа кода.)

Выполняет ли API «1,00» (или «X.XX»), чтобы убедиться, что с кредитной карты можно списать определенную сумму (и, таким образом, вернуть результат вызывающей стороне, такой как «да» или « нет ")? Если это так, его можно использовать для автоматизации проверки номеров счетов кредитных карт, торгуемых в Интернете, и злоупотребление такой системой может привести к вам.

Answer 7

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

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

Answer 8

Прежде всего, лучше никогда не хранить информацию такого типа в виде простого текста. Обычно люди воспринимают это как информацию из вторых рук для номеров кредитных карт (к сожалению, только по юридическим причинам), но любые личные данные, которые не нужны другим пользователям с доступом к базе данных / исходному коду, должны быть зашифрованы. Вы должны хранить информацию об учетной записи где-нибудь в хорошо зашифрованном формате, и вы должны предоставить тестовую учетную запись для своих разработчиков для использования на своих рабочих станциях. Таким образом, только люди, имеющие доступ к серверу, могут видеть даже зашифрованную информацию.

Таким образом, вы можете иметь базу данных на рабочей станции разработчика с информацией API тестовой учетной записи, хранящейся (вероятно, зашифрованной) в своей локальной базе данных, но когда код зеркально отображается на рабочем сервере, он все равно будет использовать реальный, настоящий шлюз информация хранится в базе данных производственного сервера без дополнительного кода / конфигурации.

С учетом сказанного, я не думаю, что программист с деталями аутентификации API может сделать слишком много. В любом случае, риск не стоит, по моему мнению.

Надеюсь, эта помощь.

PS: Если что-то плохое действительно случается, вы всегда можете сгенерировать новый ключ в веб-интерфейсе на authorize.net после того, как вы приняли меры предосторожности, чтобы убедиться, что это не повторится.

Answer 9

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

Однако главное в том, что если вы работаете над конфиденциальным проектом / информацией, вам лучше найти людей, которым вы могли бы доверять. Наем программного обеспечения дома, чтобы сделать работу, может сэкономить вам сон в дальнейшем.