Quel type de dommage peut-on faire avec un identifiant et une clé de transaction API de passerelle de paiement?

StackOverflow https://stackoverflow.com/questions/166639

Question

Actuellement, je suis en train de recruter un développeur Web qui travaillera sur un site traitant des cartes de crédit. Bien qu'il n'ait pas les informations d'identification pour se connecter à l'interface utilisateur de la passerelle de paiement, il aura accès au nom de connexion de l'API et à la clé de transaction car elle est intégrée au code de l'application.

J'aimerais connaître tous les "et si" " scénarios relatifs au type de dommage que l’on pourrait faire avec cette information. De toute évidence, il peut traiter les cartes de crédit, mais l'argent va dans le compte bancaire du propriétaire du site, donc je ne suis pas sûr de l'ampleur des dommages qui pourraient en résulter. Quelqu'un peut-il penser à d'autres scénarios possibles?

UPDATE: la passerelle de paiement utilisée est Authorize.net.

Était-ce utile?

La solution

Ont-ils vraiment besoin d'accéder à vos sites de production?

Ne stockez pas la clé dans votre code, ni dans votre base de données de production, ni dans un fichier du serveur de production.

Autres conseils

Quelques bonnes réponses ici, je vais juste ajouter que vous auriez probablement des problèmes avec le PCI.
La norme PCI-DSS dicte spécifiquement la séparation des tâches, l'isolation des environnements de production de la conception / du test, la protection des clés de cryptage de toute personne qui n'en a pas besoin, et plus encore. Comme @Matthew Watson l'a dit, repensez cela et n'accordez pas l'accès de la production aux développeurs.

Par ailleurs, s’il peut accéder directement à l’API, comment vous assurez-vous que "l’argent est versé sur le compte bancaire du propriétaire du site"? Sans parler de l'accès à toutes ces données de carte de crédit ...

Si le développeur a accès aux numéros de carte de crédit bruts, cela peut devenir un problème plus grave car votre site peut être associé à une activité frauduleuse, en supposant que le développeur soit une mauvaise pomme. (Ils pourraient rediriger leurs numéros de compte, leur numéro de CV, leur date d'expiration vers un autre site, même si cela devrait être possible via des outils réseau et une révision complète du code.)

L’API exécute-t-elle le code " $ 1,00 " facturer (ou "X.XX $") pour vérifier qu'une carte de crédit peut être débitée d'un certain montant (et ainsi renvoyer le résultat à l'appelant, tel que "oui" ou "non")? Si tel est le cas, il pourrait être utilisé pour automatiser la validation des numéros de compte de carte de crédit échangés sur Internet, et tout abus d’un tel système pourrait vous revenir.

Quelle que soit la passerelle avec laquelle j'ai travaillé, le processeur de paiement lie la clé API à l'adresse IP ou à la plage d'adresses IP spécifique du site du marchand. Cela dit, à moins que le code malveillant (?) En question ne soit exécuté sur le même serveur que le marchand, il ne devrait y avoir aucun problème de sécurité à cet égard.

Si ce n'est pas le cas pour votre site marchand, contactez-le et demandez-lui si cela est réalisable.

La passerelle de paiement permet-elle l’inversion des frais? Si tel est le cas, un certain nombre d’escroqueries sont possibles.

Le site traite-t-il les remboursements? Sera-ce jamais dans le futur?

Si nous parlons d'utilisations néfastes, le propriétaire du site peut être interrogé si de nombreux achats non autorisés sont effectués. Comment cela affecterait-il vous si le propriétaire fait l'objet d'une enquête?

D'après votre description, il semble que ce développeur ait accès aux informations détaillées relatives aux cartes client, auquel cas la confidentialité de ces derniers pourrait être compromise. Vous pouvez envisager de rédiger le contrat de manière appropriée pour vous assurer que cet angle est couvert.

Cependant, l’essentiel est que si vous travaillez sur un projet / une information sensible, il est préférable que vous trouviez des personnes de confiance. L'embauche d'une maison de logiciels pour faire le travail peut vous faire économiser du sommeil plus tard.

Avant tout, il est préférable de ne jamais stocker ce type d'informations en texte brut. Habituellement, les gens prennent cela pour une connaissance secondaire des numéros de carte de crédit (malheureusement, uniquement pour des raisons juridiques), mais toute sorte de données privées que vous ne souhaitez pas voir accessibles à d'autres personnes avec un accès à la base de données / code source devrait être cryptée. Vous devez stocker les informations de compte quelque part dans un format bien chiffré et fournir un compte de test que vos développeurs pourront utiliser sur leurs postes de travail de développement. Ainsi, seules les personnes ayant accès au serveur peuvent voir même les informations chiffrées.

Ainsi, vous pouvez avoir une base de données sur le poste de travail du développeur avec les informations d'API du compte de test stockées (éventuellement chiffrées) dans sa base de données locale, mais lorsque le code est mis en miroir sur le serveur de production, il utilisera toujours la passerelle réelle et réelle. informations stockées dans la base de données du serveur de production sans code ni configuration supplémentaire.

Cela dit, je ne pense pas qu'un programmeur avec des détails d'authentification d'API puisse faire beaucoup. De toute façon, le risque n’en vaut pas la peine, à mon avis.

J'espère que cela vous aidera.

PS: en cas de problème, vous pouvez toujours générer une nouvelle clé dans l'interface Web sur authorize.net après avoir pris les précautions nécessaires pour vous assurer que cela ne se reproduira plus.

Dans le cas spécifique d’Autorize.Net, ils ne seraient pas en mesure de créditer leurs propres cartes de crédit, car Authorize.Net ne le permet que sur les transactions effectuées par leur intermédiaire au cours des six derniers mois. La seule exception autorisée si une exception vous est accordée pour les remboursements non liés. Si vous avez signé les documents appropriés à cet effet et qu'une personne dispose de votre identifiant d'API et de votre clé de transaction, elle peut ensuite traiter les crédits avec ses propres cartes de crédit. La seule façon pour vous d’attraper cela serait de surveiller vos déclarations avec soin.

Pour atténuer ce problème, vous devez modifier votre clé de transaction dès la fin du travail effectué pour vous. Cela rendrait la clé qu'ils ont inutile après 24 heures.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top