Bonjour à tous,
 
Comme beaucoup, je me lance dans al création d'un site web. Ce site web est pour quelqu'un qui l’utilisera pour son site pro de vente en ligne. Il faut donc que je prenne tout un tas de précaution...
 
Supposons que le site soit fini, je l’hébergerais chez un hébergeur payant. Je pense donc ne pas stocker d'information bancaire (du moins pas toutes) dans ma BDD (je suppose que l’hébergeur pourrait y faire un tour ?) au risque d'irriter mes utilisateurs.
 
Bref, je n'y suis pas encore, j'en suis qu'à la création et j'ai très peur de faire une bourde et de créer une faille. J'ai fouiné un peu sur le net, je vais tenter de tout réunir ici et de poser quelques questions.
1) utiliser mysql_real_escape_string : je vois totalement la raison.
 
2) utiliser .htaccess pour protéger ses dossiers : Si on héberge sur sa propre machine, non ?
 
3) utiliser htmlentities : Sur mes $_GET ?
 
Et voici quelques questions :
EDIT : La fonction session_start permet de créer une session suivant l'adresse IP, c'est ça ? Du coup, c'est normale qu'en testant chez moi de me connecter avec un site web puis de me connecter sur un autre que j'ai créé, ça me log automatiquement ? Du coup, a/b et c ne sont plus utiles.
 
 
a) Je pensais créer une Session et je test : if(isset($_Session['user'])), sauf que, si un mec connait le mot "user" et un nom de compte, il peut d’approprié l'identité non ?
 
b) Je pensais donc prend un truc genre "o$^^*ùùjnoé"jo534Mbho" (exemple créé à l'instant ), est-ce suffisant ?
 
c) Dois-je tester si $_Session['o$^^*ùùjnoé"jo534Mbho'] est bien un utilisateur du site ? En supposant qu'il trouve le code il pourrait faire quoi avec cette variable (Autre que mettre le nom d'un utilisateur/ou son id) ?
 
d) Si a chaque implémentation de donnée dans ma BDD j'utilise le 1) et à chaque utilisation de donnée provenant d'autres page web j'utilise le 3), suis-je protéger d’utilisation illicite de mes pages ?
 
e) Je compte créer un compte admin avec comme identifiant Azeonh3fd02^ù* et comme mdp zaeibnéi&j"516, ce compte aurait accès à des pages comme Initialiser_La_Base_De_Donne ou Supprimer_Tel_Produit. Dois-je crypter le nom de ces pages ? Pour éviter qu'un utilisateur puisse retrouver ma page et faire quelque chose de mal ? Bien sûre je testerais si ma session est bien celle de l'admin, mais j'ai peur que cela ne soit pas suffisant.
 
 
Je ne m'y connais PAS DU TOUT en hacking, alors je ne sais pas de quoi sont capables ces gens .
 
Merci d'avances pour vos réponses, moi, je retourne coder .

mais pourquoi tu veux reinventer la roue  ? il existe dess choses pas mal comme prestashop , oscommerce,...
 
si c'est pour apprendre , ok, si c'est pour gagner ta vie, tu t'expose a de grosses deconvenue
1- non , utilise des prepared statement  
2- non
3 - non, sur tout ce que tu affiches qui n'est pas sur
a- non
b-erk
c

Bon alors, je ne connaissais pas prestashop et oscommerce, mais si tu tiens à savoir pourquoi je fais ça :
1) Bah déjà parce-que je ne connaissais pas ^^.
2) Ca me permet de m'exercer sur un vrai projet autre que les trucs de la FAC
 
Je ne compte absolument pas faire ma vie dans le web. Tu entends quoi par, des grosses déconvenues ?
 
Pour 1/2/3, je comprends pas trop, mon idée c'est ça :
1) utiliser mysql_real_escape_string, pourquoi utiliser les prepared statement plutôt que ça oO ?
2) utiliser .htaccess afin de protéger les dossiers dangereux.
3) utiliser htmlentities sur tout ce qui peut venir d'ailleurs.
 
Et sinon mes, a/b/c... découlent du fais que j'ai testé de faire une session_start depuis une autre page web, de me connecter au site, et vlan, j'étais co sur le site alors que je me suis log sur une autre page web.
EDIT : Je viens de trouver que session_start donne toujours le même id pour le navigateur ou un truc du genre ? Je vais continuer mes recherches.
 
Je ne tiens pas non plus à piquer du codes pré-fais. Je veux apprendre et comprendre, j'essaye de trouver des solutions et je vous en fais pars. Si vous n'avez pas le temps de répondre à toutes mes questions, même une ou deux explications sur un point en particulier peut m'aider.

 
Quand je lis ça, j'en déduis (peut-être à tord) que tu es débutant en développement d'applis web mais que le travail que tu es en train de réalisé sera mis en production par qq'un dont c'est peut-être le travail de faire de la vente.
 
A partir de là, le premier réflexe quand on doit développer un soft, c'est de voir s'il n'en existe pas un qui fait ce qu'on a besoin (ou au moins, un bon taux de couverture des besoins), en propriétaire (payant donc) ou en GPL (gratuit), démarche que tu n'as manifestement pas faite.
Pourquoi partir d'un soft existant? Gain de temps, plus de fonctions/modules/extensions, possibilité d'avoir du support pour l'utilisateur en cas de pbs (ou des corrections en cas de faille), si le produit existe depuis longtemps, il sera beaucoup plus sûr que ce que tu auras pu coder...
 
Si c'est juste pour apprendre, ok. Mais il est hors de question que tu mettes en production ton bousin, surtout pour une activité de e-commerce où la sécurité est primordiale pour que le client ait confiance et revienne. Et pour faire ça, il faut avoir de solides connaissances en dév web et c'est très difficile pour une personne seule d'y arriver.
Si déjà tu te poses ces questions de base pour une authentification sécurisée (au fait, comment comptes-tu stocker les mots de passe en base?), qu'est-ce que ça v être pour gérer le système de paiement (les différentes API fournies par les banques, ben oui, y'en a plusieurs, faut que ton ami puisse changer de banque et pas être liée à une seule juste parce que ton soft ne sait pas gérer les autres).
 
OsCommerce, c'est mort depuis 2005 il me semble (plus de dév) et très mal conçu. En GPL, les 2 meilleurs produits sont Prestashop et Magento (ma boutique de vaisselle jetable en B2B tourne sur Magento). En propriétaire, le plus connu est PowerBoutique.
 
Donc pour ton ami, s'il veut une boutique en ligne, il devra passer par l'un de ses produits (ou d'autres, ma liste n'étant pas exhaustive), mais certainement pas par ton soft...

.
 
Même si je me fais rembarrer, je suis très content de m'être donné ce projet :
-Ca m'expose mes limites
-J'apprends beaucoup de chose
 
Je sais développé des tas de trucs en php/mysql et blablabla, juste que n'ayant JAMAIS essayer de faire un projet, réel, on se se pose pas les bonnes questions. Je suis à la fac et, justement, je voulais faire ce projet pour évoluer par moi même. Et, justement, à la fac, on ne parle pas assez des problèmes de sécurités qu'on rencontre dans un projet réel. Youpi jsais développer blablabla, mais en faite, je ne sais absolument pas protéger mes pages...
 
Et si, au finale, je me retrouve avec un gros bousin "erk" et compagnie, j'aurais le recul de lui dire "Bon, laisse tomber, j'ai vraiment fais cque j'ai pu, mais tiens, utilise prestashop jvais t'aider". Je suis "noob", mais pas débile, je sais reconnaître mes erreurs. Vous êtes plus ou moins agressif (on va dire pas tendre ), parce-que je suis débutant dans la mise en place "réel" d'un site web et j'ai le culot de vouloir mettre en ligen quelque chose alors que je suis débutant ?
 
Vous avez peur, ou vous êtes certain, que mon truc soit de la merde en boîte ? Eh ben moi aussi. Et j'essaye de tout faire pour que, justement, cela ne le soit pas. Et si les compétences nécessaire sont hors de ma portée, tant pis, j'aurais tout de même appris beaucoup de chose.
 
Justement, je me posais aussi de grande question pour le stockage du mdp "au cas où" le serveur est attaqué. Alors je me suis demandé "Mais comment le serveur peut-être attaqué ?". Et là j'essaye de prévenir les attaques. Ensuite je m'attaque au cryptage des donnés mdp. J'ai lu des avis assez divergent, md5 est à proscrir/ou pas (mais je pense que oui). Et pareil pour crypt, et là je sais pas. J'ia vu d'autres trucs sur d'autres sites aussi, je ne me suis pas encore vraiment renseigné.
 
Je trouvais plus intéréssant de répondre à mes questions que de debuguer un programme. Mais il semblerait que je me sois tromper, trop de questions ? Trop vague ? J'ai l'air d'un benet avec trop d'espoir ?
 
Bref, malgré tout, vous m'aurez, vous aussi, appris des trucs. Merci quand même .
 
 

Désolé si je t'ai paru agressif mais ton premier post laissait fortement penser que ce que tu développais serait mis en prod et la piste d'utiliser un logiciel en GPL n'a pas été envisagée manifestement.
 
Si tu avais dit, bon, je fais un site web basé sur Prestashop/Magnto/Autre pour un ami et là, pour apprendre, j'ai eu envie de coder un tel système, tu n'aurais pas eu du tout les mêmes réponses (pas le même ton en tout cas). Tu serais surpris du nb de topics qu'on voit sur ce forum du genre, "coucou, j'y connais rien en php/mysql..., mais je veux coder un super site qui va manipuler de l'argent"...
 
Pour ta question du stockage du mdp en BD, y'a pas que le pb de l'attaque, y'a tout simplement le pb de la confidentialité. Pas envie qu'un dév ou admin d'un site connaisse mon mdp Perso, du hashage (donc pas réversible) est la solution que je préfère. Et c'est plus simple techniquement (pas besoin de se poser la question comment protéger la clé de cryptage ). Si md5 a été cassé, faut relativiser, c'est pas à la portée du premier venu de le casser. Mais dans le doute, suffit de prendre du sha-256 et zou, plus de pb.
 
Perso, comme j'avais pas forcément accès à du SSL, j'ai carrément fait en sorte que ça soit côté client (navigateur donc) que le hashage soit fait, comme ça, le pirate "in the middle" choppera juste le hash. Il pourra certes se logger mais connaîtra pas le mdp en clair. Et si côté client, Javascript est désactivé, ben comme c'est pas le formulaire dans lequel l'utilisateur saisit le login et mdp qui est envoyé, mais un autre, caché, qui fait le hashage et l'envoi via JS, ben pas de pb, le formulaire n'est pas envoyé en clair...

Pour faire rapide : la session est sur le serveur, donc quasiment inattaquable, à moins d'accéder en root au serveur ou de faire planter Apache en utilisant un hack non corrrigé par ta version d'Apache (genre le bug des multiple range).
 
Donc les sessions, relax, c'est safe. Si tu est parano, tu peux les mettre en mémoire plutôt que sur fichier, ça évitera à un éventuel attaquant de les pouvoir les lister (sauf avec un accès root, ou il les remet sur le disque dur). Pour ça tu peux utiliser l'extension php memcached, plus deux autres lignes dans ton php.ini (ca se trouve facilement sur le web). En plus mettre tes sessions en memcached rendra ton serveur plus réactif, tu auras moins de problèmes de verrouillage et tu pourras partager tes sessions sur plusieurs serveurs et donc faire du loadbalancing sans avoir à attribuer un cookie à ton client pour le faire revenir sur le même serveur (ce qui est clairement déconseillé par Google Page Speed). Que des avantages, donc.
 
Pour ce qui est de la sécurisation des mots de passe, pourquoi pas, mais franchement, il a été prouvé qu'une passphrase, autrement dit une séquence de caractères très longue et simple à retenir, avait plus d'efficacité qu'un mot de passe plus court et plus compliqué. Ce qui compte c'est de ne pas utiliser de mots du dictionnaire, et de maximiser la longueur de la chaîne de caractères (plus de bits à casser).
 
Pour les mots de passe de tes users, il faut utiliser soit un cryptage (obfuscation réversible) style AES/DES, soit un hash (obfuscation non réversible) style MD5/SHA256.
 
Le B.A.BA en sécurité en php, c'est de désactiver les register_globals, les magic_quotes, le allow_url_include, d'utiliser des requêtes échappées (mysql_real_escape_string, ou mieux, les requêtes préparées de PDO), de faire des inclusions de fichier uniquement en liste blanche et surtout de vérifier/typer toutes les données utilisateur (Never Trust The User Input).
 
Si tu respecte ces préceptes, ça devrait rouler.

Et surtout, toujours couplé avec un système de salage, pour éviter tout risque (dans le cas d'un MDP haché en MD5, ...).