Question:
Je viens de découvrir des failles de sécurité majeures dans ma boutique en ligne?
Moses
2011-07-27 10:52:50 UTC
view on stackexchange narkive permalink

Une petite information de base ici: je suis un développeur Web autodidacte avec très peu d'expérience en dehors du html / css, et la société pour laquelle je travaille a embauché une équipe de développement Web tierce pour nous concevoir un site de commerce électronique . Quoi qu'il en soit, je testais le site en version bêta aujourd'hui en utilisant le module complémentaire TamperData Firefox, et j'ai trouvé deux défauts de conception majeurs qui impliquent tous deux des en-têtes HTTP.

Le premier défaut était que lorsque notre site demande à l'utilisateur de choisir une option de fret (terrestre, express, etc.) le site renvoie la valeur de fret calculée au serveur dans un en-tête HTTP. En manipulant l'en-tête, j'ai pu modifier (voir: effacer) la valeur de fret et donc le backend a interprété la valeur de fret calculée comme 0, et donc il ne m'a pas facturé de fret!

La deuxième faille , cependant, est bien pire ... Lorsque la valeur totale du produit est calculée et que je "checkout", toutes les informations de transaction (CC #, CVV2, Expiration, $ total) sont transmises à un processeur marchand tiers via un en-tête HTTP . Encore une fois, j'ai utilisé TamperData et j'ai pu manipuler l'en-tête pour que la valeur $ envoyée au marchand soit quelque chose de trivial (je choisis $ 1 pour le test).

Le fait que je - avec absolument aucune expérience en matière de sécurité de site Web ou de codage côté serveur - j'ai pu trouver ces graves défauts m'a complètement effrayé, car qu'est-ce que cela dit des programmeurs qui ont conçu cela? Bien sûr, ils résoudront probablement ces deux problèmes d'une manière ou d'une autre. MAIS, si l'envoi de données de carte de crédit dans un en-tête HTTP en texte brut leur semblait une bonne idée, leur nouvelle solution sera-t-elle de manière réaliste plus sécurisée? Et s'il y avait d'autres vecteurs d'attaque complètement séparés que j'ai manqués?

Ainsi, mes questions pour vous:

  1. Compte tenu des informations ci-dessus, quelles étapes prendre pour éviter ces failles de sécurité? (je sais donc quoi demander à nos programmeurs de faire)

  2. Quels livres, sites et / ou ressources sont disponibles pour que je puisse me renseigner sur la sécurité Web et comment effectuer des tests de pénétration réels? Il faudra un certain temps à mon entreprise pour organiser un audit de sécurité externe et, en attendant, je souhaite réparer le plus possible le site.

MISE À JOUR :

Comme je l'ai dit dans un commentaire ci-dessous, je suis intéressé de savoir exactement à quel point il est sécurisé de transmettre les informations de paiement dans un en-tête http au marchand cc (nous utilisons un https connexion si cela compte). Des tiers peuvent-ils écouter ou intercepter ces paquets? Et s'ils le peuvent, est-ce un scénario réaliste ou est-ce hautement improbable? Je pose cette question car je n'ai pas encore une bonne compréhension du fonctionnement de la transmission de données via des en-têtes HTTP, du moins au niveau technique.

Cette question était Sécurité informatique Question de la semaine .
Lisez le article de blog du 12 août 2011 pour plus de détails ou envoyer votre propre Question de la semaine.

S'agissait-il d'un site développé sur mesure à partir de zéro? Ou utilisez-vous une sorte de forfait d'abonnement e-commerce?
@Bryan C'était un site personnalisé, entièrement développé par eux.
Dommage. Désolé de le dire, mais cet argent est probablement ce que j'appellerais des «frais de scolarité».
Avez-vous considéré les avantages à long terme du cryptage SSL? Je n'utiliserai jamais une boutique en ligne qui n'a pas de certificat SSL protégeant les données de ma carte.
Je viens de relire le Q. Votre équipe de développement transmet les détails de la carte dans les en-têtes HTTP? Cette solution est simple. Tirez-les. Embauchez quelqu'un qui comprend la conformité PCI-DSS. Oh, et utilisez simplement une plate-forme de commerce électronique prête à l'emploi la prochaine fois.
Avez-vous envisagé un emploi dans les tests d'intrusion? Vous semblez avoir le bon état d'esprit pour cela, et cela paie beaucoup mieux que les développeurs Web autodidactes. Avec un peu d'entraînement, je pense que vous seriez probablement assez efficace.
Une question qui s'est posée après avoir lu vos réponses: la transmission des détails de la carte via les en-têtes HTTP n'est-elle pas sécurisée au point que les utilisateurs malveillants puissent les écouter ou les intercepter? Dans quelle mesure serait-il pratique (voir: réaliste) d'intercepter ces informations de carte? Le site utilise https sur toutes les pages sensibles (même si j'ai un sentiment qui ne veut pas dire grand-chose)
Je suis confus. Il est très rare d'envoyer ce type d'informations dans les en-têtes HTTP, mais le fait de savoir si elles sont envoyées dans l'en-tête ou le corps est généralement sans importance. Deuxièmement, c'est généralement le serveur qui envoie les informations de carte de crédit au processeur de carte de crédit afin que le navigateur d'un acheteur n'ait même jamais accès à ces communications. Le serveur doit contrôler toutes les communications et ne doit jamais faire confiance aux informations fournies par le client.
Il semble y avoir une certaine confusion sur la façon dont SSL / TLS serait pris en compte. TLS n'empêche que la falsification par un homme du milieu (et seulement lorsqu'elle est correctement configurée et utilisée), mais elle * n'empêche pas * la falsification par l'utilisateur final. L'utilisateur final peut facilement modifier son propre trafic SSL en utilisant quelque chose comme Tamper Data ou un proxy SSL (comme mitmproxy).
De plus, tout système dans lequel le client indique au serveur combien il veut payer est défectueux de par sa conception. Le client doit indiquer au serveur quels articles il veut et en quelles quantités. Le serveur doit calculer le montant à facturer à l'utilisateur et doit envoyer ces informations directement au processeur de paiement, * et non à l'utilisateur *.
Pour référence future: Des scénarios très similaires sont décrits dans le document de recherche de Microsoft: ["Comment acheter gratuitement en ligne"] (http://research.microsoft.com/pubs/145858/caas-oakland-final.pdf) de 2011. Il contient des informations détaillées sur le même type d'attaque, mais dans le cadre de l'utilisation de processeurs de paiement externes, par exemple Pay Pal.
Neuf réponses:
Bryan Agee
2011-07-27 11:01:18 UTC
view on stackexchange narkive permalink

Quelques suggestions:

1) Ne créez pas de site à partir de zéro, à moins qu'un nouveau type de commerce électronique ne soit votre sauce secrète. Il existe de nombreuses solutions qui ont fait leurs preuves - ebay, wordpress avec un plugin de panier d'achat, drupal avec des plugins, etc. Rouler le vôtre est un moyen rapide de se faire pirater.

2) Be assurez-vous de vous rediriger vers un processeur de paiement sécurisé avant de collecter des informations de carte ou d'identité. PayPal et Google Checkout offrent tous deux d'excellents portails avec des API qui facilitent la vente de produits en toute sécurité et la redirection vers votre site.

3) De nombreuses sociétés d'hébergement (GoDaddy, volusion, etc.) paramètres clés, de sorte que tout ce que vous avez à faire est de remplir un catalogue, de choisir un style, d'expédier des choses et d'aller à la banque.

Nous utilisons déjà un processeur marchand tiers, donc s'il y avait un moyen de *** communiquer en toute sécurité *** avec eux en utilisant une méthode standard de l'industrie pour transférer des informations cc, je serais intéressé de savoir. (Cependant, je suis sûr à 90% que nous ne pouvons pas rediriger l'utilisateur vers une page de traitement hébergée par le marchand; nous ne pouvons probablement communiquer qu'avec leur backend)
@moses, pourquoi ne seriez-vous pas en mesure de rediriger vers un marchand pour traitement? Cela vous aide vraiment à éviter de vous tirer une balle dans le pied (et à vos clients) ...
chris
2011-07-27 12:47:18 UTC
view on stackexchange narkive permalink

Mon conseil est le suivant: embauchez une entreprise de sécurité pour faire des tests d'intrusion sur le produit une fois terminé. Si possible, obtenez une exigence de sécurité dans le contrat avec le développeur, afin qu'il soit obligé de résoudre tous les problèmes de sécurité comme s'il s'agissait de bogues normaux (lire: gratuitement). Cela peut sembler exagéré, mais à mon avis, si l'année dernière nous a appris quelque chose, c'est que la sécurité des applications Web devrait être par défaut maintenant.

Vous pouvez définir vous-même certaines exigences de sécurité et utiliser celles de l'autre réponse (s), mais vous ne serez pas en mesure de faire un audit de sécurité complet si vous n'êtes pas formé dans ce domaine. Alors ne comptez pas là-dessus. Vous pouvez réparer le système de paiement, mais laissez certaines grandes injections SQL ou l'exécution de fichiers téléchargés sans correction.

symcbean
2011-07-27 14:29:09 UTC
view on stackexchange narkive permalink

Toutes les données fournies par l'utilisateur peuvent être altérées par l'utilisateur. Vous devriez vous compter très chanceux si ce sont les seuls problèmes du site. Mais ils indiquent un manque de qualité du produit livré.

Ayant travaillé avec des entreprises allant de simples boutiques en ligne maman + pop à temps partiel aux grandes institutions financières, la seule chose que j'ai apprise est que l'externalisation informatique fonctionne très rarement dans l'intérêt de l'entreprise. Au minimum, vous devez avoir un personnel informatique expérimenté qui participe activement à la spécification du contrat du produit et à la spécification des fonctionnalités. Je parie que le contrat dans ce cas est très long en termes de coûts et de délais de livraison, mais comporte très peu de conditions concernant la qualité, la conformité et la garantie.

Les 2 défauts que vous avez décrits, bien que tous deux résultant de la falsification des données , sont assez différents. Dans le premier cas, puisqu'il y a probablement une session en place, il n'est pas nécessaire d'envoyer les données lors d'un aller-retour au navigateur en premier lieu. Mais pour les deux problèmes avez-vous vérifié que les modifications ne sont pas prises en compte plus tard dans le traitement?

La solution aux deux est la même - stockez les montants (ou les détails nécessaires pour calculer les montants) sur votre serveur et vérifiez que les montants renvoyés par le navigateur ne sont pas différents une fois l'opération terminée. par exemple. lors de la génération de la page des options de transport, stockez les métriques utilisées pour calculer l'expédition (par exemple le poids), puis lorsque vous obtenez une méthode d'expédition et un montant en retour, calculez le montant attendu à partir du poids stocké et de la méthode d'expédition fournie.

Bien qu'il puisse sembler plus simple de ne pas se donner la peine de renvoyer un montant directement depuis la page, ou simplement d'ignorer ce montant, si votre site a déjà indiqué au client sur la page quel sera le montant d'expédition (par exemple avec un calcul javascript) vous devez vous assurer que, pour une transaction légitime, la même valeur apparaît sur la facture du client!

ie ce sont deux problèmes insignifiants à résoudre.

Mais comme vous l'avez laissé entendre, l'envoi d'informations de carte de crédit via un canal non sécurisé est une erreur très sérieuse, voire illégale. Et c'est le troisième défaut et de loin le plus grave.

Tous les logiciels ont des bogues, mais pris ensemble, ils jettent de très sérieux doutes sur la compétence du développeur et suggèrent que vous venez de gratter la surface du problèmes avec ce produit.

BTW: il y a très peu de sites sur lesquels je voudrais entrer les détails de ma carte de crédit - même avec SSL. Il existe plusieurs entreprises de premier plan qui fournissent une solution complète pour le traitement des paiements, par ex. Paypal, Worldpay, Google où le marchand n'a pas de visibilité directe sur les détails de ma carte de crédit.

Pour en savoir plus sur la sécurité du site Web, vous trouverez un bon matériel d'introduction (et des informations plus avancées) sur sans.org et owasp.org

Robert David Graham
2011-07-27 21:09:22 UTC
view on stackexchange narkive permalink

La réponse est "OWASP" ou "Open Web Application Security Project", sur http://www.owasp.org. Ces types sont la norme pour comprendre les vulnérabilités typiques (comme celle-ci) qui affligent les applications Web.

Vous avez également demandé "qu'est-ce que cela dit sur les programmeurs" qu'ils pourraient avoir des bogues aussi triviaux. La réponse à votre question est que la plupart des programmeurs d'applications Web ne comprennent pas vraiment ce qui se passe. Ils ne croient pas que les pirates peuvent changer les en-têtes HTTP en transit.

Actuellement, dans l'actualité, il y a eu beaucoup de hacks de haut niveau ("LulzSec"). Ces enfants ne font pas de piratage compliqué, mais les choses simples que vous avez faites, comme la modification des en-têtes HTTP lors de la soumission de données.

Rory McCune
2011-07-28 12:07:05 UTC
view on stackexchange narkive permalink

Je vais d'abord répondre à la question dans votre mise à jour.

La transmission de données CC via des connexions HTTPS est (si elle est correctement configurée) très bien. Si vous regardez la plupart des configurations de commerce électronique (amazon, etc.), alors chaque fois qu'ils prennent des données CC, c'est comme ça que c'est fait. Cela dit, le peu sur les en-têtes HTTP est étrange ... Habituellement, les données seraient transmises dans le cadre d'une soumission de formulaire ou (et c'est une mauvaise idée) dans le cadre d'une requête GET dans l'URL, mais je ne l'ai jamais vue en fait transmis dans les en-têtes auparavant.

Concernant les problèmes que vous avez découverts, comme l'ont mentionné quelques autres réponses, d'après ce que vous avez dit, il semble que ce que les développeurs ont fait n'est pas une mise en œuvre correcte vérification côté serveur des données fournies par le navigateur.

Toutes les informations (totaux des achats, montants de fret) doivent être recalculées côté serveur après leur soumission depuis le navigateur, afin de garantir qu'elles n'ont pas été altérées.

Si vous êtes obtenir un site de commerce électronique complet codé pour vous, je vous recommande de faire effectuer une évaluation de sécurité indépendante avant sa mise en ligne. Lorsque vous traitez des données de carte de crédit, vous devrez le faire de toute façon car vous serez dans le champ d'application de PCI.

Tout comme je l'ai demandé à @midnightmonster,, je suis un peu confus quant à la sécurité de notre transaction de commerce électronique, car si un pirate informatique utilise un serveur proxy entre le client et notre serveur, toutes nos communications seront ouvertes sous forme de transmissions TCP en texte brut. Ne devrions-nous pas implémenter le cryptage de nos données sur le backend avant de les envoyer afin de ne pas dépendre du cryptage HTTP sur SSL? S'agit-il d'une menace majeure dont nous devrions nous inquiéter, ou s'agit-il d'un vecteur d'attaque si improbable que nous devrions simplement l'ignorer.
Si les données sont transmises via SSL, le proxy ne verra rien d'autre que des données cryptées (à moins qu'il ne termine et rétablisse la connexion SSL). S'ils mettent fin à la connexion SSL, l'utilisateur recevra un avertissement concernant le certificat, car le nom sur le certificat ne correspondra pas à un certificat émis valide sans beaucoup de travail supplémentaire de la part de l'attaquant. En fin de compte, si l'attaquant peut intercepter tout le trafic d'un client vers votre site, le client est probablement un peu à risque, mais vous ne pouvez pas faire grand-chose à ce sujet ...
David Eison
2011-07-28 20:16:46 UTC
view on stackexchange narkive permalink

Ce que fait HTTPS, et tout ce que fait HTTPS, c'est empêcher les tiers de s'impliquer au milieu. Il empêche l'homme au milieu des attaques, des tiers lisant ou modifiant les données au fur et à mesure qu'elles sont transmises, et c'est tout. (Modifier, puisque je ne peux pas commenter un autre message: vous êtes toujours vulnérable aux proxys auxquels l'utilisateur final fait confiance. Https empêche un tiers inconnu de prétendre être vous, mais votre utilisateur peut toujours collaborer avec un proxy connu. Il recevra des avertissements indiquant qu'un homme au milieu est en train de se produire, et il peut choisir de ne pas en tenir compte et de l'autoriser, car c'est lui qui contrôle cette attaque. Démontrez-vous facilement en configurant Fiddler et en le disant à un proxy Connexions https (pas la valeur par défaut, et il met en garde contre cela, mais il le fera pour vous si vous le lui dites. [6]))

Vous avez donc deux principaux problèmes potentiels: De chaque côté de la connexion. Vous pourriez avoir un problème dans le code de votre serveur, ou un problème avec un client malveillant (pas nécessairement l'utilisateur actuel) (Une 3ème classe de problèmes est possible si vous rebondissez entre http et https à tout moment après avoir authentifié l'utilisateur ou lui avoir donné un 'session', détournement de session ou sidejacking - un tiers obtient suffisamment d'informations pendant la partie http de la conversation pour lancer sa propre conversation https authentifiée. "Firesheep" est un outil pour le démontrer.)

Le meilleur aperçu J'ai vu pour vous tenir au courant de ce que vous devez savoir, c'est la liste des 10 meilleurs projets Open Web Application Security Project. [1]

Côté serveur, vous devez vous assurer que votre code vérifie les entrées malveillantes:

  • "Sql Injection" ("petites tables de bobby ": [2]) (principalement défendu en utilisant systématiquement des" variables de liaison ", mais voir OWASP pour plus)

  • "Cross Site Scripting" ou XSS (si vous prenez une entrée d'un utilisateur, comme une critique de produit ou son nom, et l'affichez à un autre utilisateur, l'utilisateur 1 peut voler des informations sur l'utilisateur 2 en entrant des informations malveillantes comme un mauvais javascript). Principalement défendu en utilisant une liste blanche de choses valides qu'un utilisateur doit fournir, en échappant à toutes les sorties fournies par un utilisateur (difficile à faire parfaitement / uniformément), et en ne laissant pas les utilisateurs entrer html (C'est l'une des raisons pour lesquelles des choses comme Markdown, l'édition langage utilisé sur le débordement de pile, existe. L'autre raison est que le HTML est trop facile à bousiller - les balises non fermées ruinent le reste de la page - et difficile à analyser / valider.) Encore une fois, voir OWASP.

  • utilisateurs menteurs / données altérées. Tamperdata est un bon moyen de se faire une idée de ce que les utilisateurs peuvent faire. D'autres outils pour mentir sont un proxy de réécriture comme Charles Web Debugging Proxy [3]. Vous vous en défendez en ne faisant jamais confiance aux données fournies par l'utilisateur. Faites des calculs sur le back-end. Si vous avez un bon calculateur d'expédition dynamique en javascript ou quelque chose du genre, c'est bien pour mettre à jour l'utilisateur, mais répétez le calcul sur le serveur au lieu de vous fier à la valeur de $ qu'ils ont trouvée.

Pour votre scénario de processeur de carte de crédit, c'est généralement une bonne idée car ils traitent de la sécurité et vous n'avez pas à vous soucier de stocker les numéros de carte. Ce que vous devez faire est de sécuriser les données qui leur sont envoyées. Vous pouvez le faire soit en

  • En parlant au processeur directement depuis votre serveur au lieu de rediriger l'utilisateur vers son site. A son propre ensemble de problèmes de confiance et de sécurité, vos utilisateurs doivent être prêts à vous donner leurs informations de carte de crédit et vous croire lorsque vous dites que vous ne le ferez pas. Obliger les utilisateurs à vous faire confiance pourrait réduire les ventes, cela ne vaut peut-être pas la peine, alors n'insistez pas nécessairement sur cette option.

  • Tenir à jour un catalogue de produits avec le processeur afin qu'il connaisse vos prix .

  • En signant les informations de prix que vous envoyez au processeur, vous ne pouvez pas les falsifier.

  • Vérification auprès du processeur une fois que le client a saisi ses données pour s'assurer qu'elles sont correctes.

Malheureusement, cela Il semble que les processeurs ne prennent pas en charge les catalogues de produits ou ne signent pas les prix. Par exemple, je ne le vois pas comme une option avec Paypal "Paiements sur site Web standard" [4]. La seule réponse dans ces cas est une étape de réconciliation post-traitement - vérifiez le montant que paypal dit que vous avez obtenu par rapport aux données de votre commande en indiquant le montant qui devrait être, et annulez toute commande où elle est erronée. C'est une mauvaise option car le besoin de recontacter l'utilisateur est coûteux et prend du temps, et vous vous retrouverez dans des disputes où les gens mentent et blâment votre système (et parfois ils ne mentent même pas - des bugs sont possibles.) / p>

Exemple de l'option 4, Paypal Express Checkout a une étape de vérification: vous êtes censé appeler directement 'GetExpressCheckoutDetails' avant 'DoExpressCheckoutPayment' pour faire une page de confirmation. [5] Je préconiserais donc quelque chose comme ça - l'utilisateur saisit les informations de paiement sur un site tiers, puis vous contactez le site directement depuis votre serveur et vérifiez les informations pour la page de confirmation de l'utilisateur.

Bien chance.

(En tant que nouvel utilisateur ici, je suis limité à 2 hyperliens.)

[1] Liste des 10 meilleurs OWASP: https: //www.owasp .org / index.php / Catégorie: OWASP_Top_Ten_Project

[2] Injection SQL Little Bobby Tables: xkcd.com/327/

[3] Charles rewrite proxy: www.charlesproxy.com/documentation/tools/rewrite/

[4] Variables Paypal 'Website Payments Standard', notez le manque d'options de signature: merchant.paypal.com/us/cgi-bin/?cmd = _render-content&content_ID = developer / e_howto_html_Appx_websitestandard_htmlvariables

Ensuite, regardez l'onglet "comment ça marche" et notez l'absence de "ils retournent sur votre site pour confirmation": merchant.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=merchant/wp_standard

[5] Paiement express Paypal (voir schéma où -votre serveur- parle directement à paypal pour obtenir des informations sur la page de confirmation): https://cms.paypal.com/us/cgi-bin/ ? cmd = _render-content&content_ID = developer / e_howto_api_WPECIntegration

[6] Page de Fiddler sur HTTPS: http://www.fiddler2.com/fiddler/help/httpsdecryption.asp

midnightmonster
2011-07-28 19:33:42 UTC
view on stackexchange narkive permalink

Oui, le fait que vous utilisez HTTPS fait tout la différence. La seule raison pour laquelle les informations vous semblent être du texte clair est que vous utilisez Tamper Data, une extension de navigateur qui vous permet de jouer avec vos propres données POST avant de les envoyer via HTTP (S). Personne d'autre que vous et la passerelle ne peut lire ces informations, ou du moins, ils ne le peuvent pas plus que sur n'importe quel autre site sécurisé dans le monde.

Le problème de la carte n'est vraiment pas une grosse affaire. C'est en fait une intégration assez intelligente avec une lacune.

Vous voyez, chaque fois que vous touchez des données de carte de crédit, vous devenez responsable d'un ensemble de choses de conformité PCI, même si vous ne stockez pas ces données. Il est encore courant dans cette industrie de mal gérer cela. Mais quelle que soit la passerelle de paiement qu'ils utilisent, vous pouvez garder le contrôle de l'expérience de paiement sans recevoir ni transmettre de données de carte - une excellente chose pour la conformité PCI. Le formulaire se trouve donc sur une page HTTPS sur le site du marchand, mais au lieu d'être publié sur l'application du marchand, il publie directement sur la passerelle. La passerelle communique l'état avec le marchand via une requête HTTP synchrone ou des données signées dans une URL de redirection, et le logiciel du marchand traite la transaction sans jamais voir les données de la carte.

C'est la bonne façon de le faire pour un site qui n'obtient pas un avantage convaincant de la construction de l'infrastructure nécessaire pour être conforme à la norme PCI. Ainsi, la conformité PCI ne nécessite que le trivial SAQ A. Le seul problème avec ceci est que soit la passerelle ne prend pas en charge (malheureusement, le cas le plus courant), soit le développeur n'a pas implémenté la signature des détails de la transaction du côté du commerçant.

Pour résoudre ce problème, votre développeur doit implémenter la signature des montants des transactions si votre passerelle le prend en charge, ou bien vous avez besoin d'un processus backend qui, chaque fois qu'il entend parler d'une nouvelle transaction, vérifie auprès de la passerelle pour s'assurer le bon montant a été payé et marque la commande si ce n'est pas le cas.

Mais notre application ne serait-elle pas vulnérable aux pirates informatiques utilisant un serveur proxy pour agir comme un intermédiaire entre le serveur et le client? Le proxy forcerait la connexion HTTPS à revenir au relais de niveau TCP qui transmet en texte clair. Dans mon esprit * c'est * la seule lacune. Bien que je comprenne théoriquement que cette attaque ** peut ** se produire, je ne comprends pas la logistique de ** comment ** cela se produit. Alors, est-ce notre implémentation qui est vulnérable aux serveurs proxy, ou est-ce qu'un serveur proxy rendrait même les sites conformes PCI vulnérables?
La connexion HTTPS n'enverra pas les données en texte brut. Mais vous pourriez avoir un proxy qui parle HTTPS. Donc je pense que je contacte foo.com, mais c'est vraiment evil.com. Ils ouvrent leur propre connexion HTTPS à foo.com avec mes données, puis me relaient la réponse de foo.com. Mais mon navigateur a une liste d'autorités de certification de confiance, et il ne me permettra pas de contacter evil.com-as-foo.com via HTTPS car le certificat SSL de evil.com n'est pas pour foo.com ou n'est pas fiable. Le scénario du proxy peut être pire avec la communication de serveur à serveur car les bibliothèques de programmation ne vérifient pas toujours les certificats valides, contrairement aux navigateurs.
Charlie B
2011-07-28 18:16:22 UTC
view on stackexchange narkive permalink

Les vulnérabilités que vous décrivez sont malheureusement courantes, mais heureusement faciles à corriger. Quant à votre question, non, l'envoi de données par en-tête n'est pas sécurisé. Pour ce faire en toute sécurité, voici ce que vous devez faire: 1) Générez une clé de cryptage sur votre serveur (public / privé) 2) lors du paiement, demandez à votre système (côté serveur) de valider les données que l'utilisateur a saisies par rapport aux bonnes valeurs connues, si possible 3) Demandez à votre serveur de générer une demande de publication au lieu des en-têtes. CC et CVV doivent absolument être cryptés, sinon vous n'êtes pas conforme à la norme PCI. A aucun moment aucune de ces données ne doit jamais être renvoyée au client.

En ce qui concerne les tests de sécurité, je peux également vous aider. J'exécute un service qui est très peu coûteux et je trouverai la majorité des problèmes comme ceux-ci, ainsi que vous aider à les résoudre. J'héberge également de nombreux articles sur la façon de coder en toute sécurité et de détecter les vulnérabilités de sécurité courantes.

Pour l'analyse Web - voir https://www.golemtechnologies.com pour des articles sur la sécurité, y compris comment corriger ce type de problèmes: https: //www.golemtechnologies .com / articles

Bonne chance! et n'hésitez pas à me contacter si vous souhaitez une aide spécifique.

timk
2011-07-28 20:21:34 UTC
view on stackexchange narkive permalink

Pas de honte dans le jeu de l'appli homebrew.

Pensez à ajouter un paramètre de signature cryptographique, comme un hachage HMAC, aux données que vous avez envoyées au client et que vous vous attendez à récupérer inchangé. Lors de la lecture des données, vérifiez le sig de hachage. Votre passerelle cc devrait également permettre à votre clé de cryptage d'acheter des paramètres tels que le prix d'une manière qui empêche la falsification.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...