Problème avec https: // url allant à un location inconnu

Nous avons un site Web (ASP.NET/Plesk 9.5.5) auquel on peut accéder facilement via l'URL ordinaire ( http://example.com ).

Cependant, lorsque vous accédez au site via https : //example.com, le site affiche l'avertissement du certificate de security invalide, ce qui est bien puisque nous n'avons pas de certificate SSL. Si j'ajoute une exception, je suis envoyé à un site complètement distinct qui héberge apparemment un script de logiciels malveillants (je suis toujours sur https://example.com ).

En raison de cela, Google a signalé que le site était dangereux.

Je ne peux rien find dans le panneau Plesk qui aiderait à résoudre ce problème, et autant que je puisse dire que ces files n'existent pas sur notre server. Comment puis-je savoir où le lien https: // m'envoie? Je ne suis pas familier avec le DNS, mais c'est ce qui cause ce comportement?

2 Solutions collect form web for “Problème avec https: // url allant à un location inconnu”

La raison pour laquelle cela se produit est que votre fournisseur d'hébergement possède plus d'un (probablement des centaines ou même des milliers) de sites Web tous partageant la même adresse IP. C'est parfaitement correct et normal.

Catch est que le SSL "normal" ne peut prendre en charge qu'un seul site Web par adresse IP. Ainsi, chaque site Web qui partage cette adresse IP affichera le même site sur https:// .

Il semblerait que le HTTPS:// par défaut HTTPS:// site hébergé par votre hôte sur votre adresse IP présente cette vulnérabilité.

Il n'y a rien que vous puissiez faire à ce sujet; C'est juste un piège pour l'hébergement partagé. Comme l'indique Somantra, vous devez contacter votre fournisseur d'hébergement.

Cela semble être une injection xss d'injection javascript qui exploite une vulnérabilité dans plesk.

Selon l' article que vous avez lié, l'injection semble append le code aux files js existants.

Je suggérerais fortement de suivre les conseils des auteurs pour contacter votre fournisseur d'hébergement concernant l'attaque et modifier vos passwords.

Il y a un patch pour la vulnérabilité, alors je ferais cela aussi longtime que possible.

Cela n'empêchera pas tout cela, mais pour répondre à votre question sur la détermination de l'URL de redirection:

Utilisez netstat pour observer les tentatives de connection au site xss apparent.

J'aime utiliser netstat comme ceci:

netstat -noab >> out.txt

Ensuite, ouvrez le file out.txt lorsqu'il finit et searchz ce dont vous avez besoin.

Vous pouvez supprimer une partie de l'encombrement de sortie par quelque chose comme:

netstat -noab | find / i ": 80"

ou

netstat -noab | find / i ": 443"

  • Impossible de se connecter au serveur Tomcat à l'extérieur, [fermé]
  • 123-reg DNS ne fonctionne qu'avec des sous-domaines
  • Rinçage du cache DNS dans Ubuntu
  • Dnsimple redirige l'URL HTTPS vers une autre extension en utilisant un certificate SSL unique
  • Éviter les timeouts d'attente DNS lorsqu'un server DNS fonctionne
  • Quelle est l'adresse IP appropriée pour le DNS?
  • Comment vérifier les loggings DNS actuels avec Amazon Route 53?
  • problème d'administration du server: problème de zone avant
  • Simuler différents domaines sur la même machine
  • Comment redirect un domaine
  • Proxy inverse du sous-domaine IIS basé sur le nom de l'hôte
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.