Discussion :

[ABCIWEB]

Dans ma citation c'est le mot "pratique" qu'il faut retenir et ça tu le constateras à l'usage. Mais bon si tu peux appliquer la solution de RunCodePhp facilement dans tous les cas c'est à priori encore mieux qu'un .htaccess donc ne t'en prive pas.

Concernant le fait d'éviter de mettre ses identifiants de connexion bdd dans tous ses scripts php pour ne les concentrer que dans un seul fichier, bah c'est le minimum du bon sens, non ?
Faut pas négliger "le bon sens" quand on parle de sécurité (informatique ou autre). Sinon en te croyant peut-être protégé des génies de l'informatique par des fonctions savantes, tu pourrais par exemple tout aussi bien te faire pirater par le premier quidam venu qui regarderait par dessus ton épaule pendant que tu travaille sur un script... C'est juste un exemple pour dire que d'une manière générale on évite de multiplier l'affichage des informations confidentielles

[redoran]

salut ; ABCIWEB
sachant que le site débute par un index.php et le sous répertoire contenant le fichier con.inc.php contenant lui aussi le nom de la BDD et le mot de passe.
Comment le haker peut atteindre ou naviqué entre les répertoires ?
Est ce que il utilise son propre navigateur ou il met main sur celui du client ?

[RunCodePhp]

salut ; @ RunCodePhp : ça fait un bail

Tu l'as dit
C'est la faute à pas assez de temps

sachant que le site débute par un index.php et le sous répertoire contenant le fichier con.inc.php contenant lui aussi le nom de la BDD et le mot de passe.
Comment le haker peut atteindre ou naviqué entre les répertoires ?
Est ce que il utilise son propre navigateur ou il met main sur celui du client ?

Par moment j'estime qu'il faut éviter de se poser trop de questions, même si elles sont intéressantes, importantes.

J'estime aussi que ce n'est pas vraiment le boulot du développeur Web de savoir en détail comment les pirates font pour pirater les sites en question, je dirais que l'essentiel c'est déjà savoir quelles sont les techniques permettant de s'en prémunir, car c'est déjà assez complexe comme ça.

Après ça, je pense que beaucoup dépend des risques, et ces risques sont selon moi en rapport de la notoriété du site Web, et des enjeux.
C'est ces 2 points (les plus importants à mon sens) qui vont amener à prendre plus ou moins cet aspect sécurité au sérieux.

Tu imagines bien que les mesures à prendre coté sécurité pour un site 100% perso et d'un Facebook seront radicalement pas les mêmes.

c'est ce que j'ai fait et les autres fichiers sont dans des sous repertoires exemple : SR-conx , SR-css , SR-JS.....

L'arborescence que tu as mis ne démontre pas si ces fichiers de config sensibles sont placés dans le vhost ou en-dehors.
Qu'ils soient placés dans le vhost mais dans des sous-répertoires fait qu'ils sont toujours dans le vhost.
Et bien par définition (ou par défaut) ils peuvent être atteints via une URL, on ne peu pas le contester, bien qu'Apache permet de gérer cela via des fichiers .htaccess.


Par ailleurs, un autre point pour quelque par renforcer cette idée (plutôt de concept car cela relève de la manière de concevoir un site Web) de mettre absolument toute l'application en-dehors du vhost.
Je vais tout simplement donner un exemple de ce que mon hébergeur habituel me permet de faire (formule mutualisée je précise, donc même pas un dédié).

Et bien il me donne au départ un couple login/passe pour l'accès FTP, celui-ci on peu le considérer comme le super-admin car il donne le droit de tout faire sur l'espace disque alloué.
Donc de créer/supprimer autant de répertoires et sous-répertoires, et de définir autant de vhost que je veux (tout est configurable via une interface administrateur).

Du coup, il me permet de créer plusieurs autres utilisateurs avec des couples login/pass FTP mais ils auront des droits moins importants, mais surtout, de les lier à un vhost en particulier, donc de les lier à 1 répertoire.
Imaginons l'exemple suivant :
./espacedisque/appli_www (les classes correspondant au site www, domaine.com)
./espacedisque/appli_www2 (les classes correspondant au site www2, autresite.com)
./espacedisque/systeme (Le Core du FrameWork, générique aux différents site Web (ou vhost : domaine.com et autresite.com))

./espacedisque/www (le vhost lié à domaine.com)
./espacedisque/www/index.php (le FrontColler du vhost de domaine.com)

./espacedisque/www2 (le vhost lié à autresite.com)
./espacedisque/www2/index.php (le FrontColler du vhost autresite.com)


Et bien je peux créer un nouvel utilisateur pour un accès FTP lié au domaine domaine.com, donc du répertoire "www", ce qui fait qu'il pourra faire des opérations uniquement dans ce répertoire.
Donc en aucun cas il verra les répertoires appli_www, appli_www2, systeme et www2.
Très pratique pour par exemple donner accès à un graphiste, car dans le "www", à part le index.php, on mettra tout de même d'autres fichiers qu'on souhaite accessible via l'URL du domaine, comme les JS, Css, les images, vidéos, etc ...
Donc tout ce dont un graphiste à besoin (en aucun cas le graphiste aurait des droits de toucher au coeur du FrameWork, encore moins visualiser les différents mots de passes de l'application).

Ceci est en 1er un énorme confort, c'est même hyper important du coté de la sécurité.

En cherchant encore, on doit pouvoir trouver d'autres avantages sur cette façon de concevoir un site Web.

D'ailleurs, un autre avantage, et on le perçoit dans l'exemple d'arborescence que j'ai mis ci-dessus, c'est de pouvoir exploiter le même FrameWork (systeme) pour plusieurs sites Web différents.


Je précise que cela n'est pas de mon invention, mais ces conseils je les aient lu dans la doc des quelques FrameWork et CMS que j'ai pu utiliser ou juste parcouru.

le seul outils que j'utilise c'est le NOTEPAD++ ( tous fait a la main ).

NotePad est un éditeur de texte, pas un FrameWok, pas d'amalgame
De même que rien n'empêche de créer totalement à la main son propre FrameWork.
Un FrameWork est un espace de travail, on le qualifie souvent de moteur, donc d'un outil suffisamment générique pour pouvoir créer des sites Web intégrant des services plus ou moins différents.

[redoran]

Salut; RunCodePhp
merci d'avoir donné de votre temps a m’expliquai certaines choses ,
a mon avis :
Savoir en détail comment les pirates font pour pirater les sites = développez les techniques permettant de s'en prémunir.

NotePad est un éditeur de texte, pas un FrameWok, pas d'amalgame

je voulai dire que je fait tout le travail sur NOTEPAD++ , je n'utilise aucune assistance d'outil dédie ( CMS - Framework...) peut être c'est un inconvénient !!
dans le sens de votre intervention , je suis tombé sur cet article de Harry Guillaume http://web.developpez.com/tutoriels/...plication-web/
sa me donne de la matière première pour secoué un peut mes méninges bonne lectue
Est ce que je dois resté sur Notepad++ ou passé directement au framework et le quel est le plus adapté ?
merci

[grunk]

Attention à l'article que tu cites , je ne sais pas si il a été corrigé depuis , mais j'avais émis pas mal de remarques (voir les commentaires) sur celui ci.

Après dans l'ensemble, il donne tout de même les bonnes pratiques

[redoran]

@ grunk +1;
dans une première lecture j'ai constaté la même chose dont ce que vus avé cité:

....
2- Le minimum pour la protection des injections est l'utilisation des fonctions de base du sgbd du type mysql_real_escape_string qui va échapper les caractères à risque du type de :
Citation:
NULL, \x00, \n, \r, \, ', " et \x1a
Dans l'idéal on utilisera des requêtes préparées via PDO ou mysqli , qui sont actuellement la solution la plus sure pour se prémunir des injections sql.

ce que j'ai adopté dés le début.

A ces requêtes préparées il faut impérativement ajouter une validation et/ou un filtrage des données utilisateur (c'est précisé dans l'article) via des fonctions telles que filter_input ou intval(), floatval() ...

je filtre mes données en utilisant les bindparam.

Utiliser un token unique pour chaque action à risque. De cette manière un attaquant qui enverrai un formulaire à la place d'un utilisateur n'aurai pas le token qu'aurai du générer l'utilisateur si il avait été effectivement sur la page de formulaire.

d'après ce que j'ai lu , on peut volé des ID de session ou cookies alors le token suit aussi non !!!

[RunCodePhp]

a mon avis :
Savoir en détail comment les pirates font pour pirater les sites = développez les techniques permettant de s'en prémunir.

On peu voir les choses ainsi, sans aucun problème.

Cependant, la question qu'il me vient immédiatement, c'est à quel prix ?
C'est à dire combien de temps te faudra t-il pour déjà énumérer toutes ces différentes attaques possibles, mais aussi le temps pour les comprendre, mais encore le temps qu'il te faudra pour les intégrer.

Après vient un autre facteur, c'est d'être certain d'avoir un niveau suffisant pour les comprendre et développer (ou intégrer) tout ça.


Une autre approche consiste à se soustraire de cette tâche ingrate en s'appuyant sur ce qui existe déjà.
Les FrameWork par exemple (c'est juste un exemple) intègrent plus ou moins tout ça.


Par ailleurs, ce que tu dit est déjà en partie contradictoire.
Le fait d'exploiter PDO est une manière de se soustraire de se qui se cache derrière une attaque par injection SQL.
On somme, on s'en fiche qu'est-ce que c'est qu'une injection SQL, comment techniquement le pirate procèdera, on utilise PDO + requête préparée et l'affaire est réglée.
Au même titre qu'on s'en fiche comment ça se passe dans le core de PDO (Php/MySQL).

Bref ... on se soustrait de certaines tâches qui dans le fond n'ont rien avoir avec le coeur de ce qu'on veut faire : Le site Web (un blog, un forum, un réseau social, e-commerce, etc, etc ...).


Et bien au niveau d'un FW c'est pas loin d'être la même chose pour d'autres types d'attaques.
Suffit d'intégrer le module, puis de le configurer (définir quelques clé, le type de Hash, etc, etc ...) et les choses se feront automatiquement.
Rien n'empêche d'éplucher le code du FW pour savoir comment tout ça est goupillé.
Pour le peu que j'en ai vu, c'est hyper complexe.


L'autre gros problème de vouloir faire tout cela soit même, c'est que lorsqu'on se penche dessus on le comprend sur le moment.
Par contre, 6 mois ou un an après, on oubli.
Donc rien ne dit qu'on appliquera toujours rigoureusement toutes ces sur-couches de codes pour la sécurité tout le temps.


Toujours est-il qu'à un moment j'en ai eu vraiment marre de passer des heures et des heures la dessus.
Pas le temps puis trop prise de tête.
Je me suis orienter vers l'apprentissage d'un FW en partie pour ça.


Bon, je parle beaucoup de FW, mais je ne suis pour autant un inconditionnel de ce genre d'outil.
Je dis juste que ces outils ont leur avantages, il y a aussi des inconvénients.

[ABCIWEB]

d'après ce que j'ai lu , on peut volé des ID de session ou cookies alors le token suit aussi non !!!

On peut envisager les systèmes de protection comme des couches successives qui chacune protègent d'un certain type d'attaque. Les jetons sont faits pour lutter contre les attaques CSRF et rien d'autre.

[redoran]

Salut; ABCIWEB le message est passé merci pour votre disponibilité.
@RunCodePhp
ta résumé tous , c'est concluant merci encore une fois.
est ce que tu peut me conseiller un framework ?

@ grunk merci

[RunCodePhp]

est ce que tu peut me conseiller un framework ?

Attention, j'avais bien précisé que je m'étais orienter vers un FW en partie pour cet aspect sécurité, pas mais uniquement.

Le choix d'un FW me semble pas si simple que ça, ça dépend de beaucoup de critères, et ça ne pas être autre que TES critères.

Il te faut à tout prix avoir une idée de ce que tu veux, éviter une espèce d'effet de mode ou autre.

Il y en a beaucoup, certains ont soient bien évolués ou tout simplement vu le jours après avoir fait mon choix à l'époque, ce qui veut dire que je ne choisirais pas le même actuellement très certainement.

Puis j'en connais pas 36, j'en connais qu'1 seul, c'est celui que j'avais choisi à l'époque : Kohana


Vu que les choses ont pas mal évolués maintenant, CakePhp dans sa dernière version me semble être un excellent FW (pour moi en tout cas).

ZendFW reste sans nulle doute une valeur sûr (mais très évolué, trop pour moi).
... etc, etc ...


Il faut sillonner le Net, procéder peut être en 1er par élimination, faire des install histoire de voir si on accroche ou pas, bien voir la part/temps d'apprentissage qu'il va avoir, la qualité des docs, la réactivité de la communauté, etc, etc ...
Bref, tes critères quoi

[ABCIWEB]

ta résumé tous , c'est concluant merci encore une fois.
est ce que tu peut me conseiller un framework ?

Non c'est pas concluant, ou du moins faut pas être si catégorique. Comme pour tout cela dépend du contexte

En poussant un peu plus, tu pourrais dire aussi que plutôt d'utiliser un framework autant passer à l'étape supérieure et utiliser directement un CMS standard pour avoir encore moins de code à t'occuper. Chacun son choix, mais chaque choix a des conséquences.

Toute solution prêt à l'emploi a ses contraintes, en termes de temps d'apprentissage, en termes de consommation des ressources, et surtout cela t'impose des méthodes à respecter qui sont parfois bien lourdes au regard du résultat final et peuvent entraver considérablement ta liberté d'action pour faire facilement du sur mesure.

Prenons l'exemple d'un petit site un peu spécifique.

Déployer toute la cavalerie pour quelques pages, ça ressemble assez à prendre un semi remorque pour transporter un vélo. Tu dois te rendre dans un endroit assez difficile d'accès avec de multiples virages et les routes les plus directes passent sous des ponts limités à 2m de haut. A vol d'oiseau ce n'est qu'à quelques kilomètres. Avec ton camion tu vas galérer comme un malade, le sinistre pour prendre des virages serrés, les détours pour éviter les ponts, sans compter d'avant de partir il faudra faire un autre détour pour faire le plein à la station service. Au total ça fait beaucoup de frais de fonctionnement, beaucoup de sueur et d'effort pour arriver finalement tout énervé à la terrasse du bar, où ton copain qui avait pris son vélo, t'attend déjà depuis trois plombes en train de siroter son demi, les doigts de pieds en éventail.
Et l'aventure ne s'arrête pas là, car c'est le même topo pour le retour à la maison Toi qui pensais tout à l'heure que l'avantage du camion c'était de pouvoir mettre un vélo dedans, et pas l'inverse, tu rigole un peu moins maintenant

Moralité, faites du sport, ou tout au moins un minimum !

On y gagne aussi en réactivité car en développant de moins en moins de code à la main on perd de la pratique, on oublie des connaissances.

On y gagne aussi en vigilance et parfois même en sécurité car ça évite de se croire protéger une fois pour toutes. Parce qu'à force de se croire protéger on a tendance à ne plus vouloir s'occuper de protection et on peut oublier assez vite que les spécialistes ne protègent que de ce qu'ils peuvent faire dans leur spécialité. Donc dans les deux cas, avec ou sans framewok, il faut connaître le sujet au minimum

Tout à l'heure je parlais de performances, mais en termes de sécurité on en revient aussi à notre histoire initiale. Si pour certains projets, un framework permet juste d'éviter d'avoir à écrire quelques htmlspecialschars qu'il faudra de toutes façons remplacer par une autre formule... Bon c'est pour illustrer

C'est d'ailleurs un peu le même topo pour l'obsession des requêtes préparées. Initialement elle sont prévues pour accélérer l'exécution des requêtes multiples, pas pour la sécurité.
Il se trouve que leur conception rend la requête plus sécurisée, mais en contre partie ça te fait du code en plus, parfois de la gymnastique pas facile pour binder les variables, et ça prend un peu plus de ressources niveau serveur pour préparer la requête. En pure perte pour des requêtes simples et facilement sécurisables par ailleurs.
Prenons le cas d'une pagination, tu attends en retour un entier pour faire ta requête. Une fois que tu auras fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$limite = isset($_GET['limite']) && is_numeric($_GET['limite']) ? intval($_GET['limite']) : 0;

...je vois pas trop l'intérêt de faire une requête préparée à la ligne suivante juste pour protéger la variable $limite. En faisant de la "délégation de pouvoir systématique", on perd en temps de développement et on augmente les ressources nécessaires.


Alors au final un framework pourquoi pas, quand tu as beaucoup de code assez standard à produire, c'est utile, également si tu travaille en groupe pour standardiser le développement; mais il faudra aussi savoir s'en passer suivant les cas. Et si tu t'intègre à un projet ou si tu trouve un emploi salarié rien ne dit que le framework utilisé sera le même que le tiens...
Si tu vise les grosses boites, c'est assez utile de connaître ZF et Symfony qui sont les gros cadors et qui n'ont pas la même "philosophie". En dehors de ça tu peux en trouver une multitude qui vont de niveau quasiment débutant à niveau recherche.
Inutile de te préciser qu'il faut t'assurer de leur pérennité sinon en plus de l'apprentissage devenu inutile, tu peux te retrouver avec des sites qui seront "bloqués" sur d'anciennes configurations et dans ce cas la sécurité peut devenir le maillon faible

Enfin bon, comme tu vois et comme disait RunCodePhp, le choix n'est pas si simple. Pas si simple au point que pas mal de développeurs hésitent non seulement sur le choix mais aussi sur la pertinence d'en utiliser un. Et la réponse est parfois oui, parfois non.

Dernier point, on ne devrait à mon avis jamais utiliser un framework sans de solides connaissances. Sinon c'est un peu comme utiliser jquery en ayant peu de connaissances en javascript et css, on ne va pas bien loin et l'on part souvent sur de mauvaises pistes.

Tu l'aura compris, pour moi un framework est un outil complémentaire et qui ne doit pas être considéré à priori comme un substitut, sinon c'est faire fausse route

[RunCodePhp]

+1 ABCIWEB

Ne perdons pas de vu tout de même que pour avoir un avis objectif si tel u tel projet serait bon de s'appuyer sur un FW ou non, il faut maitriser les 2, voir 3 si on inclus les CMS.

Donc avoir les connaissances pour créer le projet de A à Z (y compris le coté sécurité) de même connaitre au moins 1 FW (voire plusieurs).


Pour le moment @Redoran se trouve dans 1 seul cas : tout développer soit même.
Rien ne dit que tu ne serait pas en train de réinventer la roue (hypothèse bien sûr).


Maintenant, et comme dirait l'autre, "c'est en forgeant qu'on devient forgeron".
Ce qui veut dire que commencer par réinventer la roue n'est pas une si mauvaise idée que ça.

D'ailleurs, de mon coté j'en avais fait de même.
Créer des sites Web de A à Z, puis m'est venu de créer mon propre FW (quelque peu mal goupillé d'ailleurs).
Je pense d'ailleurs que ce serait des étapes indispensables pour justement passer à l'étape suivante.
On sera plus à même de faire le choix du ou des FW qu'on pense utile à apprendre, et aussi de s'il est bon ou pas d'en exploiter un pour tel ou tel projet.

Déployer toute la cavalerie pour quelques pages, ça ressemble assez à prendre un semi remorque pour transporter un vélo.

Je ne partage pas tout à fait cette idée là, dans la mesure où il existe des FW très très simple et léger, donc très loin d'être une "cavalerie".
Kohana (pour exemple) en fait partie, et eux même précise bien qu'il est adapté pour des petits ou moyen projet.
C'est un jeu d'enfant à déployer et à configurer, et j'ai même tendance à dire qu'après cette étape le reste ira plus vite que de tout faire "à la mano".
C'est d'ailleurs le principal objectif d'utiliser un FW, gagner en productivité, quitte à perdre un peu en performance.


D'ailleurs, le nombre de site Web, même de quelques pages où les développeurs utilisent des CMS (Joomla, WP, etc ...) et assez impressionnant.
Pas étonnant, ça se fait en un temps record quant on maitrise bien l'outil.

[ABCIWEB]

Je ne partage pas tout à fait cette idée là, dans la mesure où il existe des FW très très simple et léger, donc très loin d'être une "cavalerie".
Kohana (pour exemple) en fait partie, et eux même précise bien qu'il est adapté pour des petits ou moyen projet.
C'est un jeu d'enfant à déployer et à configurer, et j'ai même tendance à dire qu'après cette étape le reste ira plus vite que de tout faire "à la mano".
C'est d'ailleurs le principal objectif d'utiliser un FW, gagner en productivité, quitte à perdre un peu en performance.

Oui oui, j'ai rien à redire pour ces cas là. Mais tu as oublié le préambule de ma réponse

Prenons l'exemple d'un petit site un peu spécifique.

Je voulais dire par là, un petit site qui n'entre pas dans les "standards", quand les contraintes de l'utilisation du framework impose plus d'inconvénients que les avantages qu'il procurera par ailleurs. Et c'est pas toujours facile à voir si on à l'habitude d'utiliser systématiquement toujours le même outil.

D'ailleurs, le nombre de site Web, même de quelques pages où les développeurs utilisent des CMS (Joomla, WP, etc ...) et assez impressionnant.

Ben oui, c'est fait pour ça. Tant que tu trouve le bon module qui correspond à tes besoins, t'es le roi de la productivité. Sinon il faut développez son module et il faut bien connaître non seulement php mais aussi son CMS. Par ailleurs ces outils ne sont pas fait pour tenir une montée en charge du fait de la modélisation trop généraliste de la bdd.

Mais bon dans de nombreux cas ça rend bien service c'est certain, et je ne vois pas d'inconvénient à utiliser ces outils dans leur domaine de compétence. Enfin si il y en a un de majeur et qui rejoint la sécurité. Du fait de l'open source, faut pas oublier les mises à jour régulières sinon c'est presque le piratage assuré. Et ça c'est quand même une grosse contrainte que n'ont pas les sites faits maison.

[RunCodePhp]

@ABCIWEB
Les arguments ne sont pas si objectifs que ça, je ne partage donc toujours vraiment cela.

Si le projet est spécifique, alors qu'il soit petit, moyen ou grand en tout évidence il y aura peu de chance qu'un FW entre dans le moule (ou inversement).
Il n'y a donc pas besoin d'évoquer ce cas là, ça coule de source.


Si le projet est hyper spécifique, ce ne serait donc plus très loin de ne pas être un site Web.
Là encore il n'y a pas lieu d'évoquer le cas.

Donc il me paraissait évident que la base du projet aient au moins les mêmes besoins que quasi tous les site Web.
Un FW à la base c'est juste un moteur, après ça chacun ont leur manière d'aborder les choses, et offrent plus ou moins de services annexes.


Toujours est il que tous ce que redoran évoquait sont des problématiques que quasi tous les sites Web rencontrent, sont besoin n'a donc rien d'extraordinaire, rien de spécifique.


Puis un site Web, même spécifique c'est théoriquement des échangent via HTTP, FTP, etc ... donc différents protocoles.
Si on sort de ce cadre là, on mon sens on ne parle plus de la même chose (site Web).
Les FW sont justement fait pour gérer ce genre d'échange, et c'est juste un moteur, ça sous entend qu'il faudra développer tous les services qu'on voudra faire (qui est à l'opposé des CMS et autre truc clé en main où là effectivement il faudra que le projet entre dans le moule).


Puis pour ce qui est des montées en charges, ça pour moi c'est de la désinformation car il existe pleins de très très gros site Web s'appuyant sur des FW (twiter et compagnie ...).
Les montées en chargent sont à mon sens plus un problème de serveur, voire du langage lui même (Php) qu'autre chose.

Puis n'oublions pas qu'ils existe un grand nombre de FW, donc si le responsable du projet fait une erreur dans le choix, et bien cela devient un problème de compétence, pas du FW.



Pour ma part, si on a de bonnes bases en Php/SQL, j'ai tendance à penser que prospecter ne serait-ce que 2 ou 3 FW serait un passage obligé.
Après ça libre à chacun de l'exploiter ou pas pour tel ou tel projet.
Mais au moins il saura ce que c'est, et dresser lui même les avantages et inconvénients.
Histoire de ne pas restant ignorant en somme.

L'autre problématique, c'est que certains FW sont tellement différents qu'à la limite on ne peu même plus les comparer.
Ce qui sous entend qu'il ne faudrait même pas en faire une généralité en parlant de FW.
J'ai essayer ZendFrameWork (pour exemple), il ne m'a pas fallut longtemps pour comprendre que celui-ci est incomparable à Kohana, c'est le jour et la nuit.

Du fait de l'open source, faut pas oublier les mises à jour régulières sinon c'est presque le piratage assuré. Et ça c'est quand même une grosse contrainte que n'ont pas les sites faits maison.

Si on se trompe, (MAJ trop fréquentes à notre gout), alors c'est un problème de compétence, pas du ressort du FW (ou CMS).
Ces infos là sont dispos sur les sites de ces FW (ou CMS).
Que ce soit un critère à prendre en compte, là dessus je suis d'accord.

Mais attention tout de même à ne pas comparer les FW et les CMS.

Pour ma part j'ai plutôt évoqué les FW, car à l'opposé des CMS, on conservera en grande partie la maitrise de notre projet, on ne fait que s'appuyer sur un moteur.
En somme, le logiciel (si on peu dire) il faudra tout de même le créer (pas loin d'être de A à Z).

[ABCIWEB]

Dans mon dernier paragraphe je répondais à une citation où tu parlais de CMS. Ma réponse concernant entre autre la montée en charge concernait donc ces CMS, pas les framework

[RunCodePhp]

Dans mon dernier paragraphe je répondais à une citation où tu parlais de CMS. Ma réponse concernant entre autre la montée en charge concernait donc ces CMS, pas les framework

Alors on est d'accord


A coté de ça, on a un peu dérivé du sujet initial
Sorry M'sieur Redoran

[redoran]

salut ; @RunCodePhp @ ABCIWEB
je vous remercie pour ces interventions constructives et ce n'est que la face visble de l'icebergue.
je crois que ces interventions font partie du sujet.
malgré mes 3 étoiles ( 80 % en delphi), actuellement je suis en 11 mois en autoformation ( application site web) PHPMYSQL ; j'ai quitter le monde du RAD et j'ai opter pour faire le tous a la main pour un meilleur apprentissage et cela permet de développez ces propres méthodes toutes en restant dans les normes.
CMS ou framework sont développez par des spécialistes en la matière , malgré ça y 'a des failles de sécurité et même victime de piratage !!!

[RunCodePhp]

CMS ou framework sont développez par des spécialistes en la matière , malgré ça y 'a des failles de sécurité et même victime de piratage !!!

Php lui même comportait des failles de sécurité, en contient encore peut être, et on peu estimer qu'il y en aura toujours.
La 1ère chose peut être serait d'éviter la paranoïa.


Je pense qu'il faudrait aussi éviter de faire des comparaisons entre FW et CMS, il y a déjà d'énormes différences avec les FW eux mêmes ce qui fait qu'il y en d'autant plus entre ces 2 là (FW/CMS).

Même si je connais très peu de FW et CMS, mais je lis régulièrement la presse, et j'en ai conclu à aujourd'hui que ce serait plutôt les CMS qui présenteraient plus de problèmes de failles de sécurité, les FW beaucoup moins.

La raison est simple, c'est que les CMS c'est du clé en main, y compris la sécurité, à l'opposé des FW où c'est le développeur des les intégrer, voire les développer.


L'autre aspect, c'est que les trous de sécurités sont bien souvent provoqués par le développeur lui même.
Combien de fois j'ai pu voir sur ce forum et ailleurs un développeur s'appuyant sur un CMS ou un FW faire (juste pour exemple) une requête SQL avec les fonctions mysql_truc_muche() alors que ces 2 là (FW/CMS) intégraient une abstraction de BDD, donc avec la sécurité qui allait avec.

Pour exemple encore, je ne te dis pas le nombre de plugin ou module pour WordPress et autre qu'on peu trouver sur le Net avec du code pourri (codé avec les pieds comme cela se dit souvent), avec toute l'insécurité qui va avec, c'est impressionnant.
Même constat pour certains CMS pour le e-commerce.

Le pire, c'est que ces plugin (ou modules) sont pour certains validés par la communauté, voire même vendus


Tout ça pour dire qu'il faut faire gaffe à ce qu'on lit dans la presse.
Il faut aller plus loin pour savoir pourquoi.
Puis surtout il faut franchement éviter de trop généraliser.
Il existe des FW et CMS extrêmement sérieux ou l'aspect sécurité est pris tout autant au sérieux.

Si par exemple tu t'inscris sur les forums de ZendFW, Symfony, Drupal, Dotclear (pour ne citer qu'eux) et tu leur dit que leur Soft comportent des failles de sécurités, tu risque fort de te faire appeler "Arthur", si tu vois ce que je veux dire.
Il te faudra sérieusement argumenter, leur dire où elles se trouveraient.


Puis si on fait le choix d'un FW ou CMS où la communauté est active, et bien s'il y a une faille dans le core du Soft, celle-ci est en général très vite corrigée.
Un fix est bien souvent proposé au départ, et après ça intégré dans le core dans la version suivante.

Il faut alors en déduire que l'inconvénient majeur lorsqu'on fait un projet de A à Z c'est qu'on sera bien seul face un un problème, tel qu'il soit.
Si son projet comporte une faille de sécurité et que le site Web se fait piraté, on peu estimer qu'on ne pourra pas avoir la même réactivité que celle d'une communauté toute entière.
- On remarquera qu'il y a aura eu un acte de piratage que lorsque ce sera fait, donc trop tard (chose pas forcément le cas pour un FW ou CMS).
- Combien de temps faudra t-il pour fixer la faille ??? Impossible de le définir (alors que pour une communauté active on peu l'estimer à quelque jours).



Mise à part tout ça, j'adhère totalement dans le fait de d'abord faire ces 1ère armes en développant tout soit même, quitte à réinventer la roue.
J'en ai fait de même, je pense d'ailleurs que tous passent par là.

La différence peut être, c'est que j'ai débuté il y a pas loin d'une 10ène d'année maintenant.
A cette époque il y a avait très peu de CMS et FW, et quand même ils existaient, ils étaient nettement moins abouti qu'à aujourd'hui.
Sans compter que l'aspect sécurité n'était pas aussi problématique.

[redoran]

Salut ; merci RunCodePhp.
je crois qu'il me reste beaucoup de chemin a faire en programmation 11 mois / 10 années
alors je reste sur le tous a la main, vue ma fonction je développe mes propres cahiers de charge selon mes besoins toute en restant objective afin de de développez des applications a titre d'apprentissage.
mon seul inconvénient c'est je ne possède pas de serveur pour le test alors je reste sur le local ( wamp).
langage choisi PHP,
SGBDR MYSQL
Editeur Notepad++,
donc pour la sécurité je dois suivre les conseils du OWASP ( les 10 risques...),
Aussi le CLUSIF;
Adopter un style de programmation permettant de corriger rapidement les failles,
Lie attentivement la doc http://www.php.net/manual/fr/security.php;

[RunCodePhp]

je crois qu'il me reste beaucoup de chemin a faire en programmation 11 mois / 10 années

Il me semble l'avoir dit, tant pis si je me répète
Je suis 100% amateur (voire à 200%), dans toute sa splendeur, j'ai appris tout cela uniquement par pure plaisir.

Donc ce que j'ai mis 10 ans à apprendre certains peuvent très bien le faire en 2 ou 3 ans.
Si cela peu te rassurer.

Mon Job n'a strictement rien avoir avec du Php, ni de près ni de loin.
J'ai appris cela le soir et le Week end, à temps perdu ... c'est trèèèèèès lonnnnng