Accueil > .Net, Développement, Sécurité > [SSI] Fuites d’informations

[SSI] Fuites d’informations

J’avais déjà parlé des En-têtes HTTP comme étant une potentielle fuite d’information.
Mais il y en a d’autres possibles. Dans le billet d’aujourd’hui, on va en voir d’autres.

 

Commentaires

 

Le problème avec les commentaires, c’est qu’ils sont souvent placés pour aider les développeurs quand ils arrivent ou reviennent sur un applicatif.
Mais si ces commentaires ont une valeur pour les dévs, ils peuvent aussi avoir une valeur pour des personnes moins bien intentionnées.
Sont susceptibles d’être problématiques : les TODO, HACK, FIXME ou les détails du genre « Code JS ajouté le XX/XX/XX empêcher les XSS sur le formulaire ».
Chacun pourra donner des détails sur ce qui a été fait ou ce qui devrait être fait (et donc ce qui n’est pas fait).

Dans l’idéal, une page HTML ne devrait pas contenir de commentaires. Déjà pour éviter de donner des informations, mais aussi pour le simple poids de la page (y en a qui écrivent des romans, pas des commentaires…).

Pour régler ce soucis, une relecture de code pourra aider.
Mais un bête minifier, pour le Javascript, pourra aussi faire l’affaire puisqu’ils ont tendance à virer les commentaires (du moins pour les fichiers à part, le Javascript/CSS dans les pages directement n’est pas traité).

 

Exceptions non gérées

 

Dans aucun cas il ne faut laisser la page d’erreurs classique des Framework.
Dans le cas de ASP.Net, c’est la fameuse Yellow Screen Of Death (en).
Pour voir le type d’informations données, il suffit d’aller sur Google Images.

Pour cela, il suffit simplement d’ajouter du paramétrage dans le Web.config :

  <system.web>
    <customErrors mode="On" defaultRedirect="~/Home/Error">
      <error statusCode="404" redirect="~/Home/Error404" />
      <error statusCode="403" redirect="~/Home/Error403" />
    </customErrors>
  </system.web>

Cependant, MVC va également peupler un model du type HandleErrorInfo.
Autant il peut être utilisé en développement, autant en production, il ne faut pas l’utiliser dans les vues !

Afficher ce genre de choses à l’utilisateur, c’est comme de tendre le bâton pour se faire battre.

Faire remonter des informations techniques détaillées à l’utilisateur pourra aider un attaquant à réaliser certains types d’attaques (par exemple : injections SQL).

 

Enumération d’utilisateurs

 

Autre problème, l’énumération d’utilisateurs.
Là, sur quelque chose de plus complexe.

L’énumération d’utilisateurs va souvent s’appuyer sur la page de connexion ou la page de « mot de passe oublié ».

Pour pouvoir réaliser une énumération, il va juste falloir que le système réagisse différemment si l’utilisateur existe ou non. Et c’est tout.

Prenons l’exemple d’une bête page de mot de passe oublié.
Si l’on doit entrer un nom de compte pour recevoir un email avec la procédure (cas fréquent de ce genre d’écran), il est tout à fait possible que deux cas soient gérés :

  1. L’utilisateur existe
  2. L’utilisateur n’existe pas

Si les deux messages sont différenciés (du type « Un mail vous a été envoyés. » et « Cet utilisateur n’est pas connu. »), alors il est possible de tenter une attaque par force brute, une attaque par dictionnaire (utilisé pour les mots de passe, mais exploitable aussi pour les noms de compte), voir de tester directement les comptes par défaut (admin, administrator, etc. ; et les localiser, ex: administrateur).
Du fuzzing (la version anglaise est plus complète) peut aussi être utilisé.

Du coup, utiliser un message d’erreur très générique est bien plus pertinent.
« Le couple nom de compte et mot de passe ne correspond pas », « Si le compte existe, vous recevrez un email expliquant comment réinitialiser votre mot de passe. », etc.
Bien sûr, cela va être un peu plus obscure pour l’utilisateur lambda qui aurait préféré qu’on lui dise que ce n’est pas le bon mot de passe ou le bon nom de compte…

Tout dépend de savoir si c’est la sécurité de son SI ou le confort des utilisateurs qui prime.

 

Enumération de pages

 

L’énumération de pages va fonctionner de façon similaire à l’énumération des utilisateurs.
Ici, il va falloir tester des URLs différentes pour avoir un retour. Si c’est un 404 (Not Found), la page n’existe pas. Mais si c’est un 401 (Unauthorized) ou un 403 (Forbidden), c’est que la page existe et est protégée (par une authentification).

Par dictionnaire, on pourra tester des trucs du genre (pour MVC) ~/Admin, ~/User/Create, ~/Products/Edit…
Utiliser un fuzzer (pouvant être spécialisé) pourra aussi permettre de trouver des ressources statiques intéressantes (les archives de bakcup, des txt d’extraction de données…).

Le but ici est de faire un inventaire (reconnaissance), puis d’identifier les pages qui peuvent être attaquées par la suite.

Ici aussi, pour gérer ce problème, il faut savoir ce qui est à privilégier.
Par exemple, Google pénalise les soft 404.
A titre personnel, je préfère renvoyer une 404 à la place des 401, 402, 403, avec un message standard lié (du genre « La page n’existe pas. ») pour la seule raison qu’elle n’existe pas pour la personne qui la demande (ou, c’est capillotracté, j’assume).

 

Robots.txt

 

Le fichier robots.txt sert à l’indexation des moteurs de recherche.

Ce fichier indique aux robots d’indexation ou crawler de ne pas indéxer certaines ressources.

Mais toute ressource cachée possède une valeur.
Ainsi, il est possible d’y voir des apis, des répertoires cachés…

Le mieux reste quand même de ne pas exposer ces pages sur internet…

Advertisements
Catégories :.Net, Développement, Sécurité
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :