Salut, y aurait juste un petit message à corriger, même si c'est pas trop grave   

Code:

Vous devez faire rentrer la réponse sous la forme : verifpr5.php?solution=nombre

Ce serais mieux de remplacé "nombre" par "mot".

Ne m'en voulez pas j'ai le défaut (ou la qualité ?) de vouloir toujours trop bien faire 

Tout au début j’utilisais IE (mais oui), mais dès que j'ai commencé à m'interresser un peu plus à l'informatique j'ai pris Firefox, il y a quelques années j'ai opté pour Chromium OpenSource aussi, et plus rapide que Firefox à l'époque (et en apparence plus léger). JE dis en apparence parce que ça fait un bout de temps que je me demande qui bouffe toute mes ressources, et je me suis rendu compte que Chrome créait un process pour chaque onglet, et que un process pouvait prendre entre 100 et 500 Mo de RAM ... et en plus un processus "nacl_boostrap_helper" me croquait invariablement 1GO de RAM, et après mainte recherche je me suis rendu compte qu'il appartenait à Chrome (à propos de cette fuite c'est sur Ubuntu ou Debian, pas sur win).

C'est pourquoi je suis repassé à Firefox il y quelques semaines à peine, et là j'ai remarqué un très grosse amélioration depuis quelques années, surtout niveau légèreté (et un peu vitesse). Et puis bon, Firefox à combler son retard face à Chrome en Intégrant une fonction "Examiner l'élément", et qui m'a épaté avec sa vue 3D d'une page HTML 

Vraiment, bravo aux développeurs de Mozilla, ils ont au moins rattrapé Chrome pour ne pas dire dépasser !

[AND VERSION() > '5.1']

Bonjour, j'ai lu sur plusieurs pages, dont celle-ci en particulier mais plein d'autre aussi, que quand certains mots clés étaient filtrés (UNION ou SELECT) par exemple, on pouvait contourner ces filtres en "coupant" les mots, soit en ajoutant des espaces au milieux, soit en les coupant par /**/ par exemple. Vous pouvez voir cela à la fin de la partie sur "la fonction CONV" sur le lien donné plus haut.

Malheureusement, j'ai fait des tests en local et ça ne marche pas, mais vraiment pas du tout !
L'article serait-il trop ancien ? MySQL aurait-il interdit ce genre de syntaxe depuis ?
L'article paraît pourtant s'appliquer à MySQL 5.1 ou plus, car ce numéro de version apparaît lusieurs fois dans la page (par exemple AND VERSION() > '5.1' etc.

Voilà ... je n'ai pas trouvé grand chose à ce propos sur la toile ... et ça m'étonnerai que cette page est raconter des sornette, surtout qu'elle n'est pas la seule à donner ce petit truc. L'hypothèse la plus probable est donc que MySQL est bloqué cette possibilité depuis ...

Grrr, elle est clairement plus compliquée que la précédente  
Et en plus, j'ai l'impression que le mot de passe est absolument ignoble, si c'est bien ce que je crois il fait douter l'ataquant de lui-même  

Le pire c'est que j'y suis presque, je bloque sur une toute bête erreur dans mon script  

EDIT

Après 5h (sans rire), j'ai fini par trouver le problème technique ... j'en parlerai dans le afterward sinon ça serait donner la réponse. Mais bon, sinon j'ai trouvé presque tout de suite 

rhôôoo quel idiot je suis, c'est mon problème, souvent je me focalise sur un truc et je voit pas le trou béant qui est à côté ^^
Et dire que je viens de trouver en 5 sec exactement  
C'est pas pour rien que laisser reposer est important.

Merci beaucoup  

Au fait oui bien s je ne me limite pas à cette page, mais elle à l'avantage de décrire la plupart des exploitation possibles et imaginable, et ce en français ... pas que je sais pas l'anglais mais je suis quand même plus à l'aise dans ma langue natale  

EDIT

épreuve terminée, oui en fait c'était pas beaucoup plus dur que l'autre à part le filtre qui était d'ailleurs pas compliqué 
Très réaliste encore une fois, merci beaucoup !

Salut,
pour le coup ça fait plusieurs heures que je sèche ...
La faille viens évidement de la connexion, mais je n'arrive même pas à détecter la faille.
Je m'explique, avant d'aller plus loin, je cherche d'abord à vérifier l'existence de la faille (sait-on jamais :mdr: ) et à définir son type ... mais là je n'arrive même pas à provoquer la moindre erreur ... si par exemple il n'y a aucune protection, une apostrophe ou un guillemet fera inévitablement une erreur ... Après, l'erreur est susceptible d'être capturé et hypocritement cachée ...   Dans ce cas ... le seul moyen est de faire des test à l'aveuglette, avec un SLEEP par exemple pour prolongé la durée et vérifier ainsi l'existence de la faille, mais je n'ai pas réussi. J'ai tout essayé, apostrophes guillemets, en dur ou en hexa en passant par l'urlencode et le double url encode, mais rien à faire ...

En bref, je n'ai pas encore détecté la faille (autant dire que j'ai rien fait) ... C'est à peu près la première fois que je fais une injection à part celle du "toujours réfléchir avant d'agir", mais sur ce coup on avait le code, et les erreurs n'étaient pas capturées (je parie que c'est le cas ici   ).

J'ai rassemblé toutes les méthodes que je connais, mais voilà où j'en suis ... peut-être n'ai-je pas les bonnes méthodes ?
Pour info j'ai appris le plus gros sur cette page qui est hyper-complète : http://venom630.free.fr/geo/tutz/securite_informatique/tour_d_horizon_sur_les_sql_injections_nikloskoda.html#2.3 mais qui n'explique pas énormément les moyens de détections ...

Merci d'avance.

EDIT

ah oui au passage, j'ai remarqué quelque chose de curieux dans la redirection quand on essaye d'afficher une page inexistante, le navigateur charge la page une fraction de seconde avant de redirigé ... j'ai pensé à une redirection js ou quelque chose du genre, mais apparemment non ... j'ai alors été plus loin en faisant un telnet, et j'ai reçu une erreur : HTTP Error 501 Not implemented. Apparemment pas de faille de ce côté mais ça m'intrigue quand même ...

A propos de l’exploitation ... j'ai été étonné qu'une "double requête" du type

Code:

SELECT * FROM table;INSERT INTO table(col) VALUES(val); 

provoque une erreur de syntaxe alors que chez moi elle s'exécute sans peine. Je ne vais pas m'acharné trop longtemps sur ce point, mais cela m'intrigue quand même ... serais-ce du as-ce que ma version de MySQL n'est pas la même. ça m'étonnerai que ça vienne de ça ... Peut-être il y a-t-il une sécurité en plus qui n'est aps dans le code source, pour éviter par exemple qu'un petit malin s'amuse à faire un DROP TABLE 

Je viens de m'acharner à contourner les addslashes, et pour finir je commence à croire que ce n'est pas la bonne méthode ^^ Ma question ne demande pas d'aide, je voudrais juste avoir confirmation que les addslashes ne peuvent être contournés uniquement quand la base de données est dans un encodage excentrique genre GBK  

Et ce n'est apparement pas le cas ici  , c'eut été trop simple  

Merci.

EDIT

Le pire c'est que la solution était bien plus simple que ça 
Enfin ça m'aura au moins appris quelque chose et c'est le principal !