osCommerce France : Accueil Forum Portail osCommerce France Réponses aux questions Foire aux contributions

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> osCommerce est-il sécurisé ?
Gnidhal
posté 4 Aug 2008, 20:39
Message #1


5eme dan OSC
Icône de groupe

Groupe : Administrateur
Messages : 9219
Inscrit : 4-March 03
Lieu : Auray
Membre no 927



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


--------------------
Tout d'abord : - Ni Hotline ni Service Après Vente, ces forums sont un lieu d'échange. BIEN POSER SA QUESTION (généralités)
Les "Informations Importantes" que vous devez ABSOLUMENT avoir lues :
Règlement, Bien poser sa question dans ces forums et Bien utiliser les Forums.
Les raccourcis pour gagner du temps : la FAQ, les PDF de la Doc (MS2-fr): PDF-V1 et PDF-V2, le moteur de Recherche sur les forums , la Liste des Contributions de Corbin.

----------------------------- Quelques sites de référence ---------------------------
PHP: Le site du Zéro et PHP Débutant avec la DOC en français -- HTML: Self HTML - WebProgrammation -- CSS: OpenWeb - AlsaCréations - CSS/Edge -- Autres ressources: - XajaX - highslide js
Les bons outils : EasyPHP - WAMP-5 - - Notepad++ - Firefox et son extension WebDeveloper
Le gène idéal c'est le gène original. Le génie des halles est un Génie des Alpages qui tente d'être à la page. (Merci f'murrr pour les cours de philosophie de chien)
Go to the top of the page
 
shoprun
posté 5 Aug 2008, 09:02
Message #2


2eme dan OSC
Icône de groupe

Groupe : Membres VIP
Messages : 3712
Inscrit : 11-April 07
Lieu : Ile de la Réunion
Membre no 16487



Salut Gnidal

Effectivement, cela va clore le débat -> il n'y a pas l'ombre d'une faille dans osC de nos jours ...

Merci d'avoir pris en considération ma demande par MP et d'y avoir créé ce sujet épinglé, et ce de la plus belle manière qui soit, on ne pouvais pas espérer mieux, excellent, comme d'hab ... wink.gif
Il y a pas de doute, ceci va en rassuré plus d'un, une telle synthèse manquait quelque part dans ce forum et sur ce sujet.


Ceci dit, cela ne répond totalement pas à la demande que j'avais effectuée, certes c'était peut être pas le bon moment ni le bon sujet pour le faire, mais bon que voulez vous, on fait c'qu'on peux huh.gif

Je vais faire donc cours, ceci évitera j'espère une mauvaise interprétation ...
Mon esprit de curiosité m'a amené à découvrir une solution différentes de celle de osC concernant les fichiers configurations (entre autre les infos de la BDD), en l'occurrence ZendFrameWork.

La technique est de placer ces fichiers non pas à l'intérieur du domaine (dans le www ou le htdocs) mais en amont, ou du moins au même niveau, ou on peu dire encore au niveau 0 (sais toujours pas comment dire autrement) de son espace.

OsCommerce prévois de placer le configure.php dans le www/includes/ en y ajoutant un .htaccess qui verrouille l'accès à l'ensemble des répertoires et fichiers à ce niveau. La sécurité y est donc physiquement présente.

Par contre, je remarque qu'il y a aucun .htaccess prévu au niveau 0, on peux estimer qu'il y a "anguille sous roche".
Mais il me semble avoir lu que ce niveau 0 est nativement plus sécurisé, plus verrouillé par rapport à tout ce qui ce trouve dans le www. (si rien n'est fait pour).

Donc question :
Est ce que ce niveau 0 est nativement plus sécurisé ?
Cette technique est elle réellement fiable ?
Apporte elle un plus au niveau sécurité ou est ce identique ou voir moins sécurisé ?

Je suis ouvert a toutes vos réponses et autres réflexions sur le sujet.
Merci par avance ... cool.gif

Ce message a été modifié par shoprun - 5 Aug 2008, 09:04.


--------------------
Nous ne sommes pas un Service Après-Vente ni une Hot-Line !!!, et pas de "UP" et de doublon svp ...
Prenez le temps de lire les informations mises à votre dispositions avant de créer un sujet.
Démarrer du bon pied -> Bien utiliser les forums | Bien poser sa question | Règles d'usage des forums
Prés-Requis -> Les compétences requises pour réussir avec osCommerce
Docs / Infos -> LA FAQ | Rechercher | Contributions | Contribution US
Sujets épinglés -> Manuel d'utilisation MS2 | Structure OsC2.2 MS2 | ms2-fr-rc1-w3c | SSL : une obligation? | Design de la MS2 | Tutoriels CSS | Optimisez les performances de votre boutique | Taux de TVA à appliquer
Utile -> WampServer | EasyPhp | Xampp | Mamp - Ftp -> FileZilla
Apprendre -> siteduzero | alsacreations | apprendre-php | developpez.com
Go to the top of the page
 
Rogers
posté 5 Aug 2008, 10:16
Message #3


Ceinture marron OSC
Icône de groupe

Groupe : Modérateurs
Messages : 1819
Inscrit : 14-March 03
Lieu : Beaune (21200)
Membre no 961



Gnidal a bien synthétisé les points sur la sécurité Oscommerce.

Honnêtement, si une faille de lecture simple sur le configure.php existait, elle serait la méthode privilégiée des pirates. Or, en 5 ans que j'utilise Osc, je n'ai jamais vu une telle méthode. J'ai vu quelques sites hackés, mais ça c'était dû à des contribs non sécurisées. Le configure.php est donc sécurisé au possible. Après libre à chacun de modifier le répertoire includes en le renommant (comme pour l'admin). Ce qui rajoute une sécurité supplémentaire. On peut même aller plus loin en changeant le nom du fichier configure.php.

Ce message a été modifié par Rogers - 5 Aug 2008, 10:17.


--------------------
The hardest thing in this world is to live in it.

Force jaune devant, marron derrière

J'ai touché le fond de la piscine
Dans ton petit pull marine...
Go to the top of the page
 
shoprun
posté 5 Aug 2008, 10:49
Message #4


2eme dan OSC
Icône de groupe

Groupe : Membres VIP
Messages : 3712
Inscrit : 11-April 07
Lieu : Ile de la Réunion
Membre no 16487



Citation
Gnidal a bien synthétisé les points sur la sécurité Oscommerce.

Oui, j'ai bien lu Rogers, et j'en doute pas, mais ma réflexion est de comparer 2 solutions différentes sans pour autant mettre en cause l'une ou l'autre.
Je ne souhaite pas être rassuré, ou sinon on va dire que Gnidal l'a déjà fait, ok, la question n'est pas là, mais c'est d'avoir un avis sur l'autre technique que j'ai pu découvrir, rien de plus ...

La question peu ce résumé encore plus simplement :
Peut on placer au niveau 0, des données sensibles ? (au tout début de notre espace d'hébergement)
Ce niveau 0 est il tout aussi sécurisé que ce qui ce trouve dans le www ?
ou plus ?
Ou moins ?
Mais aussi comparativement à ce qui est fait dans osC avec le configure.php + .htaccess ?

A savoir que l'on ne peux pas placer de .htaccess à ce niveau, sinon c'est l'ensemble de notre hébergement (le www) qui aura un accès trop restreint, cela va donc provoquer des problèmes d'accès aux fichiers et répertoires.

C'est la seule chose que je peux dire, mais le reste, j'en sais rien en faite, d'où cette question ...

Ce message a été modifié par shoprun - 5 Aug 2008, 10:56.


--------------------
Nous ne sommes pas un Service Après-Vente ni une Hot-Line !!!, et pas de "UP" et de doublon svp ...
Prenez le temps de lire les informations mises à votre dispositions avant de créer un sujet.
Démarrer du bon pied -> Bien utiliser les forums | Bien poser sa question | Règles d'usage des forums
Prés-Requis -> Les compétences requises pour réussir avec osCommerce
Docs / Infos -> LA FAQ | Rechercher | Contributions | Contribution US
Sujets épinglés -> Manuel d'utilisation MS2 | Structure OsC2.2 MS2 | ms2-fr-rc1-w3c | SSL : une obligation? | Design de la MS2 | Tutoriels CSS | Optimisez les performances de votre boutique | Taux de TVA à appliquer
Utile -> WampServer | EasyPhp | Xampp | Mamp - Ftp -> FileZilla
Apprendre -> siteduzero | alsacreations | apprendre-php | developpez.com
Go to the top of the page
 
Gnidhal
posté 5 Aug 2008, 12:27
Message #5


5eme dan OSC
Icône de groupe

Groupe : Administrateur
Messages : 9219
Inscrit : 4-March 03
Lieu : Auray
Membre no 927



Ok Shoprun,
sur ta config d'hébergement tu as en ftp une vision de ce genre:
Code
/
     cgi-bin
     www
     logs

www est donc un sous dossier de / au même titre que logs et cgi-bin

l'accès web (le nom de domaine) pointe sur le dossier www. Donc via http (l'accès externe) on ne peut pas remonter au dessus de www.
En revanche, les scripts peuvent pointer dans ces dossier via le chemin absolu de type Files
exemple le chemin absolu de ton dossier www est root/tonhebergement/www/ et celui de cgi-bin est root/tonhebergement/cgi-bin/
pour activer un script perl placé dans cgi-bin tu passeras par le chemin absolu root/tonhebergement/cgi-bin/ton_script.pl ou par le chemin relatif depuis www qui est ../cgi-bin/ton_script.pl
Apache gère les droits d'accès à ces sous dossiers généralement par une configuration spécifique mise en place par l'hébergeur que tu peux modifier soit par une modification CHMOD soit par un .htaccess (si l'hébergeur l'a autorisé).
tu peux donc placer le fichier configure.php dans ../cgi-bin/ et l'appeler de la même manière.
Mais la sécurité n'est pas supérieure à celle du .htaccess placé dans www/includes/.

Par ailleurs, tous les hébergements mutualisés ne proposent pas cette architecture. Dans certains cas, le FTP ne donne accès qu'au répertoire www. Donc impossible de remonter d'un niveau.
Dans sa version originale osCommerce est compatible avec tous les types d'hébergement mutualisés puisque on a toujours accès au moins à www via le FTP.

petite explication complémentaire, tu pourrais même te payer le luxe de mettre ton fichier configure.php à la racine de www (oui directement dans www) qui est pourtant accessible publiquement sans aucun risque à condition que tu ajoutes dans le .htaccess de la racine les lignes suivantes :
Code
<Files configure.php>
Order Deny,Allow
Deny from all
</Files>

Le fichier configure.php serait alors totalement interdit à tout autre accès que le système lui-même.
puisqu'il vient en include dans les autres scripts et que ce qu'il contient ne nécessite aucun affichage direct vers le navigateur ça fonctionnera.




--------------------
Tout d'abord : - Ni Hotline ni Service Après Vente, ces forums sont un lieu d'échange. BIEN POSER SA QUESTION (généralités)
Les "Informations Importantes" que vous devez ABSOLUMENT avoir lues :
Règlement, Bien poser sa question dans ces forums et Bien utiliser les Forums.
Les raccourcis pour gagner du temps : la FAQ, les PDF de la Doc (MS2-fr): PDF-V1 et PDF-V2, le moteur de Recherche sur les forums , la Liste des Contributions de Corbin.

----------------------------- Quelques sites de référence ---------------------------
PHP: Le site du Zéro et PHP Débutant avec la DOC en français -- HTML: Self HTML - WebProgrammation -- CSS: OpenWeb - AlsaCréations - CSS/Edge -- Autres ressources: - XajaX - highslide js
Les bons outils : EasyPHP - WAMP-5 - - Notepad++ - Firefox et son extension WebDeveloper
Le gène idéal c'est le gène original. Le génie des halles est un Génie des Alpages qui tente d'être à la page. (Merci f'murrr pour les cours de philosophie de chien)
Go to the top of the page
 
Rogers
posté 5 Aug 2008, 13:39
Message #6


Ceinture marron OSC
Icône de groupe

Groupe : Modérateurs
Messages : 1819
Inscrit : 14-March 03
Lieu : Beaune (21200)
Membre no 961



Oui mais je ne vois pas en quoi le niveau 0 serait plus sécurisé que le répertoire web. Etant donné que le mec qui a accès au répertoire www peut accéder à tout le serveur, je ne suis pas persuadé de la légitimité du niveau 0. Et vu que le sujet était sécuriser le configure.php en le mettant au niveau 0, je ne vois pas en quoi c'est mieux. C'est certainement une barrière supplémentaire, mais ce n'est pas une fin en soit.


--------------------
The hardest thing in this world is to live in it.

Force jaune devant, marron derrière

J'ai touché le fond de la piscine
Dans ton petit pull marine...
Go to the top of the page
 
shoprun
posté 5 Aug 2008, 13:46
Message #7


2eme dan OSC
Icône de groupe

Groupe : Membres VIP
Messages : 3712
Inscrit : 11-April 07
Lieu : Ile de la Réunion
Membre no 16487



Excellent, rien a dire, vraiment blush.gif

Et oui, Apache permet de verrouiller un fichier en particulier, et pas uniquement un répertoire ... Ok ... je découvre ...

Et c'est bien ça aussi, mon hébergeur me permets d'y placer autant de fichiers ou répertoires au même niveau que le www (sous domaine, cgi-bin, perso, etc ...)
Donc si on souhaite placer des fichiers ailleurs que dans notre domaine (www) il faut donc aussi s'en préoccuper et y placer des .htaccess, arfff ... La grosse boulette que j'allais faire mrgreen.gif

Ton intervention et très clair, répond parfaitement à mes énigmes, j'avais de gros pré-jugés, c'est clair ...

En faite, je vais enlever un mystère, car j'ai un second projet, ce sera un sous domaine, un genre de blog, et lui, aura accès a la même BDD, donc configuration identiques, sans compter que je compte bien optimiser mon code pour y créer petit à petit des classes ou fonctions communes aux 2 projets.
-> Un seul et même code pour les 2, et encore, on peut dire pour les 3 vu que osC est divisée en 2 (catalog/admin), et même 4 car ce blog aura aussi une partie public / admin.

C'est cela dont Zend FrameWork utilise comme solution et j'y est vu là une manière on ne peux plus judicieuse ...
Mais le coté "sécurité" restait sans réponse, c'est chose faite ...

Y a plus qu'à comme dirait l'autre ...

Merci encore pour ton aide éclairé ... wink.gif

[edit]
@Rogers
Citation
je ne vois pas en quoi c'est mieux. C'est certainement une barrière supplémentaire, mais ce n'est pas une fin en soit

Pour ma part si, car à chaud comme ça, j'ai pas poser tout mon projet, car c'est encore un projet, mais déjà je me dis que je peux créer un répertoire config au même niveau que le www, et dans celui ci j'y mets un fichier genre bdd.php avec les paramètres de connexions qui seront communs à tous les projets.
Idem, je pense créer un répertoire classes en y mettant toutes les classes dont j'aurais besoins.
Suffit donc de faire pointer, inclure les classes vers ce répertoire des différents projet, j'ai déjà fais un essai, ça marche impeccable, mais il faut y mettre un .htaccess, c'est cela dont j'avais cru inutile ...

Cette solution change tout, un seul code commun -> Maintenance largement plus facile, sérieux, des codes dupliqués entre le catalog et l'admin j'en ai pleins, il y en aura de plus en plus. Je fais une modif dans l'un, je l'oubli de le faire dans l'autre et voilà que ça marche plus, bug ... ça commence à m'arriver de plus en plus, ça devient pénible ...
Il y a pas photo, c'est largement mieux ...
Sans compter que c'est très simple à faire, juste déplacer les classes, et de les faire un set_include_path() en indiquant le répertoire commun, ça prends 5 minutes ...
[/edit]

Ce message a été modifié par shoprun - 5 Aug 2008, 14:14.


--------------------
Nous ne sommes pas un Service Après-Vente ni une Hot-Line !!!, et pas de "UP" et de doublon svp ...
Prenez le temps de lire les informations mises à votre dispositions avant de créer un sujet.
Démarrer du bon pied -> Bien utiliser les forums | Bien poser sa question | Règles d'usage des forums
Prés-Requis -> Les compétences requises pour réussir avec osCommerce
Docs / Infos -> LA FAQ | Rechercher | Contributions | Contribution US
Sujets épinglés -> Manuel d'utilisation MS2 | Structure OsC2.2 MS2 | ms2-fr-rc1-w3c | SSL : une obligation? | Design de la MS2 | Tutoriels CSS | Optimisez les performances de votre boutique | Taux de TVA à appliquer
Utile -> WampServer | EasyPhp | Xampp | Mamp - Ftp -> FileZilla
Apprendre -> siteduzero | alsacreations | apprendre-php | developpez.com
Go to the top of the page
 
Gnidhal
posté 5 Aug 2008, 14:24
Message #8


5eme dan OSC
Icône de groupe

Groupe : Administrateur
Messages : 9219
Inscrit : 4-March 03
Lieu : Auray
Membre no 927



@ rogers :
l'accès publique au site se fait via le nom de domaine ou l'adresse IP web.
Si le nom de domaine pointe vers www, il est impossible de remonter via le nom de domaine vers un dossier parent de www ou sur un niveau parallèle.
En revanche, un script peut accéder à ces chemins via un chemin relatif ou absolu (on est en chemin physique et non en chemin web)
S'il n'y a aucune protection, je peux lister les sous-dossiers de www (comme includes/) depuis un navigateur. Mais je ne peux pas lister un dossier parent (ou frère) de www.
Hors ici le cas ne se pose pas. On part du principe que la sécurité minimum Apache est activée et que les sous-dossiers de www ne peuvent être listés. En ajoutant la syntaxe convenable dans un .htaccess on peut verrouiller un fichier, un lot de fichiers (avec des jokers) ou un répertoire etc.
La question de Shoprun était (pour résumer) la sécurité est elle meilleure dans un chemin inaccessible depuis le web. La réponse (en résumé) est : pas forcément, c'est un autre procédé qui n'exclut pas d'utiliser la sécurité d'un .htaccess.


--------------------
Tout d'abord : - Ni Hotline ni Service Après Vente, ces forums sont un lieu d'échange. BIEN POSER SA QUESTION (généralités)
Les "Informations Importantes" que vous devez ABSOLUMENT avoir lues :
Règlement, Bien poser sa question dans ces forums et Bien utiliser les Forums.
Les raccourcis pour gagner du temps : la FAQ, les PDF de la Doc (MS2-fr): PDF-V1 et PDF-V2, le moteur de Recherche sur les forums , la Liste des Contributions de Corbin.

----------------------------- Quelques sites de référence ---------------------------
PHP: Le site du Zéro et PHP Débutant avec la DOC en français -- HTML: Self HTML - WebProgrammation -- CSS: OpenWeb - AlsaCréations - CSS/Edge -- Autres ressources: - XajaX - highslide js
Les bons outils : EasyPHP - WAMP-5 - - Notepad++ - Firefox et son extension WebDeveloper
Le gène idéal c'est le gène original. Le génie des halles est un Génie des Alpages qui tente d'être à la page. (Merci f'murrr pour les cours de philosophie de chien)
Go to the top of the page
 
Rogers
posté 5 Aug 2008, 15:09
Message #9


Ceinture marron OSC
Icône de groupe

Groupe : Modérateurs
Messages : 1819
Inscrit : 14-March 03
Lieu : Beaune (21200)
Membre no 961



Dommage que je n'ai plus les scripts (mon antivirus me les a dégagé) que j'ai vu dans les répertoires images de 2 sites Oscommerce, mais je peux te dire que tu pouvais faire beaucoup de chose (je les avais vite testé à l'époque). Codés en perl si je me souviens bien.

Citation
La question de Shoprun était (pour résumer) la sécurité est elle meilleure dans un chemin inaccessible depuis le web. La réponse (en résumé) est : pas forcément, c'est un autre procédé qui n'exclut pas d'utiliser la sécurité d'un .htaccess.


Là-dessus on est entièrement d'accord.


--------------------
The hardest thing in this world is to live in it.

Force jaune devant, marron derrière

J'ai touché le fond de la piscine
Dans ton petit pull marine...
Go to the top of the page
 

Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



RSS Version bas débit Nous sommes le : 18th November 2017 - 07:32
Ce site est déclaré auprès de la commision Nationale
de l'Informatique et des Libertés (déclaration n°: 1043896)