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