Bonjour les Zéros :),
Ce matin je viens a vous car je voudrais vérifier si mon site ne contient beaucoup de failles ou non pour ensuite pouvoir les corriger !

Vous allez sûrement me dire "met mysql_real_escape_string() et htmlentities()", je sais , je le fait Il est possible que j'ai oublié a certain endroit. Mais suite a mon topic de hier j'ai de nouveau discuter avec la personne et il m'assur avoir accès a ma BDD sur PHPmyadmin sans le mot de passe et il me la prouvé en me donnant deux noms de tables que je l'ai demandé. De plus il m'assure qu'il fait partit de l'entreprise security focus a 20 sans étude (a 18 ans déjà et a 20 l'entreprise lui on attribue un diplôme di'ngenieur avec expérience de 5 ans au lieu de 2 ans!). Même si son histoire n'est pas vrai, comment a t'il pu connaitre toutes mes tables ? => il y a des failles sur mon site !

C'est après ce jour ci, je voudrais trouver toutes mes failles et les corriger ! Mais comment faire ? Embaucher un hacker ?

Ensuite j'ai remarque que avec mon hebergeur, j'ai des fichiers du nom d'error_log ( un truc du genre) et je sais qu'il enregistre toutes les erreurs.



Je sais que mon histoire peut paraitre bizarre, mais je commence a stresser en votant que mon site ai des failles et que je voudrais pas que après un an de travail celui-ci est anéantit !

Merci, cordialement _dark mort_

Salut,

Alors j'ai peut etre une idée est-ce que tu met tes infos pour te connecter à la base de données directement dans la page ? car si oui a partir du code source de la page on peut le savoir

Juste pour savoir, tu sécurise tout ce qui est numérique aussi (avec is_numeric ou intval par exemple). Car je rappelle qu'une injection SQL ne se fait pas toujours sur un formulaire et n'a pas toujours besoin d'un guillemet.

A partir de là et par tâtonnement, on peut trouver les noms de table et afficher ce que l'on veut.

Bonjour,

Si j'avais un conseil à te donner pour éviter de donner des indications sur un site en production c'est de désactiver l'affichage des erreurs php et dans les requêtes de ne pas mettre les mysql_error() simplement un or exit('erreur sql requête n°..') garder cela simplement en débogue.

J'ai appris qu'une fonction permettait de modifier la gestion des erreurs par défaut (set_error_handler)

Je pense que tu pourrais modifier cette gestion à ta manière (envoie des erreurs par mail par exemple)

Même si un jour par malheur tu te fait hacker ton site ne sera pas "anéanti", car en accédant a ta BDD, il peut faire quoi ? Tout supprimer, dans ce cas tu récupère tes données avec ton Backup SQL (normalement la plupart des hébergeurs le font).

Dans le pire des scénario il pourrait choper tes mots de passes, et si jamais c'est le même dans tout les sites ou tu t'est inscrits, là c'est la catastrophe

Et de toute manière je vois pas trop comment il peut chopper tes identifiants, c'est complètement absurde... On peut foutre en l'air une BDD à cause des injections SQL, mais ça se saurait si il existait des failles avec lesquelles on peut accéder au mot de passe de la BDD d'un site.

En gros protège bien tes POST, tes GET, et tout ce que l'utilisateur peut modifier qui interagi avec ta BDD.

Effectivement il n'aurait accès qu'aux infos de la base de données en question.

J'ai déjà tenté de récupérer les identifiants de connexion mais je ne suis pas arriver avec des requêtes SQL (le login, y a moyen, le pass j'ai pas trouvé).

Par contre et là ça peut faire beaucoup plus mal, il m'est arrivé de trouver le login/pass d'un site (par la même méthode que que ton hacker à mon avis), et que le site d'administration ne soit pas fort protégé, or il permettait l'envoi de fichier, sur lequel il y avait une petite protection très facilement contournable.

Sans me vanter de quoi que se soit, ce n'est plus 1 mais plus de 40 sites qui auraient pu tomber (et là, je pouvais modifier/voir/supprimer le code source du fichier (NB: Oui c'est possible, certaines backdoor sont faites pour). Et dans le code source, bien entendu: les identifiants de connexions (serveur, login, et pass).

Et pourtant mysql_real_escape_string était utilisé, et htmlentities aussi.

Donc là, c'était le cumul de 2-3 failles qui devenait vraiment dangereux.

2-3 lignes de plus aurait largement suffit à empêcher tout ça, il faut bien vérifier tout ce que l'utilisateur peut modifier même si il s'agit de l'administrateur du site.

Dans ton cas, je crois que ta seule erreur pour ce coup là à été de ne pas avoir vérifié les variables numériques du genre index?php?id=1.

Utilise des fonctions comme intval() ou is_numeric, et tu sera déjà plus tranquille.

SI t'as besoin de plus d'explications, y a pas de soucis tu demandes. Et puis si il t'a prévenu, dis toi bien qu'ils ne font pas tous la même chose et que c'est bien sympa de sa part. ;-)

Oui, il m'a pas vraiment prévenu, c'est que je lui donnait mes fichiers pour qu'il corrige les failles et comme ça il pouvait copier mes codes pour son site. Mais dit que si j'accepte pas, i ne ferais comme même

Cordialement _dark mort_

Logiquement même en utilisant les fonctions is_numeric() ou intval() quand on passe un id en GET ne protège pas contre les failles.
Car en utilisant uniquement mysql_real_escape_string() on se protège des injections. Vérifier que c'est une valeur numérique avant de faire la requête, c'est plus "propre".
Je ne suis pas un fin connaisseur, mais je pense qu'en utilisant juste mysql_real_escape_string() et htmlspecialchars() (ou leur équivalent), rein de grave ne peut arriver (du moins si c'est juste enregistrer ou afficher des données en SQL).
Après c'est mieux de contrôler tout ce qui se passe : vérifier le type de données, si c'est pas trop long/trop court, si l'utilisateur n'essaie pas de forcer en postant plusieurs fois dans le même formulaire, etc... (faut faire gaffe aux bots aussi )

mysql_escape_string échappe ce qui se trouve ENTRE GUILLEMET, or si ton ID n'est pas entre guillemet, cette fonction ne fera absolument rien. Faudra que tu m'explique comment tu pourrais faire une injection SQL avec uniquement des chiffres (quoique j'ai déja vu des trucs assez imbuvables XD).

EN gros je suis prêt à parier que darkmort avait une page de ce genre:

article.php?id=1

Requete: SELECT * FROM articles WHERE id = 1

Bah suffit de faire:

article.php?id=9999999 UNION SELECT login,pass FROM admins #

L'article 9999999 n'existant surement pas, ça sera la seconde ligne, donc le login et pass qui s'afficheront. Aucun guillemet dans cette requête.

Si tu utilise des caractères:

$lavaleur = mysql_real_escape_string(htmlentities($_GET['valeur']));

Si il s'agit de valeurs numérique entières:

$lid = intval($_GET['id']);


Avec ça, faut déjà être fort pour injecter du code.

Pour les bots, c'est autre chose aussi effectivement (et bien chiant !).

C'est marrant autant de posts sur le sujet et toujours le même fonctions pourris mises en avant. intval ou (int) ne remplaceront jamais une validation correct des informations. Dit autrement, transformer n'importe quoi en 0 ne fera pas mieux fonctionner ton système.
juanito21: +1

Tracker.

Alors il faut faire quoi ?
Parce que moi j'utilise (int), et si la valeur est à la fin fausse, je donne un message d'erreur à l'utilisateur.

Perso j'utilise plus souvent is_numeric, pour la simple et bonne raison que je peux si la valeur entrée est fausse, exécuter une fonction récupérant certaines infos utiles mais c'est certes plus long à écrire.

Tracker, sans vouloir jouer mon rabat joie, en quoi ces fonctions sont pourries ? Je veux un ID, je vérifie que j'ai bien un ID si c'est pas le cas je le transforme, on veut des lettres, je vérifie que j'ai bien des lettres. Je dis pas ça méchamment hein ^^, juste que j'aimerai comprendre en quoi ça n'est pas fiable (et surtout pourquoi... ;-) ).

Je suis d'accord avec Tracker meme si je continue à faire du intval() pour mes ID.

J'aime pas trop is_numeric() car il valide pas grand chose, tu peux mettre +0123.45e6 et il acceptera.

La solution de Tracker je pense est de passer par des expressions régulières