voila
apres tu peu regarder du coté de extract
d'ailleurs comme $_POST est une liste, si c'est bien fait tu pourrais direct faire

$stmt->execute($_POST);

mais bon c'est pas a faire et en plus ta le coup du CV derrière mais en manipulant bien les tableaux ca se fait bien

Héhé merci bien, c'est vraiment sympa de m'avoir aidé.

Je vais appliquer le code la semaine prochaine si j'ai le temps, histoire de modifier chaque page.

Encore merci pour l'aide ^^

hey oh j'hallucine lolll

Stealth, le mec se fait hacker et tu lui conseilles la fonction extract()

N'utilise pas cette fonction, ton code est déjà bien assez insécurisé.

De plus ton script est complètement incorrect, la faille vient de ton formulaire upload et non d'une faille Sql.
Mais c'est une bonne idée de sécuriser tes requêtes...

Il faut refaire ton code upload.
Sers toi par exemple du tutoriel plus bas:
http://antoine-herault.developpez.com/t ... hp/upload/

Et suis les consignes du tutoriel plus haut à la lettre

Et une attention particulière sur le code de vérification des extensions autorisées...

hey oh j'hallucine lolll

Stealth, le mec se fait hacker et tu lui conseilles la fonction extract()

ouai ta raison c'est pas top

Il faut refaire ton code upload.
Sers toi par exemple du tutoriel plus bas:
http://antoine-herault.developpez.com/t ... hp/upload/

Et suis les consignes du tutoriel plus haut à la lettre

Et une attention particulière sur le code de vérification des extensions autorisées...

la par contre non le tuto est obsolète

De plus ton script est complètement incorrect, la faille vient de ton formulaire upload et non d'une faille Sql.

ou ?

je ne le trouve pas si obsolète que cela, et de toute façon il est bien plus propre que son code...

Je voulais étudier son code et corriger, mais toutes les lignes partent dans tous les sens, cela m'a découragé.

Ah sinon je n'avais pas vue que c'était une version Wordpress non mis à jour, donc le problème vient surement de là aussi.

Sinon, si il a reçu une injection de code, et apparemment ce même code n'est pas généré à partir de la Bd, donc le problème est ailleurs.
Mais je le répète, c'est une bonne idée de sécuriser les requêtes, sauf que c'est Wordpress, donc faudrait tout refaire...
Genre bon courage..

je ne le trouve pas si obsolète que cela, et de toute façon il est bien plus propre que son code...

il est plus obsolète que le sien, rien que le coup pour allé chercher l'extension et le renommage du fichier c'est immonde

Sinon, si il a reçu une injection de code, et apparemment ce code n'ai pas généré à partir de la Bd, donc le problème est ailleurs.

ouai comme il a mis partout des htmlentites meme dans la base ca n'aurais pas du afficher ca (a moins qui fasse un html_entity_decode) a voir

Nan nan je ne fais pas de "html_entity_decode" .

Puis mes lignes ne partent pas dans tout le sens, je m'y retrouve plutôt facilement .

Je ne pense pas réinstaller wordpress, je vais essayer d'en trouver un autre, des conseils ? Et le jour ou j'ai aperçu le code dans mes pages, le blog ne fonctionnait plus du tout.. D'où le fait que j'ai penché pour le blog.

Sinon vous connaissez peut être des logiciels qui permettent de tester un peu la sécurité de son site ? Je connais SQL Inject Me, mais il ne fonctionne pas sur Firefox 3.6.3

Je ne suis pas d'accord, la structure du code en elle-même est bien plus propre.
Ensuite les fonctions utilisées sont discutables, il est vrai, mais elles fonctionnent parfaitement encore et donc cela n'a rien d'obsolète.

De plus l'utilisation par exemple de filesize() est préférable.

Pour indiquer de travailler en utf-8 pour ta connexion pdo il y a un exemple dans la première note de cette page

Sinon dans ton premier code il ne fallait pas utiliser addslashes sur tes données avant d'utiliser mysql_real_escape_string() puisque cette fonction remplace (en mieux) la fonction addslashes.

Enfin bon tu es passé à pdo et des requêtes préparées donc pas besoin d'utiliser la fonction quote de pdo (équivalent de mysql_real_escape_string() pour l'extension mysql).

Mais dans tous les cas, quand tu utilises mysql avec mysql_real_escape_string() ou l'équivalent avec mysqli ou quote pour pdo, ou quand utilise des requêtes préparées avec mysql ou mysqli ou pdo tu ne dois jamais utiliser addslashes avant.

A part ça il est très peu probable que le piratage ait eu lieu avec une injection mysql même avec ton premier code. Cherche la faille ailleurs. Car là une ajoute une couche de blindage à un porte déjà blindée alors que tu as peut-être des murs en carton.

Ah oui au passage, quand tu utilises pathinfo pour trouver l'extension d'un fichier, ce n'est pas plus sécurisé que la méthode du tuto indiqué par Droke.

Dans les deux cas si tu as un fichier .exe ou .php que tu renomme .txt, l'extension trouvée sera txt

Une meilleure méthode serait d'utiliser finfo_file (si possible).

Tout à fait AB =)

Je ne me souviens plus exactement, j'avais regardé ça il y a quelques temps.
Il existe des moyens pour s'assurer du type du fichier sans se fier exclusivement à l'extension.
C'était peut-être finfo_file ou quelque chose d'autre, je ne sais plus.
Je n'ai pas poursuivi plus loin car pour le moment je n'ai aucun besoin d'un système d'upload.

Sinon Ariochs, je pense que l'on a trop peu d'éléments pour rejeter la faute sur Wordpress.
D'après moi, notre propre code est souvent la cause, ou le mélange de notre code à un code déjà existant qui peut rendre tout le système instable...
Ceci est vrai aussi pour les thèmes, qui ne prennent pas toujours les dernières fonctionnalités ou qui ne sont pas à jour: eux.
C'est encore pire pour les extensions...
Pour résumer, moins on rajoute de fichiers non inclus dans la version de base, plus on a de chance d'avoir un système stable.

Te conseiller sur un autre système de blog ?
Eh bien cela dépend des gouts de chacun, tout ce que je peux dire c'est que Wordpress est un bon système.

Quoi qu'il en soit, il est primordial de mettre à jour les logiciels que l'on utilise .

Merci pour vos informations.

Malheureusement je m'y connais trop trop peu dans le codage pour savoir si j'ai un site en carton ou non xD. Donc comment le savoir ?

Surtout que la je revois le code de A à Z pour avoir quelque chose de mieux, et compatible en w3c aussi.

Malheureusement je m'y connais trop trop peu dans le codage pour savoir si j'ai un site en carton ou non xD. Donc comment le savoir ?

Surtout que la je revois le code de A à Z pour avoir quelque chose de mieux, et compatible en w3c aussi.

Ben c'était pour dire que le hack n'a pas pu se faire sur les lignes que tu nous a montrées (c'est très improbable). Donc c'est inutile d'essayer de renforcer encore ce bout code.
Le problème vient certainement d'ailleurs :
Problème d'include non vérifié, mots de passe trop facile à trouver, accès à un espace administrateur depuis un endroit non sécurisé (depuis un proxy par exemple)... , mot de passe directement volé sur ton ordinateur à l'aide d'un logiciel malveillant (ou autrement), mauvaise gestion de l'administration du serveur etc... tout cela peut poser autant de problème que l'injection sql dont normalement tu étais protégé d'après ce que tu nous a montré.

Il faut croire que le problème ne venait pas de moi ^^
http://www.h-online.com/security/news/i ... 96628.html

Arf et mauvaise nouvelle si l'installation de la dernière version de wordpress ne garanti pas d'être protégé du hack (si j'ai bien compris).

Y'a quelques temps c'est joomla qui avait été attaqué...