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

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

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

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

9 ответов

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

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


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

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


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

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


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

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


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


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

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


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

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

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

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

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


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

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


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

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

licensed under cc by-sa 3.0 with attribution.