C'est une très mauvaise idée point de vue sécurité d'utiliser le IP comme identifiant. Si tu te connectes sur un réseau publique, n'importe qui sur ce réseau à accès à ta page d'administration sans se connecter après.

Quelques corrections, ton code ce n'est pas du .NET (.NET c'est la plateforme de Microsoft pour faire du C#, F# et VB.NET). Ce n'est pas du AJAX que tu utilises pour faire l'upload, c'est juste une passe-passe pour faire l'envoie de données dans une autre page caché.

"Avec ce script je peux envoyer des mail en html sur hotmail et gmail sans qu'ils soient considérés comme spams"

Ce n'est pas tout à fait vrai, c'est en fait beaucoup plus complexe que ça.

Ce qui fait en sorte qu'un message est considéré comme SPAM dépend de plusieurs facteurs dont certains sont théoriquement impossible à contrôler. Dans ceux des contrôlables, il y a :

- Le contenu du message. Si le message est HTML, la présence de certaine balise (img, script, etc.) peut être banni. Il est préférable d'utiliser du HTML simple avec les données des images encodé dans le HTML. Aussi, certains mots clés sont bannis (inutile d'en faire la liste).
- Les entêtes, le paramètre From est généralement analysé de la façon suivante par les serveurs POP. On récupère le domaine et on vérifie si le IP d'où le message a été envoyé correspond au IP du domaine. Si tu envoies du serveur xxx.com, tu peux mettre un adresse d'origine xxxxx@xxx.com, mais pas xxxxx@xyz.com parce que (IP de xxx.com != IP xyz.com). Si ce test échoue les messages s'en vont généralement directement dans la boîte de SPAM.

Dans les incontrôlable :

- Le serveur, si le IP du serveur a été identifié comme serveur envoyant du SPAM tous les messages qui seront envoyé de ce serveur seront identifiés comme SPAM.
- Les filtres des serveurs, les serveurs ont généralement des filtres complexes et peuvent identifier des messages comme SPAM même s'il ne le sont pas. Le meilleur exemple seraient des messages automatisés d'alerte. Les serveurs peuvent identifier ces messages comme SPAM étant donné la similarité et la fréquence qui peut être élevé.

Au final, il ne s'agit pas de simplement utiliser un script pour que les messages envoyés soient considérés comme normal. Il y a beaucoup de truc à considérer.

ghuysmans99 -> mysql_query ne permet pas d'avoir plusieurs requêtes en même temps, ça va juste de sortir un exception si tu essaies de faire ça.

masternico -> Le problème c'est que les injections SQL ne servent pas juste à contourner un login. Tu laisse carrément un accès à n'importe qui de faire des requêtes select. Tout dépendant de la base de données que tu utilises, ça laisse la possibilité d'avoir une fuite de ta base de données au complet.

Exemple d'entrée qui pose problème :

' UNION ALL SELECT * FROM INFORMATION_SCHEMA INTO OUTFILE 'chemin/Accessible/Du/Net.txt

Exemple de problème :

<?php
$sql = 'SELECT * FROM Infos WHERE id="' . $tonChampFiltrer . '"';
?>

Si j'envois comme valeur : 1" AND 1 LIKE 0 UNION ALL SELECT * FROM Users WHERE "1" LIKE "1, ton truc n'a absolument rien filtrer et la requête passe.

Aussi des entrées avec des caractères spéciaux peuvent être normal, il faut simplement bien les prendre en charge. Ce genre de contrôle peut exaspéré les utilisateurs d'un site, les caractères spéciaux que tu «bannis» peuvent quand même être utiliser de façon normal par des utilisateurs.

L'idéale comme solution c'est d'utiliser les requêtes paramètrées avec PDO ou d'utiliser des librairies qui prennent en charge des requêtes paramètrées pour mysql (si PDO n'est pas disponible). Le problème, à la source, est que les données sont mises directement dans la requête et qu'ils peuvent la modifier, il faut donc essayer qu'il passe ailleurs que directement dans la requête. C'est pour ça que les requêtes paramètrées restent et resteront toujours la meilleur solution à envisager pour sécurisé une requête SQL.

Honnêtement c'est très mauvais comme approche, parce qu'au lieu d'essayer de régler le problème à la source, tu fais simplement quelque chose qui va être un peu plus dur à exploiter, mais qui est tout de même exploitable.

Pour régler un problème en sécurité informatique il faut regarder pourquoi un code est exploitable et non pas quelles sont les entrées qui peuvent exploiter la faille.

Aussi le problème des caractères spéciaux ' et ", s'applique pratiquement uniquement lors de requête SQL. Dans l'exemple que tu montres il n'y a aucune requête SQL qui est effectuée avec les paramètres entrées par l'utilisateur, donc il n'y a aucune raison de se méfier des caractères spéciaux.

Le fichier configuration.ini se trouve à la racine du zip ... Tout ce que tu as besoin de modifier normalement dedans, c'est le nom d'utilisateur/mot de passe de ta base de données et le nom du schéma dans lequel se trouve les tables (par défaut c'est chat).

C'est un problème d'encodage, si tu as modifié les pages assure-toi que tu les enregistre de nouveau en UTF-8 ou utilises les entités HTML pour encoder les caractères spéciaux (ex.: &#160;)

Le script est disponible sur leur site web, normalement tu devrais trouver l'information que tu as besoin ici :

http://www.phpsimul.fr/viewforum.php?f=71