Какого рода ущерб можно было бы сделать с помощью логина входа и транзакции API-шлюза платежного шлюза?

Question

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

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

UPDATE: Используется платежный шлюз Authorize.net.

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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