[le_gremz]

Bonjour à tous,
On dit que le PHP est plutôt pas mal point de vu sécurité...On dit aussi qu'il est impossible de voire le code source.Est-ce vraiment sur?En claire on pourrait pas craké un système de login en php vu que on peut pas voir les sources...
Dit-moi si je me trompe...

[akway]

Salut !

PHP pas mal au niveau sécurité...tout est relatif. Il existe pas mal de vulnérabilités ciblant les différentes versions de PHP lui même. (ex. ICI), sans compter l'infinité de modules et librairies annexes.Au final, c'est un peu comme le choix de l' OS, le plus sécurisé c'est celui qu'on maitrise le mieux. 

Le fait que PHP ne permette pas de voir le code source (par rapport a HTML ou javascript par exemple ou là, en effet , tu pourras voir le code source de la page) vient du fait que php est executé directement coté serveur, et pas envoyé au navigateur du client pour traitement. Cependant, une toute petite faille sur un des modules d' un site peut parfois permettre a l'exploitant de récupérer le code source.
Puis ce n'est pas parce qu'on ne voie pas le code source qu'on ne peut rien lui envoyer/executer

En clair PHP en lui même N' ASSURE PAS la sureté d'un formulaire d'authentification, et ça les épreuves de la section hacking te l'expliqueront mieux que moi.
     
 

[le_gremz]

Ok merci pour vos réponses

[Iansus]

La seule manière de voir le code source PHP serait d'inclure la page avant qu'elle soit exécutée côté serveur, id est, tu lis le fichier PHP et tu l'affiches.
Mais en général, tu auras du mal à faire ça facilement sans une petite faille include ou un backdoor préalablement déposé sur le site.

Pour la faille include, un bon exemple était le CMS Webspell, qui jusqu'à la version 4 possédait une faille include énorme.
Le fichier picture.php récupérait le CONTENU du fichier passé dans la variable ?file et l'écrivait dans la page, elle même incluse via une balise <img> dans un autre fichier.
Il suffisait de télécharger Webspell pour se rendre compte que le fichier _mysql.php contenait tout ce qu'il faut pour se connecter au serveur SQL, et que le code source de la page http://monsite.fr/picture.php?file=_mysql.php était en fait le contenu de _mysql.php.

Exemple rare d'apparition de PHP dans le code source. D'ailleurs, FireFox a très bien compris qu'en général ce n'était pas affiché, et le parse en rose quand il y en a.

Sinon, tu peux toujours voir la source des fichiers PHP si le serveur n'a pas PHP...

[pal83]

Ou alors si tu es chez un hébergement mutualisé, et que la fonction system() fonctionne... (ca existe?)
Mais bon à ce moment là plus rien n'est sécurisé, même pas les dossiers protégés par un .htacces ^^'

[neroptik]

Ou alors si tu es chez un hébergement mutualisé, et que la fonction system() fonctionne... (ca existe?)
Mais bon à ce moment là plus rien n'est sécurisé, même pas les dossiers protégés par un .htacces ^^'

Pas forcement. Connais tu les jails ou encore le chroot ?
Techniquement si tu possede ton propre pool de process, t'a propre racine de dossiers, et tes propres fichiers et binaires, peu importe que tu soit sur une machine mutualisee tu n'a conscience que de ta partie du systeme et tu n'a pas acces au reste.
Les jails sont choses courantes chez les hebergeurs il me semble.

[_o_]

Pas forcement. Connais tu les jails ou encore le chroot ?

Chroot n'est pas un outil de sécurité, ça se troue les doigts dans le nez : http://sid.rstack.org/blog/index.php/222-prison-break
Par contre, tu as raison sur les jails de FreeBSD (et l'équivalent sur Solaris), qui sont des vraies solutions de cloisonnement.

Les jails sont choses courantes chez les hebergeurs il me semble.

Sérieusement ? Je n'en ai jamais vu. En tout cas chez des hébergeurs gratuits ou pas chers, et si on a besoin d'un cloisonnement, on prend un dédié, vu les prix actuels. Non, je n'ai jamais vu ce genre de mécanisme sur des mutualisés (c'est lourd à déployer, administrer, et pas rentable pour des petits sites), et c'est bien pour ça qu'il ne faut pas espérer héberger un site secure sur un mutualisé : une petite faille sur l'appli d'à côté, et c'est tout le serveur qui est compromis.

[neroptik]

Sérieusement ? Je n'en ai jamais vu. En tout cas chez des hébergeurs gratuits ou pas chers, et si on a besoin d'un cloisonnement, on prend un dédié, vu les prix actuels. Non, je n'ai jamais vu ce genre de mécanisme sur des mutualisés (c'est lourd à déployer, administrer, et pas rentable pour des petits sites), et c'est bien pour ça qu'il ne faut pas espérer héberger un site secure sur un mutualisé : une petite faille sur l'appli d'à côté, et c'est tout le serveur qui est compromis.

Eh bien disons que j'osais esperer
Apres reflexion j'avoue que ce serai pas tres viable pour les hebergeurs en terme de cout/maintenance/deploiement mais bon... comme quoi on nous vend le beurre, la creme et la cremiere pour moins d'un euro et apres on comprends pas pourquoi internet est un monumental gruyere. 

[Barti]

Moi j'ai souvent vu (en farfouilant dans certains sites) des fichiers php renommés de telle façon qu'ils sont lisibles, genre index.php dans un répertoire accompagné de index.php.old du coup l'extension n'est plus considérée comme du php, donc lisible, ou encore j'ai souvent vu index.php~ et là aussi c'est lisible, et franchement je trouve ça assez répandu comme truc et c'est un peu con, surtout que j'ai vu ça sur deux-trois sites plutot gros et ça peut faire mal.