Choix techno web pour service de paiement

Bonjour,

Je suis dev iOS, et un peu web (php et qqs autres) et je suis amené à me poser une question dans le cadre de mon boulot :

Y a-t-il un choix de techno web à préconiser dans la conception d'un service de paiement bancaire ?

Précision : le service en question est amené à gérer un nombre important de transactions bancaires, données confidentielles, etc...
Ma question porte surtout sur le thème de la sécurité et la fiabilité, au niveau des accès serveurs, de la sécurité dans les pages web etc...
Je sais que la sécurité absolue n'existe pas. Inutile par ailleurs de me parler de sécurité physique de serveurs, là n'est pas la question, je recherche plutôt des pros&cons sur les technos.

J'aimerais bien avoir essentiellement des retours sur les " plus grands " (php, java, .net)

Merci de vos réponses !

Bonsoir,
je ne pense pas qu'il y ai un meilleur langage pour le paiement en ligne. Il faut simplement faire les choses bien.

J'ai déjà vu des solutions de paiements installées avec les 3 langages que tu cites (php, java et asp), et je n'ai jamais vu de problème.

Bien que java soit réputé pour sa robustesse, je ne pense pas que ça soit à ce niveau la que ça se joue.

PS: Je te donne mon avis en temps qu'intégrateur web. Des personnes plus compétentes devraient pouvoir mieux te renseigner...

Bonsoir,

PierreP a écrit :
Y a-t-il un choix de techno web à préconiser dans la conception d'un service de paiement bancaire ?

Il y a notamment des technos à éviter et Java arrive en tête.

Ce n'est pas une question qui se discute à la légère et les réponses dépendent des tes besoins et contraintes. Ton interlocuteur, à ce stade, doit être un ingénieur réseau car c'est au niveau hardware que commence le process de sécurité. Autant dire que ce forum n'est pas le lieu adéquat pour ce genre de question.

UltrAs001 a écrit :
Bien que java soit réputé pour sa robustesse

Java est réputé pour beaucoup de chose mais certainement pas sa robustesse...

a écrit :
Java est réputé pour beaucoup de chose mais certainement pas sa robustesse...

Ah ok, je ne vais pas te contredire, je suis loin d'être un expert dans le domaine, cependant nombreux sont les sites qui vantent la robustesse de java.Une simple recherche google permet de confirmer cela (quasi tous les liens ci-dessous sont présentés dans les universités), on y retrouve toujours la notion de robustesse:

http://www-inf.it-sudparis.eu/COURS/CSC4002/EnLigne/Cours/CoursJAVA/2.2.4.html

http://membres.multimania.fr/stcad/java/histo.html

http://raphaello.univ-fcomte.fr/javareseau/Concepts.htm

http://pages.univ-nc.nc/~touraivane/Java/node4.html#SECTION02240000000000000000
Modifié par UltrAs001 (23 Oct 2012 - 09:58)

Java est un marronnier en sécurité informatique. On ne s'étonne plus que des 0 day ou des exploits immondes apparaissent de semaine en semaine, on s'étonne quand aucune faille n'est découverte.

À l'heure actuelle, ce qui contribue à la relative popularité de Java, c'est le fait qu'il soit largement enseigné dans les écoles et universités en substitution au C/C++.

Akhilleus a écrit :
Java est un marronnier en sécurité informatique. On ne s'étonne plus que des 0 day ou des exploits immondes apparaissent de semaine en semaine, on s'étonne quand aucune faille n'est découverte.

À l'heure actuelle, ce qui contribue à la relative popularité de Java, c'est le fait qu'il soit largement enseigné dans les écoles et universités en substitution au C/C++.

Attention aux confusions !

Les failles dont tu parles concernent la machine virtuelle Java et non le langage en lui-même.

De plus, j'aimerais que tu fournisses des exemples de failles qui concernent la vulnérabilité des serveurs Web basés sur Java puisque c'est de cela dont il s'agit dans ce sujet. Ces serveurs sont-ils moins robustes que les serveurs basés sur d'autres technologies ?

Julien Royer a écrit :
Attention aux confusions !

Il n'y a aucune confusion dans mon esprit

Julien Royer a écrit :
Les failles dont tu parles concernent la machine virtuelle Java et non le langage en lui-même.

Je ne parle évidemment pas du langage mais de failles sur JRE (dont JVM n'est qu'une partie).

Julien Royer a écrit :
De plus, j'aimerais que tu fournisses des exemples de failles qui concernent la vulnérabilité des serveurs Web basés sur Java puisque c'est de cela dont il s'agit dans ce sujet.

Au hasard... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4681

Choisir le langage Java, c'est choisir ce qui va avec. Dans le cas ci-dessus, ça concerne des vulnérabilités côté client.

Akhilleus a écrit :
Il n'y a aucune confusion dans mon esprit

Peut-être, mais ton discours est un peu ambigu, et je rappelle que même lorsque nous avons les idées claires, celles-ci ne se transmettent pas par magie à notre interlocuteur (encore moins sur un forum).

Akhilleus a écrit :
Je ne parle évidemment pas du langage mais de failles sur JRE (dont JVM n'est qu'une partie). Au hasard... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4681

Choisir le langage Java, c'est choisir ce qui va avec. Dans le cas ci-dessus, ça concerne des vulnérabilités côté client.

Comme je te le disais, je voudrais des exemples de failles liées à l'utilisation de Java sur un serveur Web ; ton exemple n'en fait pas partie, il illustre un problème relatif à l'exécution d'applets par l'intermédiaire d'un navigateur.
Modifié par Julien Royer (24 Oct 2012 - 09:37)

Bonjour,

Akhilleus, choisir Java pour la technologie côté serveur n'oblige personne à utiliser Java pour le côté client.

PierreP, le choix de la technologie côté serveur, que ce soit PHP, Coldfusion, .NET n'est pas ce qui fera la plus grande différence dans la sécurité et les performances. L'essentiel est que le développeur qui utilisera l'une ou l'autre de ces technologies soit compétent et expérimenté. Les failles de sécurité des applications Web sont majoritairement le fruit du développeur qui par négligence ou méconnaissance, n'a pas protégé son application contre les injections SQL, le Cross-site scripting, Cross-site request forgery, Brute force et autres. Pour les performances, c’est aussi une question de maîtrise de la technologie choisie.

Il y a évidemment tout ce qui gravite autour comme la sécurité du serveur (intrusion informatique, accès physique), le poste informatique du développeur (virus, spyware, choix des mots de passe ou stockage des mots de passe en clair). Mais passons, puisque vous ne souhaitez pas parler de cette partie.

Maintenant, la question est de savoir si vous voulez :
A. Devenir un fournisseur de solution de paiement
B. Utiliser un fournisseur de solution de paiement existant pour l'une de vos applications

Dans le cas de B, le fournisseur de solution de paiement fourni au marchand (vous) des exemples de code en différents langages comme PHP, ASP, Coldfusion, etc. ainsi que des explications sur la méthode de communication entre votre application et leur API de paiement. En général, le client saisie ses informations de crédit sur le site sécurisé (ssl - https) du marchand et ce dernier les transmets directement à l’API du fournisseur de solution de paiement qui lui retourne une réponse de succès ou d’échec de paiement. Le marchand ne stocke jamais les numéros de carte de crédit complet sur son propre serveur.

Est-ce que ça répond à votre question? Je peux donner plus de détails si nécessaire.

D'ailleurs, veuillez préciser si c'est plutôt le point A qui vous intéresse.