Suspension pour vulnérabilités

Les Pages Perso Chez Free

Par Al, le , dans En cas de problème.
Tags : Assistance, Usenet, Erreur 403, Suspension

Votre site est suspendu pour le motif « Site Vulnerability », avec un lien vers le site OpenBugBounty ? Qu'est-ce que cela veut dire ? Comment retrouver l'accès à votre site ?

Qu'est ce que OpenBugBounty ?

OpenBugBounty est un site Web dédié à la sécurité informatique, servant d'intermédiaire entre les découvreurs de failles de sécurité et les gestionnaires de site Internet. Il se concentre sur un nombre restreint de failles de sécurité : Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), Improper Access Control et Open Redirect.

Votre site contient donc une de ces vulnérabilités, et le lien qui vous est fourni sera d'un grand secours. Vous trouverez la chronologie du traitement de la vulnérabilité (de la communication à la suspension par Free), le type de faille et une URL démontrant la vulnérabilité rencontrée. Ces informations vous seront essentielles pour comprendre le problème et corriger votre site.

Comprendre les différentes failles évoquées

Voici quelques exemples de code très simple présentant les vulnérabilités évoquées ci-dessus, des bonnes pratiques pour les éviter, des procédures pour les identifier et les corrections à apporter à vos scripts pour y remédier.

1. Cross Site Scripting (XSS)

Cette vulnérabilité est due à un manque de contrôle des variabes envoyées par le client vers l'application Web. Il existe tellement d'attaques différentes qu'il est illusoire de vouloir présenter un seul exemple de code. Cependant, quelques règles de bonnes pratiques permettrons de bloquer la quasi totalité d'entres-elles : on retiendra simplement qu'il ne faut jamais utiliser les variables que l'utilisateur aurait pu modifier sans les vérifier et les nettoyer.

Liens utiles :

2. Cross Site Request Forgery (CSRF)

Le but de cette attaque est de permettre à un attaquant d'obliger un utilisateur à réaliser des actions définies (changement d'adresse de courriel ou de mot de passe, postage de liens ou de message…) à l'insu de l'utilisateur. L'attaquant peut ainsi prendre le contrôle de compte sur des services en ligne ou de toute un application Web (si le compte compromis et celui d'un administrateur).

Votre site est potentiellement vulnérable à cette attaque uniquement si vous disposez de formulaires (contact, inscription, commentaires, téléversement de fichiers…

Les méthodes les plus simples pour se protéger efficacement contre ce type d'attaque et de vérifier l'origine (le Referrer) de la requête POST soumise au serveur, de mettre en place et vérfier un token masqué dans le formulaire et, enfin, de limiter les cookies déposé à votre site uniquement (drapeau SameSite).

Liens utiles :

3. Improper Access Control

Il s'agit d'une gestion partielle ou erronée des droits d'accès à des ressources protégées.

<?php
 define ('acces_admin',false);
 if ($_SERVER['REQUEST_METHOD']=='GET'):
      acces_admin=true;
      if(CUser->IsAuthorized()):
        acces_admin=false;
      else:
        acces_admin=true;
      endif;
 endif;
 if (acces_admin):
      echo 'Vous ne pouvez pas venir ici.';
 else:
      echo 'Ceci est protégé.';
 endif;
 ?>

On comprend aisément ici que l'utilisation d'une requête avec la méthode POST permet de contourner la protection, qui ne s'appliquera que si la méthode utilisée est GET en raison de la ligne $_SERVER['REQUEST_METHOD']=='GET'.

C'est le même problème qui s'applique avec l'erreur fréquement répandue concernant l'identification HTTP basique :

AuthUserFile /.htpasswd
AuthGroupFile /.htgroup
AuthName "Secret"
AuthType Basic
<Limit GET POST>
require group managers
</Limit>

Dans cet exemple, seules les requêtes utilisant les méthodes GET et POST nécessite une authentification. Il sera ainsi facile à une personne mal intentionnée de détruire une ressource « protégée » par la méthode DELETE ou de rajouter un script malveillant via la méthode PUT sans avoir à casser la moindre protection, même si le site est statique.

Liens utiles :

4. Redirection Ouverte (Open Redirect)

Si vous ne vérifiez pas les variables utilisées dans une redirection de la page, il est aisé d'utiliser votre site pour envoyer un visiteur vers une ressources autre que celle voulue. Il s'agit du même problème que le Cross Site Scripting : l'absence de contrôle des variables et une confiance aveugle dans le visiteur.

<?php $page_url = $_GET['page'];
header('Location: '.$page_url); ?>

Le code présenté ci dessus utilisera la variable page, quelle qu'elle soit, pour rediriger le visiteur vers la ressource sélectionnée.

Requête du client : http://les.pages.perso.chez.free.fr/?page=login.php

<?php
$page_url = $_GET['page'];
header('Location: '.$page_url); ?>

Réponse du serveur :

…
Location: login.php
…

Requête du client : http://les.pages.perso.chez.free.fr/?page=http://example.com/ma/fausse/page/de/login.php

<?php
$page_url = $_GET['page'];
header('Location: '.$page_url); ?>

Réponse du serveur :

…
Location: http://example.com/ma/fausse/page/de/login.php
…

Ainsi, si une personne mal intentionnée souhaite rediriger vers une page malveillante – par exemple une page de phishing – un utilisateur qui se connecte à la section d'administration, il suffit de modifier la variable au vol (ou de poster un lien sur une autre page web ou via un courriel).

Cette vulnérabilité repose souvent sur l'ingénierie sociale ; son impact est relativement faible car un utilisateur attentif remarquera souvent la supercherie.

Liens utiles :

Corriger le site

Profitons de ce billet pour rappeler qu'il est important de sécuriser son site Web, afin de limiter les dangers auxquels vous, votre site et vos visiteurs sont exposés. Pour cela, vous devez suivre quelques règles de bases présentées ici : mettre en place des en-têtes de sécurité minimale, sécuriser vos scripts, mettre à jour régulièrement vos CMS, ne pas faire confiance aux données (r)envoyées par vos visiteurs, tester votre site contre les intrusions et les failles, utiliser des mots de passe différenciés et forts pour les différents services (email/FTP/SQL), etc.

Maintenant que vous disposez des informations importantes concernant la faille identifiée sur votre site, vous devez effectuer les actions suivantes :

  • Sur la copie locale de votre site, identifiez et corrigez le morceau de code ou le composant (CMS, plugin, extension, etc.) à l'origine de la faille ;
  • Vérifier également que d'autres failles ne sont pas présentes dans d'autres parties de votre site ;
  • Mettez à jour l'ensemble des scripts dont vous n'êtes pas l'auteur (CMS, extensions, plugins, frameworks, etc.) ;
  • Évaluez si la faille a été exploitée, et quelle est la portée de celle-ci. Prenez les actions nécessaires éventuelles, comme la recherche/suppression de code/ressources malveillant, le changement des mots de passe du compte et des utilisateurs du site… ;
  • Enfin, réalisez les pré-requis qui se trouvent ci-dessous.

Notez également qu'une fois que l'admin a bloqué le site (celui-ci retourne alors une erreur 403), il lance de nouveau une vérification sur le site de OpenBugBounty. Les sites listés – mais suspendus par l'admin – sont alors considérés comme faussement corrigés par OpenBugBounty, car ils ne représentent plus une menace pour le site ou ses visiteurs. Une fois le compte réactivé – et si rien n'est corrigé par le titulaire – le site repassera dans le statut non-corrigé sur le site de OpenBugBounty dans les jours qui suivront.

Les pré-requis pour les suspensions pour vulnérabilités

  1. Changement des mots de passe du compte, de l'accès FTP et SQL (éventuellement, si une base est active) ; si le compte suspendu est un compte principal, il est impératif de changer les mots de passe de l'ensemble des comptes secondaire rattachés à celui-ci et, pour plus de sécurité, tous les comptes dont vous êtes le titulaire ;
  2. Mettre en conformité avec les règles d'utilisation des pages perso l'ensemble des pages perso rattachées au compte principal touché (liste sur le forum Usenet des pages perso de Free ou sur ce site). Si ce pré-requis n'est pas effectué, l'admin n'étudiera pas votre demande ;
  3. Vérifier qu'aucun des comptes est orphelin (erreur 500 lors de la connexion à l'interface de gestion) ;
  4. « Passer les ordinateurs à l'antivirus », de préférence un antivirus robuste et mis régulièrement à jour. Voir 2 anti-virus ;
  5. Trouver et corriger les vulnérabilités mentionnées sur le site et rechercher les éventuelles autres failles ;
  6. Mettre à jour la copie locale du site, avec les corrections permettant d'empêcher l'exploitation de la vulnérabilité et vérifier qu'aucun morceau de code malveillant n'est présent dans les pages, dans la base de données et dans le fichier .htaccess et qu'aucun fichier douteux n'est également présent sur le site (une fois l'accès FTP rétablis) ;
  7. Demander la levée du blocage à Lionel, de manière claire, courte et précise en présentant ce qui a été fait, ce qui sera fait une fois l'accès FTP rétabli, en postant un message sur le forum Usenet de Free ;
  8. Une fois que l'admin a redonné la main, déployer la nouvelle version du site ou, selon la nature de la faille, supprimer l'ensemble des fichiers sur le serveur et les remplacer par ceux de la copie locale saine et sécurisée ;
  9. Ré-ouvrir l'accès en modifiant le fichier .htaccess à bon escient. C'est-à-dire, dans un premier temps, uniquement à vous-même, afin de vérifier que tout fonctionne correctement et que les vulnérabilités ne sont plus présentes. Ensuite seulement, vous pourrez réouvrir l'accès à tous les visiteurs.