Merci de tester la sécurité de mon site

[ortolojf]

Bonjour
Tout est dans le titre.
Théoriquement, je pense avoir suffisamment sécurisé la prise en compte des paramètres de mes scripts PHP, qui sont en GET. ( Ce n'est pas un secret, c'est visible sur la ligne de commande du navigateur. )

Pourriez-vous faire des tests, les plus zarbis qui soient, pour déceler un comportement bizarre de mon site, qui est dans mon profil ?

Merci à tous.

Jean Francois Ortolo

 

[itsme]

Aller, un p'tit coup d'oeil

1) il vaut mieux securiser un repertoire que de le mettre dans robots.txt. C'est la premiere chose que l'on regarde pour savoir ou chercher.
=> xw.ortolojf-courses.com/robots.txt

2) securiser donc les repertoires que tu veux proteger avec htaccess et leur donner un nom moins evident.
=> ww.ortolojf-courses.com/robotstats/

3) eviter les injectionsSQL : controles les parametres utilises pour tes requettes SQL
=> ww.ortolojf-courses.com/php/courses_nouvelles/stat2_new_courses.php?JOUR=1#

4) Le systeme de redirection n'est pas top => ww.ortolojf-courses.com/php/redirections/action_index.php?ADRESSE=../../robotstats/

J'arrete la

 

[ortolojf]

Aller, un p'tit coup d'oeil

1) il vaut mieux securiser un repertoire que de le mettre dans robots.txt. C'est la premiere chose que l'on regarde pour savoir ou chercher.
=> xw.ortolojf-courses.com/robots.txt

2) securiser donc les repertoires que tu veux proteger avec htaccess et leur donner un nom moins evident.
=> ww.ortolojf-courses.com/robotstats/

3) eviter les injectionsSQL : controles les parametres utilises pour tes requettes SQL
=> ww.ortolojf-courses.com/php/courses_nouvelles/stat2_new_courses.php?JOUR=1#

4) Le systeme de redirection n'est pas top => ww.ortolojf-courses.com/php/redirections/action_index.php?ADRESSE=../../robotstats/

J'arrete la

Bonjour itsme

Le problème, c'est que:

1- Je suis obligé d'empêcher les moteurs de recherche de scanner certains fichiers...
2- Le répertoire /robotstats/ est connu par tout le monde, c'est le seul autre répertoire que j'aurais besoin de cacher, mais quelle importance, vu qu'il ne contient que des scripts PHP, qui sont eux-mêmes facilement connaissables, en téléchargeant RobostStats ? Et puis, un hack de RobostStats, celà ne me fait ni chaud ni froid...
3- Pour les paramètre $_GET de mes scripts, pour ce qui est du script stat2_old/new_courses.php , tous mes paramètres sont vérifiés et sur-vérifiés, et des valeurs fausses n'aurait que très peu d'impact sur le fonctionnement de mon site, seulement des mauvais résultats pour l'utilisateur. D'un autre côté, dans tout mon site, ma base de données n'est utilisée que pour de la lecture avec des SELECT, sans aucune écriture.
4- Pour la redirection, il se pourrait que d'aucuns mettent d'autres valeurs à la variable adresse, mais il faudrait pour celà, qu'ils sachent quels sont les scripts dans les répertoires de mon site, et à part /robotstats/ , je ne vois pas comment on pourrait deviner les noms des scripts dans les répertoires, à part évidemment ceux qui s'affichent dans la barre des tâches du navigateur.

Et puis, nonobstant cette redirection... Rien n'empêcherait des hackers de se brancher directement sur ces scripts PHP intermédiaires, je vais examiner tous mes scripts pour étudier les hacks possibles...

Reste qu'il me faudrait une autre sorte de redirection, en fonction du choix de l'utilisateur... Il me suffira d'utiliser un paramètre de transfert, qui décidera sur quelle adresse codée en dur, se fera la redirection, ce que j'aurais du faire depuis longtemps... Merci beaucoup de ta suggestion, et si tu vois d'autres problèmes, n'hésite pas à me le dire! ;-)

Amicalement.

Jean Francois Ortolo

 

[itsme]

1- Je suis obligé d'empêcher les moteurs de recherche de scanner certains fichiers...

un repertoire protege par htacces est aussi protege des moteurs

2- Le répertoire /robotstats/ est connu par tout le monde, ...Et puis, un hack de RobostStats, celà ne me fait ni chaud ni froid...

C'etait cite en exemple

3- Pour les paramètre $_GET de mes scripts, pour ce qui est du script stat2_old/new_courses.php , tous mes paramètres sont vérifiés et sur-vérifiés, et des valeurs fausses n'aurait que très peu d'impact sur le fonctionnement de mon site, seulement des mauvais résultats pour l'utilisateur.

C'etait aussi un exemple l'injection sql permet pas mal de choses. Sans parler de mise a jour, un simple commentaire au milieu d'une requette faisant des jointures sur des grosses tables suffit a provoquer un produit cartesien et donc a planter le serveur

4- Pour la redirection, il se pourrait que d'aucuns mettent d'autres valeurs à la variable adresse, mais il faudrait pour celà, qu'ils sachent quels sont les scripts dans les répertoires de mon site, et à part /robotstats/ , je ne vois pas comment on pourrait deviner les noms des scripts dans les répertoires, à part évidemment ceux qui s'affichent dans la barre des tâches du navigateur.

Il existe des solutions et des logiciels pour retrouver rapidement tes scripts et/ou repertoires (bases sur le principe des dictionnaires)

Reste qu'il me faudrait une autre sorte de redirection, en fonction du choix de l'utilisateur...

Tu as des constantes dans tes redirections, passes en parametre un code qui est une partie du script, cela corsera un peu les choses.

Merci beaucoup de ta suggestion, et si tu vois d'autres problèmes, n'hésite pas à me le dire!

Ne resonnes pas par defaut

A mon avis, la premiere question a te poser est: y-a-t-il quelque chose de vital sur mon site ?
Si oui, est-ce normal que cela y soit ?
Si oui, il faut blinder.
Dans le cas contraire, un developpement propre et des sauvegardes regulieres suffisent amplement

 

[ortolojf]

1- Je suis obligé d'empêcher les moteurs de recherche de scanner certains fichiers...

un repertoire protege par htacces est aussi protege des moteurs

Bof, les seules autres choses que j'aurais besoin de protéger sont des photos...

3- Pour les paramètre $_GET de mes scripts, pour ce qui est du script stat2_old/new_courses.php , tous mes paramètres sont vérifiés et sur-vérifiés, et des valeurs fausses n'aurait que très peu d'impact sur le fonctionnement de mon site, seulement des mauvais résultats pour l'utilisateur.

C'etait aussi un exemple l'injection sql permet pas mal de choses. Sans parler de mise a jour, un simple commentaire au milieu d'une requette faisant des jointures sur des grosses tables suffit a provoquer un produit cartesien et donc a planter le serveur

Tous mes ordres SQL sont fixés avec seulement des variables calculées ( critères de sélections ) qui sont vérifiées et sur-vérifiées.

Il n'y a strictement aucune possibilité pour agir de l'extérieur, sur les contenus de mes critères de sélection, ni sur les ordres SQL non plus.

4- Pour la redirection, il se pourrait que d'aucuns mettent d'autres valeurs à la variable adresse, mais il faudrait pour celà, qu'ils sachent quels sont les scripts dans les répertoires de mon site, et à part /robotstats/ , je ne vois pas comment on pourrait deviner les noms des scripts dans les répertoires, à part évidemment ceux qui s'affichent dans la barre des tâches du navigateur.

Il existe des solutions et des logiciels pour retrouver rapidement tes scripts et/ou repertoires (bases sur le principe des dictionnaires)

J'ai seulement revérifié tous les scripts intermédiaires qui s'affichent dans la barre des tâches du navigateur, et blindé toutes les valeurs de variables $_GET transmises, mais je pense que même pour tous les scripts que j'utilise non visibles, les variables paramètres sont suffisamment protégées, et compte tenu de l'effort qu'il faudrait faire pour trouver les scripts invisibles en question, j'avoue que je n'ai pas tellement vérifié, bien que je me souvienne en gros, quelles variables sont transmises, et comme les scripts visibles redirectionnés à partir des scripts invisibles, sont protégés contre les hacks de façon très soigneuse, je pense qu'il n'y a pas lieu de s'inquiéter.

Reste qu'il me faudrait une autre sorte de redirection, en fonction du choix de l'utilisateur...

Tu as des constantes dans tes redirections, passes en parametre un code qui est une partie du script, cela corsera un peu les choses.

C'est ce que je disais dans ma réponse.
Ceci dit, les scripts déclenchés par ce premier script de redirection, n'ont pas du tout de paramètre, et donc ne peuvent pas du tout être hackés, car des paramètres qui leur seraient communiqués ne seraient pas pris en compte par les scripts récepteurs. Donc le fait de savoir leurs noms ne permet aucun hack possible.
Je pense donc laisser mon script de redirection tel quel...

Le seul et unique problème qui arrive très très rarement, est quand l'utilisateur stoppe rapidement le chargement de la page des Courses du lendemain/après-midi, ce qui dans de très très rares cas, peut faire que le fichier des Courses soit incomplet... Mais ça, je n'y peux rien, j'ai tout essayé, y compris un verrouillage par fichiers de verrous très très efficace, qui devrait résoudre tous les problèmes de ce type. Cependant, ce matin, pour la première fois depuis de nombreux mois, j'ai vu qu'il n'y avait que deux Courses dans la liste...

Moi qui pensais être définitivement sécurisé contre ce problème
En fait, je ne sais même pas d'où vient le problème dans ce cas, car ces verrouillage que je fais, devraient éliminer complètement le problème.

A mon avis, la premiere question a te poser est: y-a-t-il quelque chose de vital sur mon site ?
Si oui, est-ce normal que cela y soit ?
Si oui, il faut blinder.

Rien de vital, ma base de données est en lecture seule, mais je viens quand même de blinder des paramètres de dates.

Celà dit, le seul avantage que pourrait avoir un hacker avec mon site, serait de le faire fonctionner d'une façon inhabituelle, ou carrément inutile, c'est-à-dire qui ne lui apporte aucune des informations habituellement données par mon site.

Dans tous les cas, il n'y a strictement aucune moyen de faire du mal au serveur, si peu que ce soit.

Même mes pages de Statistiques, comportent tellement de paramètres, et l'ensemble des scripts intermédiaires nécéssaires pour y accéder ( fixer les paramètres et les conditions d'utilisation ), a une durée d'exécution suffisamment longue, pour qu'il soit impossible de surcharger le serveur, sur le plan du débit.

La seule et unique possibilité, serait une augmentation des consultations ( même automatisées ) telle, que ma limite de 40 giga-octets/mois soit dépassée... Mais actuellement j'en suis bien en dessous de 0,3 giga-octets/mois, alors...

Merci beaucoup pour tes conseils.

Amicalement.

Jean Francois Ortolo

 

[ortolojf]

Bon...
J'ai eu un peu peur que quelqu'un n'ait deviné mon password FTP, alors j'ai viré tout RobotStats, qui aurait théoriquement pu être hacké dans ce cas, et j'ai modifié le password...

Donc, plus de répertoire /robotstats/ , c'est comme ça, je suis content...

J'ai aussi viré toutes les tables de RobotStats sous le PHPMyAdmin de mon hébergeur OVH, comme ça pas de problème.

Je sais, c'est un peu suicidaire, j'ai obéi à une impulsion subite, mais bon...
J'ai simplement pensé qu'il était plus facile pour un hacker, de hacker mon site ou copier ma bdd en hackant RobotStats, qu'en hackant mon propre site.

Maintenant, finies les folies googleliennes, je n'ai plus que la barre de FireFox et celle de IE6, pour me donner des indications sur mon PR... Et aussi MyWri, merci beaucoup à Olivier !

Bien à toi.

Jean Francois Ortolo