Lut,
Je développe un site d'e-commerce en php (peut être pas le meilleur langage pour certain) pour mon stage de fin d'année (vente de bouquins), c'est un site sans prétention (heureusement) qui m'a permit de découvrir plein de choses.J'aurais 2, 3 questions a poser sur certains elements qui me tracassent.
 
Question sécurité:  
1/ Les failles susceptibles de m'apporter des ennuis se limitent elles a celles que j'ai pu voir dans "Sécurité PHP et Mysql", du genre attaque par injection, XSS ect ... ou y'a t'il des attaques que vous avez pu constater et qui ne figure pas dans les manuels.
2/ Les conseils pour déjouer ces attaques se limitent elles (encore une fois) a la "transformation" des chaines reçues (fonction htmlspecialchars(),mysql_real_escape_string()) ou y'a t'il d'autres méthodes?
3/ Lors de l'identification des potentiels clients, il me semble naturel de hacher leur mdp, dois je en plus ajouter d'autres choses ?
4/ L'administration du site se passe sur une page isolée, accessible aux utilisateurs administrateurs. Les log et pass sont vérifiés et en fonction de la validité, un champs dans la table des utilisateurs informe sur les droits de ces utilisateurs. Est ce que ce champs suffit ou faut il ajouter quelque chose?
5/ Faut il utiliser un accès sécurisé pour mon utilisateur qui s'identifie et/ou pour la gestion des produits/utilisateurs ou ce ne semble pas nécessaire?
 
Question d'ordre pratique:
J'ai pu voir lors de la création de mon panier que certains le font avec des sessions, j'aimerais votre avis sur la solution que j'ai copié sur une personne du forum (dsl le pseudo m'echappe):
Lors de l'arrivée du client sur la page boutique il reçoit un numéro de session généré aléatoirement (sans hachage)
celui ci navigue au grès de ses envies et, lorsqu'il ajoute un produit, une nouvelle entrée est créée en base avec son n° de session, les références du produits, la quantité, et un champs temporaire.
Dans un deuxième temps, lors de son arrivée sur le panier, il valide et la somme calculée de ce même panier entre en base et compléte les champs précédent (pour chaque n° de session du client est attribué un prix ttc + transport).
1/Pourrais je améliorer ce système.Repérez vous, dans l'énoncé du principe des failles/incohérences que je pourrais corriger?
2/ Je pourrais passer par des variables de session peut être?
3/ La centralisation* des pages vous semble t elle dangereuse ou il n'y'a pas de danger (je précise que je contrôle les valeurs passées)
*un index et des includes qui incluent les différentes pages identifiées.
4/ Est ce que la centralisation des traitements et dangereuse pour la sécurité du site: le formulaire de chaque page pointe vers une page de traitement qui teste les valeurs des noms des boutons d'envoi?
 
Question paiement:
1/ Un module de paiement est il ardu a mettre en place, j'ai pu voir des tutos et cela me laisse une impression mitigée.
2/ Est il vrai comme dit dans plusieurs sujets que j'ai pu voir que les informations sensibles, ne seront pas de mon ressort (n° de carte, cryptogramme, date de validité) ?
 
Question accessibilité:
J'utilise (et je découvre encore) l'acronyme AJAX, sur les pages de panier, de validation de commande, d'ajout/suppression d'articles, d'identification/inscription.
1/ Ce choix vous semble t'il juste?  
2/ Gagnerais je en accessibilité a enlever ce traitement par AJAX des certains modules et a garder un traitement PHP?
 
Question développement:
J'ai développer ce petit site sans utiliser les différents frameworks ou autres bibliothèques.
1/ Aurais je du mettre a profit le travail d'autres pour me faciliter la vie?
De même, les CMS's facilitent la vie des développeurs (pour ma part, osCommerce me semble incroyablement compliqué mais en le mettant en place et en découvrant, je vois plein de choses auxquelles je n'ai pas pensé et que je rajoute au fur et a mesure)
2/ Faut il penser en premier lieu a un CMS pour développer un site de ce genre?
 
Je pense que mon site ne mérite pas d'être mis en ligne vu le nombre de faille qu'il doit comporter, mon tuteur insiste pour le faire, je pense (et lui ait dit) que se serait a ses risques et périls.  
Comment argumenter pour lui mettre dans la tête qu'un étudiant ne devrais pas faire ce genre de choses?
Une dernière question, il me demande un estimation de mon site, il souhaite payer ce site (normalement stage rémunéré qui s'élève a 30% du SMIC par mois ~900€), a combien vendriez vous ce genre de site, sachant qu'il y'a derrière l'hébergement et les éventuels certificats SSL et la prestation de la banque ?
 
J'espère avoir été clair, je pose ses questions pour m'assurer que je ne commets aucune faute dans ma prestation, que lors de l'oral je puisse répondre a chacune des questions posées par le jury (qui malheureusement connaitra ce genre de site), et que ce site pourra me resservir dans le futur.
 
Merci d'avances pour vos réponses.
PS: codes dispo si besoin, a vous de juger

 
1/Ca depend, on connait pas tous les bouquins hein   Si le tiens est chez l'édition Eyrolles je le connais
En général celles qui sont oubliées ce sont pas les failles mais les trous de sécurité (brute force, DoS, etc...)
2/Encore une fois cela dépend du problème : pour une attaque brute force pas de solution que de la disuasion. Un sleep(3); par exemple peut suffir.
Il est aussi intéressant de rajouter des honey pots, des trucs comme çà quoi.
3/Là encore çà dépend, mais normalement le pass est haché partout (session, bdd)
4/Ce champs suffit
5/Si tu parles d'HTTPS, c'est nécessaire pour le paiement mais pour le reste... Pas vraiment. Le sniffing n'est pas une réelle menace. Dont le oui l'emporte.
 
 

 
1/Je serais toi j'aurais utilisé uniquement les sessions, qui peuvent contenir des tableaux, et être gérés plus rapidement. Bon çà n'a pas que des avantages, mais tu stocke l'id du produit qui est dans les bases et tu calcules tout dynamiquement sur le panier.
2/ j'espère que tu as compris que oui.
3/Je vois pas trop ce que je veux dire mais si tu parles d'une page qui inclue dynamiquement les fichiers nécessaires je vois pas l'intérêt.
4/Oui en contournant la méthode POST, pas de pb de sécurité risque de gros bug !
 
 

 
Je ne peux pas te répondre à ce sujet.
 

 
1/Non, et surtout à l'origine de problèmes de compatibilité. Faut toujours penser aux paranos utilisateurs qui désactivent javascript.
2/Oui.  
 
 

   
1/ Si tu poses la question t'en as pas besoin !
2/A toi de voir, mais si tu rajoutes-toi, alors t'en as pas besoin, mais si tu bloques, comme à l'envisager réellement. Question de besoins et de difficultés.
 
EDIT : tout çà vaut bien 5000€

Sache, pour une question de prix, que je me suis vue proposer des sites "familiaux", par des gens ayant pignon sur rue, avec quelques page, uniquement pour du partage de photos, sans l'hébergements ni le NDD, à 400€

 
Comment interpréter cette réponse, la rémunération de mon stage (~900€, confirmation aujourd'hui) suffit elle pour ce genre de site (apparemment non)?
 
Merci Lucas pour ces réponses, quelques précisions sur différents points  

Faut il que je traite sur une page l'envoi d'un formulaire, puis sur une autre l'envoi d'un deuxieme formulaire?
 
Merci encore pour vos réponses

 
Oui je pense.

 
Ok merci vais faire comme ça, concernant les sessions, quelles seraient les méthodes pour être sur qu'il 'y est pas de problème (vol d'id,ect)?
J'ai simplement mis en place un identifiant de session généré aléatoirement, je ne pense pas que cela soit suffisant, je recherche toujours une/plusieurs méthodes supplémentaires.

Si tu passes pas le SID par l'URL, alors méfie toi surtout des XSS.
Sinon, regarde du côté du session hijacking.  
Normalement c'est suffisant.

1/ mettre en place un module de paiement, ce n'est en soi pas hyper compliqué une fois qu'on a compris comment ça marche  (parce que les docs fournies par les banques sont assez mal faites)
2/ en effet, une fois que le client a choisi son type de carte de paiement, il est redirigé sur le site de la banque en https et la transaction se fait directement sur le site de la banque. Donc tu n'as absolument rien à voir avec les données de la carte bancaire. Après le paiement, le client est redirigé sur une page de ton site (et cela se configure dans les scripts fournis par la banque)

Pour ce qui est du hash je dirais que toute donnée sensible que tu n'as pas besoin de lire doit être hashée.
 
Et à fortiori hashée non pas avec un bête fonction de hash, mais avec une combinaison de ton cru (concaténation de fonctions de hash différentes, ajout de grains de sel...etc.).