Accueil > .Net, Développement, Sécurité > [SSI] En-têtes HTTP

[SSI] En-têtes HTTP

La sécurité par l’obscurité, ça ne marche pas.
J’ai souvent entendu ça.

Sauf que comme disais l’ami Sun Tzu, une bonne connaissance de soit ET de l’ennemi (la cible, dans notre cas) permet de vaincre.
Du coup, la phase de prise d’informations est importante.
Donc, à l’inverse, pour se défendre, il faut afficher le moins d’informations possibles.

Ce n’est pas directement de la sécurité, cela vise surtout à limiter la prise d’informations et donc de ralentir cette étape.
Eventuellement, si on a de la chance, décourager !

Dans ce billet, on va voir les bannières spécifiques au .Net.

 

Exemple

 

Prenons l’exemple du site de la MSDN : https://msdn.microsoft.com/fr-fr/default.aspx
Premier constat, c’est de l’aspx on peut supposer que c’est du WebForm, donc.

Ensuite, si on va dans un navigateur quelconque (Chrome dans mon cas), on peut faire F12 pour avoir les Developer Tools puis aller dans Network.
En regardant les headers, on peut obtenir ceci :
En-têtes HTTP

Plusieurs bannières sont importantes :

  • Server : indique le serveur web et sa version
  • X-AspNet-Version : indique la famille du Framework
  • X-AspNetMvc-Version : indique que c’est du MVC et non du WebForm
  • X-Frame-Options : pour lutter contre le clickjacking (note, le Server pour l’OWASP est Apache, c’est du PHP, donc probablement architecture LAMP)
  • X-Powered-By : bannières custom, souvent alimentée par le CMS ou autre
  • X-Powered-By: ARR/2.5 : c’est pour Application Request Routing

Du coup, on sait que c’est du MVC 5.1, dont le premier membre de la famille est sortit le vendredi 17 janvier 2014.
La dernière version stable est la 5.2.3 du lundi 9 février 2015. Donc, c’est une version pas à jour.
La famille MVC 5.1 tourne sur un Framework 4.5 minimum (de la famille de 4 comme la balise X-AspNet-Version nous l’indiquait).

Sur le Framework 4.5, il y a déjà 42 failles de sécurité connues (il y en a un peu plus pour la famille 4.5). Et une seule pour MVC 5.1.

Pour IIS, il n’y a pas de failles connues pour la version 8.0.

Si on prend l’exemple de la CVE-2014-0257, on peut voir qu’elle possède un module sur Metasploit. Ce qui veut dire qu’elle va être « simple » à exploiter.

Bien sûr, là, je n’ai pris qu’une seule source d’informations : CVE Details.
Mais en cherchant un peu plus, il y a sans doute moyen d’en trouver d’autres.

 

Supprimer les bannières

 

X-Powered-By

Il y a plusieurs moyens pour virer cette bannière.

Le premier est de le faire dans chaque Web.config :

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Le second, c’est de le faire sous IIS.
Il est possible d’avoir ce menu depuis la racine de IIS (la machine), sur le WebSite (Default Web Site par exemple) ou sur chaque application web.
X-Powered-By - IIS 01
X-Powered-By - IIS 02

X-AspNet-Version

Plus simple, mais dans tous les web.config :

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

X-AspNetMvc-Version

Là, ce n’est plus seulement de la configuration, il faut impacter le code.
Il est possible d’impacter en une seule fois, à partir du Global.asax :

        protected void Application_Start()
        {
            MvcHandler.DisableMvcResponseHeader = true;
        }

Server

Là aussi, il faut impacter le code.
Par contre, cette balise est ajoutée à CHAQUE requête…
Donc, si on se place sur du MVC, il peut être intéressant de placer ce bout de code dans un « contrôleur de base » qui hérite de Controller et est hérité par les controllers de l’application.

        protected override void OnResultExecuting(System.Web.Mvc.ResultExecutingContext filterContext)
        {
            filterContext.RequestContext.HttpContext.Response.Headers.Remove("Server");
            base.OnResultExecuting(filterContext);
        }

Note : pour ceux qui utilisent IIS Express en développement, il y a des chances que le code ci-dessous pose problème.
En effet, IIS Express ne positionne pas cette bannière. Tester si elle est présente pourra aider !

 

Conclusion

 

Comme on peut le voir, les modifications sont triviales à réaliser.
Cependant, cela permet de ne pas gentiment indiquer au premier venu les versions qu’on utilise.
Ça lui ferait gagner du temps pour cibler efficacement.
Donc, à l’inverse, sans ces informations, l’attaquant mettra plus de temps pour arriver à les avoir ou trouver comment exploiter l’applicatif.

Bon, après, vu l’exemple, c’est assez probable que ce sera un IIS sur un Windows Server avec un site en .Net.

Advertisements
Catégories :.Net, Développement, Sécurité
  1. Aucun commentaire pour l’instant.
  1. 02/03/2017 à 22:56

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 :