Aide - Recherche - Membres - Calendrier
Version complète : Erreur sur submit avec formulaire de contact (R 2.3.1)
Forum osCommerce-fr > Oscommerce 2.3 > Contributions OsC2.3
Jimmy2731
Salut,

Depuis une semaine les formulaires de contact de mes sites (contact_us.php) me renvoient l'erreur suivante :

"Un formulaire de contact vient d'être envoyé. Veuillez réessayer dans 15 minutes".

Les différents sites concernés par ce message d'erreur :

1/ sont chez des hébergeurs différents
2/ n'ont pas fait l'objet d'une installation de contribution iden tique (qui aurait pu être à l'origine de ce message)

Y aurait-il un lien avec une limitation côté serveur de messagerie de l'hébergeur? Une limitation que je n'aurais pas vu dans l'admin?

Par avance merci de votre avis.
chti_poupon
Bonjour
Sans doute un espion !! ninja.gif
MS2.3 prévoit un agrément du contact et tu as reçu le message standard: ERROR_ACTION_RECORDER de la ligne 36
Ch'tite lecture instructive sur cuntact_us.php ... entr'autres happy.gif
Chti poupon
Citation (Gnidhal @ 4 Aug 2008, 20:39) *
Suite aux délires d'un petit malin qui vient nous apprendre qu'osC est plein de trous de sécurité, je réagis.
- Cette affirmation est un TROLL

Quelles sont les failles potentielles connues d'osCommerce ?
- L'accès administration non protégé (la démarche de sécurisation est données dans la FAQ et la RC1 inclut maintenant une sécurité via cookie de session, mais la méthode présentée dans la FAQ d'utilisation du htaccess reste indispensable)
- L'utilisation d'éditeurs html dans la partie publique (FCKeditor ou HtmlArea ont des failles de sécurité) par exemple dans la page contact_us.php lors de l'installation d certaines contributions. Oui, la littérature là dessus est connue, faites une recherche sur ces forums. Ne placez ces outils avancés de formulaire HTML que si vous avez la compétence pour le faire. Et s'il y a faille elle n'est pas dans osCommerce de base, mais bien dans une installation douteuse d'un ajout.
- Faire apparaitre tous les prix à zéro. Moui, c'est une vraie faille pour un site de téléchargement par exemple. Mais la solution est donnée dans la FAQ. Au passage un commerçant qui livre une commande dont le total ne correspond pas à ce qui a été acheté est idiot. Cette faille n'existe plus sur les versions récentes (plus de 2 ans) en téléchargement.
- Obtenir la livraison gratuite dans tous les cas. Là encore, la parade est dans la FAQ mais à moins d'être dans la lune, on ne livre pas une commande dont le port est à zéro sans vraie raison. En cas de besoin, On va consulter les logs Apache de son hébergement et on confond le fraudeur en le menaçant d'une plainte car cette manip pour avoir le port gratuit n'est pas des plus évidentes à réaliser. Elle peut donc facilement être repérée pour prouver la volonté de fraude du client. Et quand bien même, elle ne met pas en péril un commerce et ne peut marcher que si on fait le port gratuit à partir d'un certain montant.

Il n'en existe pas d'autres connues à ce jour (à moins que j'en oublie une grosse mais je ne vois pas)

Autres questions soulevées par le trolleur :
Peut-on lire le fichier configure.php (afficher le contenu) d'un site qui contient les informations de connexion à la BDD ?
Non
pour deux raisons : la première est qu'un fichier php est considéré comme un fichier exécutable par le serveur. Donc ce qui s'affiche au pire est ce que ce fichier est sensé faire (le résultat de l'exécution du code qu'il contient). Alors si le parseur (moteur) PHP du serveur est en panne on peut éventuellement lire le contenu des fichiers de la racine du site qui ne s'exécuteront plus. Mais pas ceux qui sont contenus dans le dossier includes et ses sous-dossiers, car de base ce dossier est protégé par une sécurité Apache .htaccess ce qui est la deuxième raison de base.

Et quand bien même... une fois que j'ai réussi à récupérer les accès BDD cela me donne-t-il accès au contenu de la BDD ? Chez un hébergeur qui fait bien son boulot non. Pour adresser le serveur sql qui va comprendre ces infos il faut :
- soit que la BDD soit accessible de l'extérieur via le port 3306 (formellement déconseillé et généralement désactivé sur un hébergement mutualisé) auquel cas je peux accéder au contenu de la bdd depuis un applicatif local
- soit que j'ai réussi à envoyer un script exécutable sur le site dans lequel j'ai placé mon propre code. Et là, c'est carrément que le site est ouvert à tout le monde en écriture. Donc chez un mutualisé il faut faire un procès à l'hébergeur ou à soi même si on a laissé trainé ses codes d'accès à tous vents, et sur un dédié, faire rapidement passer un professionnel pour mettre les bonnes sécurités qui s'imposent.

Bon et puis après, le hacker a réussi toutes les épreuve et peut lister la base de données, voire la modifier (je crois qu'il a plus de chance de gagner 3 fois le gros lot du loto dans le même mois). Quels sont les risques ?
- d'accéder aux données commerciales du site
- de casser le site : catalogue HS = plus de site
- d'avoir les mots de passe client : pas facile les mots de passe sont cryptés par MD5 avec une clé salt (explications plus bas) mais et alors? cela présente un risque quasi inexistant.

Dans ce cas quelle est la solution ?
1/ mettre le site en stand-bye (page d'accueil provisoire) non active
2/ consulter les logs Apache pour identifier la méthode utilisée et donc localiser la faille
3/ avertir l'hébergeur et éventuellement engager des poursuites à l'encontre du pirate
4/ Réparer cette faille
5/ effacer tous les fichiers en ligne et réinstaller le site en entier (scripts et BDD) depuis la dernière sauvegarde saine (avant l'incident) en prenant soin d'appliquer le point 4
cette dernière étape permet d'éliminer d'éventuels scripts laissés par le pirate qui continueraient à lui donner un accès privilégié

Un mot de passe MD5 c'est quoi ?
Le procédé utilisé pour crypter les mots de passe est à sens unique et n'a pas de fonction de décryptage. On fonctionne donc par comparaison : si le mot de passe saisi, une fois crypté avec la même clé salt (2 caractères au hasard qui sont enregistrés à la fin de la chaine crypté) donne le même résultat que la chaine cryptée enregistrée en BDD, c'est que c'est le même. Cette clé "salt" impose un caractère totalement aléatoire du cryptage interdisant par exemple la comparaison de chaîne cryptées pour créer un dictionnaire de décryptage.
Les décrypteurs procèdent donc comme ça : on passe tous les mots de passe possible dans le crypteur et on compare avec la chaine stockée en BDD. Avec un gros ordinateur, un mot de passe peut se décrypter en 10 secondes, en 10 heures ou en 10 jours selon la complexité du mot de passe original.
Afin de se rappeler leur mot de passe, les utilisateurs ont généralement un mot de passe simple : une date de naissance, un prénom, le nom du chien...
Il suffit donc d'utiliser un dictionnaire et de passer tous les mots qu'il contient à la comparaison pour se faciliter le travail. On peut alors "casser" assez rapidement près de la moitié des mots de passe d'une base de données.
Donc si vous utilisez un mot de passe trop simple vous pouvez le compliquer juste un peu, le simple fait d'ajouter un chiffre et une majuscule complique énormément la tache du hacker (ou de son ordinateur) exemple mon mot de passe est "jeannette" (ou "Jeannette") : résistance environ 30 secondes avec un bon ordinateur et "jeAnnette65" résistera plus de 4 heures, après c'est affaire de chance dans le séquenceur du script du pirate.


Le X-scripting ou cross scripting c'est quoi ?
C'est une méthode qui utilise le passage de variables entre les pages pour essayer d'introduire un bout de script dont l'autre partie active sera située sur un autre serveur (celui du hacker). osCommerce n'a aucune faille connue de ce type (il en avait, mais les versions récentes depuis 2 ans sont résistantes à ce genre d'attaque)
Le sql-injection c'est quoi ?
une autre méthode utilisée pour pirater un site mais cette fois on essaye de passer des ordres vers la base de données dans les paramètres entre les pages. Là aussi, osCommerce est parfaitement résistant à cette épreuve et n'offre pas de faille.

Quelles sont autres les failles potentielles ?
toutes les pages ou on saisit des informations dans un formulaire : la page d'enregistrement, la page contact_us par exemple peuvent être considérées par les pirates comme des points faibles.
Rassurez-vous ces pages sont blindées depuis au moins 3 versions. Toutefois les hackers utilisent des robots (ordinateurs avec un script) pour tester une faille. Il n'en trouveront pas mais pourront squatter la page contact_us pendant des heures à la recherche d'un passage. Vous allez recevoir des mails bizarre via le contact de la boutique et cela occupe inutilement le serveur.
La parade dans ce cas est d'ajouter sur ces pages un Captcha (il existe des contributions pour ça) Le robot sera dérouté et ne pourra pas passer la page à la moulinette car il ne pourra pas déchiffrer le code à saisir pour valider son formulaire. Il ira voir ailleurs.

Peut-on pirater un site osCommerce ?
Bien sûr ! Certains hackers arrivent bien à pénétrer des systèmes bancaires ou même l'ordinateur du Pentagone dont les sécurités ont pourtant été réalisées par des experts.
Prétendre qu'un site Internet est inviolable est tout aussi vrai que prétendre qu'une voiture est inviolable. Et ça reste vrai tant que personne n'a prouvé le contraire.
Après c'est une question de moyens et de temps. Il n'existe pas de système inviolable mais des systèmes résistants à toutes les attaques connues.
Cela dit, si je peux comprendre l'intérêt que peut avoir un pirate de pénétrer le site de la CIA ou celui d'une grande banque, je n'arrive pas à placer une boutique Internet sur le même plan. Elle n'a pas de stock, pas de liquidité, pas de données sensibles...

Voilà, j'ai essayé de faire simple mais le plus exhaustif.

en résumé : osCommerce dans sa version de base actuelle validée (en fr ou en original téléchargeable ici ou sur oscommerce.com) ne présente pas de faille de sécurité.

Je laisse ce post ouvert pour tous vos commentaires. Mais je serai intraitable sur la déviation en troll. Alors mâchez bien vos mots avant de répondre et faite dans le court.
Merci smile.gif
Jimmy2731
Salut Chti poupon,

Piraté ou pas? la est la question!

Concernant le contact_us.php , j'y ai intégré un captcha depuis le début..et aucun problème.

Pour ce qui est de la sécurité via les chmod, j'ai scrupuleusement suivi les recomandation côté admin ("Sécurité des répertoires").

Disons que ce message d'erreur arrive environ 1 fois sur 3 fomulaires envoyés!

J'ai regardé un peu en détail et il semblerait que ce soit le fichier "ar_contact_us.php" qui soit à l'origine du message d'erreur! Peut être un problème dans ma conf côté admin!

Une chtite idée?
Jimmy2731
Un espion! Ce serait genre un fichier au milieu des autres sur le serveur de mon hébergeur. Ou un bout de code glissé dans un de mes fichiers.

Il me reste plus qu'à supprimer sur le serveur et réinjecter un backup que je suppose sain!

Tu parlais d'agrément pour les contacts! Que veux-tu dire?

Merci pour la piste. ^_^
Jimmy2731
Salut,

En modifiant la valeur du champ "nous conacter" dans l'admin (Modules/Traceurs sécurité) j'ai pu lever la limitation d'1 envoi toutes les 15 minutes.

Jimmy
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez cliquer ici.
Invision Power Board © 2001-2014 Invision Power Services, Inc.