Discussion :

[psychoBob]

Bonjour,

Je lis partout que les messages d'erreur de script sont des indications précieuses pour les hackers.

Alors prenons cet exemple :

Code :

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

1
2
3
4
Warning: mysql_result(): 
supplied argument is not a valid MySQL 
result resource in /home/autroisi/www/php/actu.php 
on line 123

Imaginons que sur mon site apparaisse l'erreur ci-dessus, qu'est que le pirate va bien pouvoir en faire ?

[xave]

Ben déjà il obtient une partie de l'arborescence de ton site...

[psychoBob]

Bon mais encore ? Il est en fait quoi de cette partie d'arborescence ? Il va essayer de faire quoi avec ces indications ?

[Alexandre T]

Il sait que sur le serveur est sur linux.
Il sait que la base de données est MySQL et peut tenter d'attaquer le port 3306 du dit serveur.
Il sait qu'un utilisateur autroisi existe probabalement.
Il sait que vous ne vérifiez pas très bien les retours de vos requêtes.
Il sait que vous avez mal paramétré votre serveur pour de l'hébergement.

Il peut donc espérer pirater votre site plus aisément que d'autres !

[psychoBob]

Bon ça l'encourage quoi. Il se met à frétiller sur sa chaise en ricanant, l'air surnois et le regard perçant...

ok


- A quoi est-ce qu'il voit que l'on est sur linux là ?
- Et pourquoi une erreur comme ça indique-t'elle un mauvais paramétrage de l'hébergement ? J'en ai des comme ça, je suis chez ovh, je pense pas qu'ils paramètrent mal quand même.
- Et est-ce vrai ce que l'on m'a dit qu'il faut placer ses scripts PHP en dehors du répertoire www car cela complique considérablement le piratage ?
Si oui, pourquoi s'il vous plait ?

[Alexandre T]

- A quoi est-ce qu'il voit que l'on est sur linux là ?

On n'attaque pas de la même façon un serveur linux qu'un serveur Windows

- Et pourquoi une erreur comme ça indique-t'elle un mauvais paramétrage de l'hébergement ?

Bien sécuriser son serveur consiste en partie à cacher sa nature. Si on laisse des messages de la sorte, on cache moins sa nature, donc il est moins sécurisé

J'en ai des comme ça, je suis chez ovh, je pense pas qu'ils paramètrent mal quand même.

Oui et non. En fait, ils ont hésité entre deux choses :
Ou bien cacher les warning et bien cacher les informations ;
Ou bien recevoir plein de mail de webmasters disant : mon script n'affiche rien. Il ne fait rien, etc... etc...

Mon conseil : modifiez votre niveau de signalement dans vos messages d'erreur.

- Et est-ce vrai ce que l'on m'a dit qu'il faut placer ses scripts PHP en dehors du répertoire www car cela complique considérablement le piratage ?
Si oui, pourquoi s'il vous plait ?

Bah si c'est en dehors du chemin www, ils ne s'affichent pas. Donc il faut seulement mettre les fichiers inclus, les librairies dans un répertoire extérieure. Par contre, les fichiers consultés (comme index.php) doivent être accessible.

Pour ma part j'utilise l'arborescence suivante

Code :

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

1
2
3
4
5
/home/user/www/www.site1.com
/home/user/www/www.site2.com
... ... ...
/home/user/www/www.siten.com
/home/user/www/lib/

Seuls les répertoires /home/user/www/www.sitex.com sont "diffusés" par Apache.
Le répertoire lib n'est jamais diffusé.

PS : j'ai dit sitex, pas site X !

[psychoBob]

- A quoi est-ce qu'il voit que l'on est sur linux là ?

On n'attaque pas de la même façon un serveur linux qu'un serveur Windows

Je fais mal le lien entre la réponse et la question là.

Bah si c'est en dehors du chemin www, ils ne s'affichent pas. Donc il faut seulement mettre les fichiers inclus

Oui je fais des requires. Donc en fait ça empêche le pirate d'ouvrir directement les fichiers inclus dans son navigateur c'est ça ? Et donc d'en connaitre le code ?

Le répertoire lib n'est jamais diffusé

Qu'est ce que tu veux dire par "diffuser"? (Je commence à m'intéresser un peu aux serveurs, parce que si je dois acheter un dédié un de ces jours, autant prendre de l'avance...)

[ePoX]

Salut,

- A quoi est-ce qu'il voit que l'on est sur linux là ?

En faisant un telnet sur n'importe quel serveur web tu peux récupérer le harder HTPP. Ce header peut être très interessant selon les cas.

exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
HTTP/1.1 200 OK
Date: Sat, 27 May 2006 10:50:46 GMT
Server: Apache/1.3.33 (Unix) mod_gzip/1.3.19.1a PHP/5.0.3 mod_ssl/2.8.24 OpenSSL
/0.9.6m
Last-Modified: Wed, 28 Apr 2004 10:55:38 GMT
ETag: "6bcb1-13b-408f8daa"
Accept-Ranges: bytes
Content-Length: 315
Connection: close
Content-Type: text/html

Tu notes que deja on connait avec précisions et certitudes la version d'apache/php/ssl. Le pirate peut dès lors rechercher les failles existantes dans ces softs et tenter de les exploiter.

- Et pourquoi une erreur comme ça indique-t'elle un mauvais paramétrage de l'hébergement ? J'en ai des comme ça, je suis chez ovh, je pense pas qu'ils paramètrent mal quand même.

Rendre ton appli aussi opaque que possible est une source de sécurité. En effet, moins on sait sur un truc plus il est compliqué d'imaginer des comportements et donc des failles.

Si je reprend l'exemple du dessus, si le pirate sait que je travaille avec PHP, alors il à tout à fait raison de penser que je travaille avec un SGBD. Et que donc mon appli est succeptible de contenir des failles SQL.
Si il ne l'avait pas su, il aurait travailler en aveugle... Ce qui n'est pas très motivant.

- Et est-ce vrai ce que l'on m'a dit qu'il faut placer ses scripts PHP en dehors du répertoire www car cela complique considérablement le piratage ?
Si oui, pourquoi s'il vous plait ?

Ah oué.. On t'a dit cela. C'est censé compliqué quoi de plus ?
A l'interieur ou l'exterieur de la racine web, un fichier php n'est pas lisible via apache.
Seul le résultat de son execution est disponible.

Bref, je n'ai pas compris l'interet.

Je commence à m'intéresser un peu aux serveurs, parce que si je dois acheter un dédié un de ces jours, autant prendre de l'avance...

Bon courage

bbye

[psychoBob]

En faisant un telnet sur n'importe quel serveur web tu peux récupérer le harder HTPP. Ce header peut être très interessant selon les cas.

J'ai déjà lu ce mot là, telnet, mais je sais plus ce que c'est et comment on le fait.

Tu notes que deja on connait avec précisions et certitudes la version d'apache/php/ssl. Le pirate peut dès lors rechercher les failles existantes dans ces softs et tenter de les exploiter.

Je note, je note... Déjà on a affaire à un pro qui n'en veut là.

Ah oué.. On t'a dit cela. C'est censé compliqué quoi de plus ?
A l'interieur ou l'exterieur de la racine web, un fichier php n'est pas lisible via apache.
Seul le résultat de son execution est disponible.

Bah le gars qui m'a dit ça sur un forum avait l'air sur de lui et personne l'avait contredis. Il m'avait dit "le seul moyen de rendre ton application parfaitement sécurisée, c'est de placer tes fichiers en dehors du répertoire www".

Je commence à m'intéresser un peu aux serveurs, parce que si je dois acheter un dédié un de ces jours, autant prendre de l'avance...
Bon courage

C'est si compliqué que ça ? Pas plus que d'apprendre le PHP quand on y connait rien en programmation quand même ? Faut combien de temps pour s'y retrouver avec un dédié ? 3 semaines ? 30 ans ?

[Mr N.]

- A quoi est-ce qu'il voit que l'on est sur linux là ?

Pour répondre directement à la question, ton warning indique le path '/home/autroisi/...'
Or c'est les architecture *nix qui ont une telle arborescence. Sous windows tu aurais eu par exemple 'c:\wamp\www\php\actu.php'

Concernant les fichiers hors de l'espace www, ça empeche l'utilisateur d'appeler directement les fichiers inclus, du genre config.php ou autres, esperant afficher quelques infos utiles.

Sinon plus tu donnes des infos, plus le pirate a des chances de trouver une faille de sécurité connues (ou non) : système d'exploitation, applications (php, mysql, ...), librairies (phpbb, oscommerce, ...), ...

[psychoBob]

ok là c'est clair pour la façon de reconnaitre un serveur linux, merci Mr N.

[hugo123]

Petite exemple vécu :
En visitant un site, je suis tombé sur une erreur lors de l'inscription.
En gros ca disait, warning : erreur dans le fichier config.inc a la ligne x
"Ah oui ? Donc ils ont un fichier config.inc ?"
Et souvent les fichiers .inc sont pas interprétés si le serveur est mal configuré. J'ai donc tenté de l'ouvrir en mettant le chemin directement. Et evidemment, ca a marché.
Du coup j'avais les paramêtres de l'appli, le mot de passe de la base et de l'admin qui était en dur dedans.

Voici donc un bel exemple de message d'erreur qui aurait causé des problèmes si j'avais été moins sympathiques (je me suis contenté de le signaler par mail).

[psychoBob]

A ce sujet je me rappelle que l'une des premières choses que j'ai lu en matière de sécurité des applications web en php, c'est de toujours nommer ses fichiers en .php et jamais en .inc.

Mais pourquoi .inc existe-t'il alors ?

[hugo123]

.inc existe tout autant que que .tototruc
C'est a chacun de nommer ces fichiers correctement. Personnellement je n'utilise pas d'autres extensions que .php ^^

[psychoBob]

C'est noté

Bah si y'a d'autre trucs à dire hésitez pas...

[Alexandre T]

.inc existe tout autant que que .tototruc
C'est a chacun de nommer ces fichiers correctement. Personnellement je n'utilise pas d'autres extensions que .php ^^

Le plus sûr est encore de le mettre en dehors de l'arborescence web !

[psychoBob]

Bah c'est ce que j'avais dis mais tu as juste dis que ça allais simplement empêcher le pirate de l'ouvrir, sans détailler d'avantage.
ça n'a d'action que sur l'ouverture de fichier directement dans le navigateur, le fait de placer ces fichiers en dehors de l'arborescence ?

Ou ça gêne pour d'autres trucs aussi ?