Profil supprimé | redspiegel a écrit :
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?
|
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.
redspiegel a écrit :
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?
|
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 !
redspiegel a écrit :
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é) ?
|
Je ne peux pas te répondre à ce sujet.
redspiegel a écrit :
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?
|
1/Non, et surtout à l'origine de problèmes de compatibilité. Faut toujours penser aux paranos utilisateurs qui désactivent javascript.
2/Oui.
redspiegel a écrit :
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?
|
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€ Message édité par Profil supprimé le 16-07-2008 à 13:26:14
|