Passerelle de paiement étrange
J'ai un client indépendant qui souhaite que j'intègre une passerelle de paiement dans son site Woocommerce mais je suis de plus en plus préoccupé par son choix de fournisseur et le projet dans son ensemble.
Les problèmes
Contre mon avis, le client a choisi le fournisseur de passerelle. Le fournisseur est un Extrême-Orient dont je n'ai jamais entendu parler auparavant appelé Payforasia. Le premier indicateur d'avertissement est le fait que la version anglaise et chinoise (je pense que c'est chinois) de leur site Web ne semble pas charger correctement les images.
On m'a fourni de la documentation pour l'API de passerelle sous la forme d'un PDF et d'une simple démonstration PHP. Ils m'ont également donné une connexion au front-end marchand pour que je puisse surveiller mes transactions de test. Tout à fait normal.
J'ai exécuté la démo sur mon hôte local et j'ai réussi à me connecter à la passerelle de paiement, mais j'ai reçu une réponse d'erreur d'échec. L'erreur n'était pas répertoriée dans la documentation, en fait la liste des erreurs possibles va de 0001 à 0067. J'obtenais l'erreur 0068. Le deuxième indicateur d'avertissement. Lorsque j'ai contacté le fournisseur, par l'intermédiaire de mon client, pour demander des documents à jour et des conseils sur l'erreur. On m'a dit que les documents sont les plus récents et que le bureau a été fermé pendant plus d'une semaine en raison d'une fête nationale (!?!?!). Ils sont finalement revenus vers moi aujourd'hui et ont dit que l'erreur était "probablement" due au fait qu'ils n'avaient pas ajouté l'IP du serveur à la liste blanche et qu'ils l'avaient résolu maintenant. Je reçois toujours la même erreur.
En attendant qu'ils me reviennent, j'ai commencé à fouiller dans le code de démonstration et à relire leur documentation pour voir si j'avais oublié quelque chose d'évident. J'ai remarqué cette ligne dans leurs documents:
csid String 100 Oui Capturez la valeur via http://cm.js.dl.saferconnectdirect.com/csid.js
Depuis les tests d'origine, et en attendant qu'ils fassent leur fête nationale d'une semaine, j'avais appliqué un SSL au site de mon client et, évidemment, le navigateur ne chargerait pas la connexion non sécurisée au javascript. L'URL de ceci est dans la démo mais tout en bas après un grand nombre de retours entre elle et le balisage du formulaire de démonstration. Un autre drapeau me fait signe.
Il s'avère après avoir essayé l'URL agnostique du protocole et HTTPS que le csid.js N'est pas disponible via une connexion sécurisée. J'ai donc copié le JS sur le serveur et modifié le lien dans le balisage. C'est là que le drapeau flottant commence vraiment à devenir mental.
Le script remplit le champ CSID avec ma chaîne d'agent utilisateur, ma résolution d'écran, le serveur d'origine et les données hachées. Plus inquiétant, cela ajoute également un iframe qui semble être une image de suivi ou quelque chose de similaire. L'iframe déclenche six connexions étranges à l'aide d'un protocole wss: // vers localhost.
Je dois admettre qu'à ce stade, j'ai paniqué et je suis venu ici pour demander des conseils. Le JS est minifié et semble avoir une PHP eval() et ce qui ressemble à des caractères encodés. Je ne sais pas comment décoder cela et je ne sais pas si il est prudent de continuer à approfondir le code.
Mes questions
J'ai besoin de conseils.
- Suis-je trop paranoïaque ou ai-je un réel souci?
- Est-il normal qu'un fournisseur de passerelle brouille son code comme ceci?
- Dois-je conseiller à mon client de changer immédiatement de fournisseur?
- Dois-je m'éloigner et l'enregistrer à l'expérience?
Tout conseil, suggestion ou commentaire à ce sujet sera grandement apprécié. Désolé si ma question est décousue et un peu longue, je voulais obtenir autant d'informations que possible.
Mise à jour
Merci à tous ceux qui m'ont donné d'excellents conseils, je voulais juste vous donner une mise à jour rapide.
J'ai fait part de mes inquiétudes à mon client, qui n'a pas réagi comme je m'y attendais. J'ai été accusé de me traîner délibérément les pieds, d'inventer des problèmes, d'être incompétent et j'ai reçu des questions moins professionnelles quant à ma filiation. Les relations entre moi et mon client se sont définitivement givrées.
Ils ont insisté pour que j'implémente la passerelle sans SSL sur le site DU TOUT. Quand j'ai refusé et les ai invités à trouver un autre développeur, ils ont reculé presque immédiatement et sont devenus un peu plus cordiaux, même si je n'ai pas encore reçu d'excuses.
Depuis lors, ils ont révélé que le fournisseur de la passerelle avait mis sur liste blanche la mauvaise adresse IP, c'est pourquoi je recevais toujours la mystérieuse erreur 0068. Le fournisseur de passerelle a essayé de m'épingler sur celui-ci jusqu'à ce que je fournisse les journaux Skype à l'effet contraire. Mon client ne me laisse pas parler directement au fournisseur de passerelle, donc l'adresse IP a été tronquée à un moment donné entre eux.
En ce qui concerne le JavaScript non sécurisé, mon client m'a soudainement fourni, tard hier, cette url https://online-safest.com/pub/csid.js. Ils n'ont fourni aucune documentation supplémentaire ni d'où ils ont obtenu ce script. Je n'ai pas encore testé ce script.
Je ne suis pas sûr de vouloir continuer, donc je me traîne les pieds. J'ai besoin d'y penser aujourd'hui. J'accepterai une réponse demain, malheureusement je ne peux pas accepter plusieurs réponses même si j'ai utilisé le contenu de plusieurs.
Mise à jour 2
Juste une dernière mise à jour. J'ai terminé ce projet pour mon client, mais je crains que ma relation avec eux ne soit irrémédiablement endommagée. Ils ont insisté pour que je mette la passerelle en direct sans aucun test au-delà du fait qu'une seule transaction de test ait été effectuée. Je leur ai dit que tout problème post-live qu'ils auraient, ils devront trouver un autre développeur car ils sont passés en direct sans test et ont perdu ma période de support normale.
Vous pourriez faire valoir qu'il est contraire à l'éthique pour moi de libérer du code dans la nature qui pourrait être bogué et dangereux pour les utilisateurs finaux, mais je n'ai vu aucun autre moyen de quitter facilement le contrat. Je leur ai donné un accès complet au référentiel GIT privé contenant la source qui contient toutes les interactions documentées entre moi et le client. Tout futur développeur devrait pouvoir le voir et prendre une décision à partir de là.
J'ai découvert en outre qu'ils m'avaient en fait sous-traité. Dans l'ensemble, c'est un projet dont je suis heureux de me débarrasser.
Merci à tous pour votre aide, vos conseils et votre soutien.
- Suis-je trop paranoïaque ou ai-je un réel souci?
Vous avez une réelle inquiétude. Quelque chose ne va pas ici.
- Est-il normal qu'un fournisseur de passerelle brouille son code comme ceci?
L'obfuscation n'est pas, en soi, anormale. Cependant, au moment où ils essaient d'ouvrir des connexions d'hôte local à RDP, VNC et à d'autres ports, ce n'est pas de l'obscurcissement, c'est complètement inapproprié et malveillant.
- Dois-je conseiller à mon client de changer immédiatement de fournisseur?
Je voudrais informer votre client que le code fourni pour l'intégration semble être malveillant et que vous ne pouvez pas supposer que le fournisseur est a) légitime ou b) capable de sécuriser son entreprise (et par extension, celle de votre client). De plus, le fournisseur ne semble pas s'intégrer correctement dans un environnement d'achat sécurisé (le lien http: only js), ce qui remet en cause leur pertinence même s'il est légitime.
Selon le commentaire de @ JaimeCastells à la question, il n'y a pas de fournisseur de services "payforasia" répertorié sur http://www.visa.com/splisting/searchGrsp.do . Cela pourrait signifier qu'ils font des affaires sous ce nom mais sont certifiés sous un nom différent, ou cela peut signifier qu'ils sont un "fournisseur de services de niveau 2". Franchement, aucune de ces options n'est rassurante.
- Dois-je m'éloigner et l'enregistrer à l'expérience?
Si le client veut continuer avec ce fournisseur, j'envisagerais certainement de partir. Vous ne pouvez pas obliger le client à faire la bonne chose, mais vous pouvez choisir de ne pas être celui qui fait la mauvaise chose pour lui.
Analyse Javascript
L'intention du Javascript obscurci semble importante. J'ai essayé de démêler ce qui se passe dans le Javascript, et je vais créer un lien vers des copies lisibles partiellement désobscurcies dans cette section.
Dans l'ensemble, j'ai l'impression que le niveau d'obscurcissement utilisé dans ces scripts dépasse ce qui est commercialement raisonnable et devient par conséquent suspect. Le nombre limité d'inférences que je peux tirer sur ce qu'il fait n'est pas conforme au traitement normal des paiements. Faute de meilleures informations, je suppose que c'est du javascript malveillant.
Voici les fichiers que je regarde si vous souhaitez explorer la même question. Ces fichiers ont été exécutés via Embellisseur Javascript en ligne et j'ai également utilisé l'Éditeur Javascript en ligne pour séparer les bits de ce que font les scripts. Vous pouvez voir que même avec la désobfuscation de base appliquée, il y a encore beaucoup d'obscurcissement en place - check.js est plein de tableaux d'entiers qui sont traités par le code, et qui sont probablement plus de texte ou de code à exécuter.
Il y a au moins quatre scripts impliqués:
Il est clair, par exemple, que les cinq ports que l'OP a vu obtenir des tentatives de connexion sont câblés dans check.js:
td_0a = ['REF:63333', 'VNC:5900', 'VNC:5901', 'VNC:5902', 'VNC:5903', 'RDP:3389'];
Je vais continuer à les pousser, et peut coller quelques copies, mais je pense qu'il est raisonnable de se méfier de ce code à ce stade.
Un peu plus d'informations sur ce javascript obscurci: Ils utilisent packer, une méthode de compression javascript assez célèbre. Voici le js décompressé (vous pouvez également le décompresser vous-même ici: http://dean.edwards.name/unpacker/ ):
var a = "";
try {
var z = document.createElement('canvas');
var A = z.getContext('2d');
var B = 'http://security.tencent.com/';
A.textBaseline = "top";
A.font = "14px 'Arial'";
A.textBaseline = "tencent";
A.fillStyle = "#f60";
A.fillRect(125, 1, 62, 20);
A.fillStyle = "#069";
A.fillText(B, 2, 15);
A.fillStyle = "rgba(102, 204, 0, 0.7)";
A.fillText(B, 4, 17);
var C = z.toDataURL();
C = C.replace("data:image/png;base64,", "");
var D = atob(C).slice(-16, -12);
a = b(D)
} catch (err) {};
function b(z) {
var A, B, C = '',
D;
z += '';
for (A = 0, B = z.length; A < B; A++) {
D = z.charCodeAt(A).toString(16);
C += D.length < 2 ? '0' + n : D
};
return C
};
function c(z, A) {
var B = 180;
var C = new Date();
C.setTime(C.getTime() + B * 24 * 60 * 60 * 1000);
document.cookie = z + "=" + escape(A) + ";expires=" + C.toGMTString()
};
function d(z) {
var A, B = new RegExp("(^| )" + z + "=([^;]*)(;|$)");
if (A = document.cookie.match(B)) return unescape(A[2]);
else return null
};
function e() {
var z = "";
for (var A = 1; A <= 32; A++) {
var B = Math.floor(Math.random() * 16.0).toString(16);
z += B
};
z += new Date().getTime();
return z.toUpperCase()
};
var f = "";
f = d("ccpspay");
if (f == null || f == '') {
f = c("ccpspay", e());
f = d("ccpspay")
} else {
f += "OLD"
};
var g = "vduzzz8d";
var h = e();
var i = "";
i = navigator.systemLanguage || window.navigator.systemLanguage || navigator.language;
var j = "";
j = navigator.browserLanguage || window.navigator.browserLanguage || navigator.language;
var k = "";
k = navigator.appCodeName || window.navigator.appCodeName;
var l = "";
l = navigator.appMinorVersion || window.navigator.appMinorVersion;
var m = "";
m = navigator.appName || window.navigator.appName;
var n = "";
n = navigator.appVersion || window.navigator.appVersion;
var o = "";
o = navigator.cookieEnabled || window.navigator.cookieEnabled;
var p = "";
p = f;
var q = "";
q = a;
var r = "";
r = navigator.platform || window.navigator.platform;
var s = "";
s = navigator.userAgent || window.navigator.userAgent;
var t = "";
t = navigator.userLanguage || window.navigator.userLanguage;
var u = "";
u = String(window.screen.fontSmoothingEnabled);
var v = "";
v = String(window.screen.width + "x" + window.screen.height);
var w = "";
w = String(window.screen.colorDepth);
var x = new Array;
x[0] = i;
x[1] = j;
x[2] = k;
x[3] = l;
x[4] = m;
x[5] = n;
x[6] = o;
x[7] = p;
x[8] = q;
x[9] = r;
x[10] = s;
x[11] = t;
x[12] = u;
x[13] = v;
x[14] = w;
x[15] = new Date().getTimezoneOffset() / 60 * -1;
x[16] = window.location.Host;
x[17] = h;
var y = x.join("&@");
document.getElementById("csid").value = y.toUpperCase();
document.write("<script type='text/javascript' src='https://h.online-metrix.net/fp/tags.js?org_id=" + g + "&session_id=" + h + "&pageid=1'></script>");
document.write("<noscript><iframe style='width: 100px; height: 100px; border: 0; position: absolute; top: -5000px;' src='https://h.online-metrix.net/tags?org_id=" + g + "&session_id=" + h + "&pageid=1'></iframe></noscript>");
Bien qu'ils puissent être une passerelle de paiement légitime (je ne sais pas, mais ils me semblent assez louches), ils sont remplis d'outils de suivi. Vous voudrez peut-être au moins en avertir le client.
Le comportement du code Javascript que vous analysez est inhabituel, mais plausible dans le cadre d'un système anti-fraude.
Ce script est utilisé pour évaluer le risque de fraude d'un ordinateur client. Dans le cadre de cette évaluation, il vérifie si la machine peut être configurée en tant que proxy Web ouvert - c'est pourquoi le script tente d'ouvrir WebSockets sur localhost sur différents ports. Je n'ai jamais vu cette technique particulière auparavant, mais je pense que c'est plutôt intelligent en fait. :) Il évite d'effectuer une analyse de port externe invasive en faisant analyser lui-même un ordinateur client!
Je n'ai pas entièrement analysé le script moi-même, mais sur la base de certains mots clés du script que vous avez lié, il semble que le script collecte également diverses informations d'identification à partir du navigateur, telles que la version du navigateur, la langue du système et divers options de configuration. Encore une fois, cela est raisonnable pour une évaluation antifraude, et ce fournisseur n'a pas l'habitude d'utiliser ce type de méthodes.
Je ne répondrai qu'à la première question sous un autre angle:
Suis-je trop paranoïaque ou ai-je un réel souci?
Vous avez une réelle inquiétude en raison de leur seul site Web.
La raison pour laquelle les images ne se chargent pas est due à AdBlock (voir l'image ci-dessous).
La source de leurs images se trouve sur un serveur distinct:
(probably don't want to look at it, to be safe)
http://www.payforasia.com.img.800cdn.com/images/logo.jpg
800cdn.com figure sur la liste des domaines malveillants:
https://easylist-downloads.adblockplus.org/malwaredomains_full.txt
L'entreprise est chinoise, et les sections chinoises mentionnent qu'elle est à Shenzhen.
Peut-être que votre client n'est pas à jour. Vous pouvez aller sur SSL Labs et vérifier leur serveur. S'ils n'autorisent que les protocoles les plus récents, votre code client peut échouer. (Sur mon serveur, par exemple, tous les clients Java échouent parce que je ne les utilise pas et ne m'en soucie pas!)
Sinon, je suis d'accord, pratiques très douteuses. Pouvez-vous contacter quelqu'un en Chine pour vérifier s'il s'agit d'un fournisseur normal et également que vous disposez des bonnes données d'accès? Serait-ce quelqu'un prétendant être cette entreprise?
Aussi, pas pour vous rendre plus paranoïaque, mais toute réponse que vous obtenez ici que le service est légitime ou où vérifier s'il peut provenir exactement des personnes que vous interrogez. ;-)