Trucsweb.com

Trucsweb 1997-2017

Le site des Trucsweb a maintenant 20 ans! 20 ans de partage.

jours restants pour la campagne de financement 2017-2037 ;- )
Je vous remercie d’envisager de faire un don afin de perpétuer cette longue tradition francophone qui a maintenant 20 ans.

Merci,
Django Blais, L’Isle-Verte (Québec)


Securité

Entête HTTP

RDFFav

Entête HTTP : Politique de sécurité du contenu (CSP)

La « Content Security Policy (CSP) », est un mécanisme d’applications Web implanté en amont de la requête HTTP.Cross-site scripting (XSS), Content Security Policy (CSP), X-XSS-Protection , X-Frame-Options, X-Content-Type, nosnif, public-key-pinsf

securityheaders.io
Tester gratuitement la vulnérabilité de votre site web à l’aide de SecurityHeaders.io.

On protège généralement le serveur, contre les attaques de scripts (cross-site scripting (XSS)) et les injections SQL, directement dans le code de chaque page. Du cas par cas à chaque requête, la première ligne de défense comme dit Wikipédia. Essentiellement la validation de formulaires. En comparant chaque chaine de requête (querystring) avec des mots-clés et des signatures, à l’instar des antivirus... C’est efficace, dans la mesure où dans mon cas j’ai la déformation professionnelle nécessaire! Mais c’est comme étouper une passoire, il suffit d’une faille, d’une oublie ou même d’une nouvelle souche pour faire voler en éclats les mesures de sécurité. Sans parler du gestionnaire de serveur Web qui n’a aucun contrôle sur les scripts publiés sous un domaine, laissant le serveur extrêmement vulnérable.

La politique de sécurité du contenu, en anglais « Content Security Policy (CSP) », est un mécanisme d’applications Web implanté en amont de la requête HTTP, qui permet de limiter l’interprétation de script et de cadre imbriqué (iframe) directement dans le navigateur client. Une défense en profondeur qui consiste en une simple politique déclarative du serveur, via l’entête HTTP, pour indiquer au navigateur les sources à partir de laquelle l’application prévoit charger les ressources.

Mais attention bien que le CSP soit très efficace, en permettant d’améliorer votre sécurité, c’est à la merci du navigateur. Étant donné que seule la version « Edge » des navigateurs Internet Explorer est compatible, la question ne se pose même pas.

Compatibilité CSP
Chrome Firefox Safari Internet Explorer
CSP 2.0Chrome 40+Firefox 31+ (partiel)
CSP 1.Chrome 25+FireFox 23+Safari 7+Edge 12 build 10240+

Voir la compatibilité de Content Security Policy.
Liste blanche

Une application web peut déclarer qu’elle ne prévoit charger les scripts de confiance qu’à partir de sources ou de domaines spécifiques, à la manière de la liste blanche du serveur de courriel. Cette déclaration permet au client de détecter et de bloquer les scripts malveillants injectés dans l’application. Ce qui est bien avec cette méthode, contrairement au serveur de courriel, c’est qu’un site web peut utiliser exclusivement des ressources locales, contrairement aux courriels... C’est dire qu’on peut protéger son serveur des attaques avec une bonne politique de sécurité du contenu et surtout, une solide éthique de programmation.

Essentiellement :

  1. En évitant les scripts et styles directement dans le code, dit « en ligne ». Parce que le butineur ne peut pas déterminer si un script « en ligne » a été injecté par un attaquant ;

  2. Particulièrement l’évaluation de chaine avec eval(). Même si on peut l’éviter avec unsafe-eval, et même si la plupart des attaques XSS ne l’utilisent pas contrairement aux injections SQL. L’eval() reste toujours une faille potentielle. Mais attention, plusieurs scripts ne fonctionnent plus à cause de cette pratique qui n’est pas conseillée, même local ;

  3. En transférant les scripts, styles et images externes localement sur le serveur ;

  4. Et enfin en ajoutant dans l’entête HTTP une bonne politique de sécurité du contenu en spécifiant les exceptions pour les scripts externes autorisés, comme Google API comme jQuery, Analytic, Font, Ad Sens etc. On comprend pourquoi Google n’est pas derrière la Politique de sécurité du contenu ;-p ;

  5. En évitant les iFrames.

Vous l’aurez compris, c’est assez simple, particulièrement pour un site d’auteur qui n’utilise pas ou peu de ressources externes d’autant que l’entête HTTP est une simple chaine de caractère. Mais ça peut devenir plus complexe dans un environnement qui utilise plusieurs domaines, un clusteur ou ces gabarits fort répandus avec des dizaines de ressources externes. Par exemple le script pour la compatibilité des images BPG de Fabrice Bellard utilise l’eval() et ne fonctionne donc pas sans une exception. Ou encore c’est toute une affaire juste pour autoriser les services de Google.

// Exemple HTTP : l’exécution de script est autorisée
// pour le domaine local et pour le domaine (et protocole) https://apis.google.com.
Content-Security-Policy: script-src 'self' https://apis.google.com

script-src est la directive pour le contrôle de privilèges liés à un script pour une page Web donnée. 'self' spécifie une source valide de script, en l’occurrence la source locale. Et une seconde, spécifiée par un nom de domaine en particulier « https://apis.google.com » et le protocole « HTTPS ». Le navigateur téléchargera et interprètera seulement le JavaScript en provenance de apis.google.com via le protocole HTTPS. Ainsi que les ressources de la même origine que la page en cours ('self'). « apis.google.com » autorise les deux protocoles en même temps. Noter que apis.google.com et google.com représentent deux sources différentes, il faut dans ce cas spécifier les deux.

Avec cette politique définie via l’entête HTTP, le navigateur va simplement lancer une erreur au lieu de charger le script à partir d’une autre source. Si un attaquant parvient à injecter du code dans votre site, c’est plutôt sur ce message d’erreur que se terminera la transaction :

Erreur CSP - Chrome

Bar OPEN

Bon par défaut, c’est « bar open », le chargement et l’interprétation de tout type de ressources peut importe la source est autorisé. Si vous ne définissez pas une politique spécifique pour une directive, le navigateur se comportera comme si TOUT (*) était une source valide. C’est pas pour rien que le test de SecurityHeaders.io retourne la note « F » par défaut. Car, c’est « bar open » ! Le chargement et l’interprétation de tout type de ressources, peut importe la source, est autorisé. Vous pouvez remplacer ce comportement par défaut en spécifiant une directive default-src. Cette directive définit les valeurs par défaut pour la plupart des directives laissées sans précision.

En général, cela s’applique à toute directive qui se termine par -src (c’est-à-dire à part les directives : base-uri,form-action, frame-ancestors, plugin-types, report-uri, sandbox). Si default-src autorise https://example.com mais qu’aucun font-src n’est spécifié, vous devrez charger les polices uniquement à partir de https://example.com et nulle part ailleurs. En précisant uniquement la directive script-src, les images, les polices, et les ressources autre qu’un script, pourront être chargées à partir de toute origine.

Bien que les ressources de script soient beaucoup plus à risquent au niveau de la sécurité, le CSP fournit un ensemble de politique sous forme de directives qui permettent un contrôle assez pointu des ressources qu’une page est autorisée à charger :

base-uri
limite les URL qui peuvent apparaître dans l’élément HTML <base> d’une page.
child-src
limite les URL pour le contenu des cadres intégrés (iframe). Par exemple : le child-src https://youtube.com permettrait d’intégrer les vidéos de YouTube, mais pas d’autres origines. Utilisez-le à la place de la directive frame-src dépréciée.
connect-src
limite les origines à laquelle vous pouvez vous connecter (via XHR, WebSockets et EventSource).
font-src
spécifie les origines qui peuvent servir de polices Web. Web Fonts de Google pourraient être activés par la font-src https://fonts.googleapis.com/
form-action
liste les paramètres valides pour la soumission de balises <form>
frame-ancestors
spécifie les sources qui peuvent incorporer la page en cours. Cette directive s’applique à <frame>, <iframe>, <embed> et <applet>. Cette directive ne peut pas être utilisé dans les balises <meta> et s’applique uniquement aux ressources non-HTML.
frame-src
Déprécié Utilisez plutôt child-src.
img-src
liste les ressources à partir desquelles les images peuvent être chargées.
media-src
limite les origines autorisées à diffuser de la vidéo et de l’audio.
object-src
limite les origines autorisées à diffuser du flash et autres plugiciels.
plugin-types
limite les types de plugiciels qu’une page peut charger.
report-uri
spécifie un URL où un navigateur envoie des rapports quand une politique de sécurité de contenu est violé. Cette directive ne peut pas être utilisé dans les balises <meta>.
script-src
liste les ressources à partir desquelles les feuilles de styles CSS peuvent être chargées.
style-src
liste les ressources à partir desquelles les script JavaScript CSS peuvent être chargés.
upgrade-insecure-requests
Directive des navigateurs pour réécrire les schémas d’URL, pour par exemple changer le protocole de HTTP vers HTTPS, pour les sites Web avec un grand nombre d’anciennes URL qui doivent être réécrites.

Il suffit de spécifier la directive et la source autorisé. On peut ajouter le nombre de directives qu’on veut en les séparent par un point virgule.

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'
Il y a quatre mnémoniques acceptées comme source :
'none'
ne correspond à rien ;
'self'
correspond à l’origine de la page en cours, mais pas ses sous-domaines (www.exemple.com mais pas exemple.com) ;
'unsafe-inline'
permet le JavaScript et CSS « en ligne » (inline) ;
'unsafe-eval'
permet l’évaluation de chaine de caractère (eval).
Exemples simples
# Bloc tout.
default-src ’none’;

# Accepte la CSS local (domaine de la page en cour).
style-src ’self’;

# Accepte le JavaScript local (domaine de la page en cour).
script-src ’self’;

# Autorise les connexion XHR de Google Maps APIs via HTTPS.
connect-src https://maps.googleapis.com; 

# Autorise les images de Google Maps via HTTPS.
img-src https://maps.google.com;
Le dangereux code en ligne (inline)
JavaScript

Le CSP s’appuie comme on le sais sur une « liste blanche », c’est une façon non ambiguë d’instruire le navigateur pour traiter des ensembles spécifiques de ressources comme acceptable et de rejeter le reste. Cette façon de faire ne résout cependant pas la plus grande menace, celle des attaques XSS (injection de script en ligne). Si un attaquant peut injecter du JavaScrip malveillant (<scrip> verslenfer.com(); </ script>), le navigateur n’a pas de mécanisme permettant de le distinguer le code en ligne légitime du code malveillant. D’ailleurs le test SecurityHeaders.io retourne un A+ même en autorisant le JavaScript en ligne ! Le CSP résout toutefois ce problème en interdisant carrément les scripts en ligne (inline) : c’est le seuile moyen absolument sûr.

Cette interdiction affecte non seulement les scripts intégrés directement dans les balises de script, mais aussi les gestionnaires d’évènements (event handlers) en ligne et le JavaScript dans un hyperlien. Vous aurez besoin de déplacer le contenu des balises de script dans un fichier externe, et remplacer le JavaScript dans les hyperliens <a ... onclick="[JAVASCRIPT]"> par des appels externes à l’aide de la méthode « addEventListener » appropriée. Par exemple, vous devrez réécrire le JavaScript suivant :

<script>
  function maFonction() {
    alert('Ahurissant');
  }
</script>
<button onclick='maFonction();'>Ahurissant?</button>

// Par quelque chose comme :

<!-- page.html -->
<script src='maFonction.js'></script>
<button id='oAhurissant'>Ahurissant?</button>

// maFonction.js
function maFonction() {
  alert('Ahurissant!');
}
document.addEventListener('DOMContentReady', function () {
  document.getElementById('oAhurissant')
          .addEventListener('click', maFonction);
});

Le nouveau code n’a rien d’exceptionnel, c’est déjà programmer de façon éthique. Et on devrait toujours programmer de cette façon. C’est ici qu’on peut s’arracher les cheveux à convertir les pages Web d’un site Web existant, ou d’un gabarit à bas prix (template). Sinon, c’est une maudite bonne habitude à prendre si vous ne l’aviez pas déjà prise. Car un JavaScript « en ligne » (Inline) ne devrait jamais être utilisé. Les ressources extérieures sont plus faciles à gérer par les techniques de mise en cache, plus compréhensible pour les développeurs et propice à la compilation et à la minification.

Feuille de styles (CSS)

Le style (CSS) « en ligne » (Inline) est traité de la même manière. À la fois l’attribut de style et les balises de style devraient être regroupés en feuilles de style externes pour se protéger contre une variété de méthodes étonnamment habiles d’exfiltration de données permises par le CSS. J’avoue que je ne sais absolument pas de quoi il est question. Il faudrait examiner un peu tout ça, mais je le crois sur parole et c’est une autre bonne habitude à prendre.

'unsafe-inline'

Si vous devez absolument utiliser des scripts et des styles en ligne, vous pouvez l’activer en ajoutant 'unsafe-inline' comme une source autorisée dans une directive script-src ou style-src. Vous pouvez également utiliser la mnémonique nonce ou un hachage sha256 (hash). Mais de grâce, éviter cette pratique à tout prix. Bannir les scripts « en ligne » est le plus important gain de sécurité du CSP, et l’interdiction de style en ligne endurcira également votre application. C’est une tâche ardue que de déplacer son code dans un fichier externe et de se plier à ces directives, mais c’est un compromis qui en vaut certainement la peine.

Si vous devez absolument utiliser...

Content-Security-Policy: script-src 'unsafe-inline';

Le CSP niveau 2 offre aussi une compatibilité pour les scripts en ligne en permettant une liste blanche de script en ligne spécifique à l’aide soit de nonce cryptographique (numéro utilisé une fois) ou un hachage (encodage sha256). Bien que cela puisse être lourd dans la pratique, ça peut donner un bon coup de pouce.

Pour utiliser nonce, donnez à votre balise de script un attribut nonce. Sa valeur doit correspondre à l’une des valeurs spécifiées dans la liste des sources de confiance. Par exemple :

<script nonce=EBFneeIOfn23fn3e983s55Af>
  // Code en ligne pour gagner du temps, ça dépanne toujours.
</script>

Maintenant, ajoutez nonce à votre directive script-src :

Content-Security-Policy: script-src 'nonce-EBFneeIOfn23fn3e983s55Af' 

Rappelez-vous qu’une chaine « nonces » doit être régénérée pour chaque demande de page et ils doivent être impossible à deviner...

Le hachage fonctionne à peu près de la même façon. Au lieu d’ajouter du code à la balise de script, créer un hachage SHA du script lui-même et ajoutez-le à la directive script-src. Par exemple, disons que votre page contient ceci :

<script>alert('Hello, world.');</script>

Votre politique devrait contenir :

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';

Il y a quelques détails à noter ici. Le préfixe sha*- spécifie l’algorithme utilisé pour générer le hachage. Dans l’exemple ci-dessus, sha256- est utilisé, mais le CSP supporte également le hachage sha384- et sha512-. Lors de la génération du hachage, n’encodez pas les balises <script>. Et attention avec les espaces et la case des caractères (majuscule/minuscule).

L’évaluation de chaine de caractères avec eval()

Même si une attaque ne peut injecter du script, elle pourrait être en mesure de tromper votre application dans la conversion du texte normalement inerte dans exécutable JavaScript et l’exécuter en son nom. eval(), une nouvelle Function(), setTimeout([chaine], ...), et setInterval([chaine], ...) sont tous des vecteurs à travers lesquels l’injection de texte pourrait finir par exécuter quelque chose d’inattendu et de malveillant. La réponse par défaut de CSP par rapport à ce risque est, sans surprise, est de bloquer complètement tous ces vecteurs.

Cela a plus d’un impact sur la façon de créer des applications :

Traitez le JSON via la méthode native JSON.parse, plutôt que de compter sur l’évaluation de chaine avec eval(). Les opérations natives du JSON sont disponibles dans tous les navigateurs depuis IE8 et ils sont totalement sécuritaires.

Réécrire tous les appelle setTimeout ou setInterval que vous avez programmé avec une évaluation de chaine de caractère par une « fonction en ligne ». Par exemple :

setTimeout("document.querySelector('a').style.display = 'none';", 10);

// Devrait codé ainsi :

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

Évitez les gabarits en ligne (templating inline) à l’exécution : de nombreuses librairies utilisent trop facilement new Function() pour accélérer la génération de modèle lors de l’exécution. C’est peut-être une utilisation astucieuse de la programmation dynamique, mais au risque d’évaluer des chaines malveillantes. Certains cadriciels supportent le CSP , la directive ng-csp de AngularJS est un bon exemple.

Encore mieux, si votre langage offre la précompilation (Handlebars le fait par exemple), précompilation vos modèles peut rendre l’expérience encore plus rapide que la plus rapide des mises en œuvre de modèle exécuté en ligne tout en étant plus sûr. Si l’évaluation (eval) est tout à fait indispensable à votre application, vous pouvez les activer en ajoutant 'unsafe-eval' comme source autorisée dans une directive script-src. Mais c’est tout à fait déconseillé encore une fois. Avec l’interdit d’exécuter des chaines évaluées, il est beaucoup plus difficile pour un attaquant d’exécuter du code non autorisé sur votre site.

Content-Security-Policy: script-src 'unsafe-eval';
Exemple avec autorisation de script « en ligne » et eval()
// Exemple pour autoriser l’interprétation des scripts locaux,  
// Plus l’autorisation de script « en ligne » avec 'unsafe-inline'
// Et l’autorisation de l’évaluation de chaine de caractère avec 'unsafe-eval'
// PAS DU TOUT SÉCURITAIRE
Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval';

// Exemple des Trucsweb.com
// Avec autorisation de la publicité Google
Content-Security-Policy: default-src trucsweb.com www.trucsweb.com; script-src 'self' googleads.g.doubleclick.net;
Journal des violations CSP avec report-uri

« rapport-uri » permets de compiler les violations de votre politique de sécurité du contenu dans un fichier journal. Il suffit de spécifier une adresse (URL) avec la directive et le navigateur se chargera d’envoyer une requête HTTP à cette adresse à chaque violation. Cette directive fait une demande HTTP avec la méthode POST et une chaine JSON qui contient tous les détails de la violation. Récupérer cette chaine pour la sauvegarder dans un « fichier log » sur le serveur à l’aide de votre langage serveur préféré.

Exemple d’entête :

Content-Security-Policy: default-src 'self'; report-uri: https://example.com/csp/journaux;

Chaque tentative d’ouvrir une autre source non autorisée provoquera la soumission de la chaine JSON via une requête HTTP POST à notre rapport-uri. Comme l’exemple suivant avec un script de Google Analytic bloqué.

{
    "csp-report": {
        "blocked-uri:" "http://ajax.googleapis.com"
        "document-uri:" "http://example.com/index.html"
        "original-policy": "default-src 'self'; report-uri https://example.com/csp/journaux"
        "referrer:" ""
        "violated-directive": "default-src 'self'"
    }
}
Content-Security-Policy-Report-Only

Si vous envisagez de mettre en œuvre une Politique de sécurité du contenu, testez-le en utilisant l’entête HTTP « Content-Security-Policy-Report-Only », au lieu de « Content-Security-Policy ». Elle fonctionne exactement de la même façon que l’entête de CSP, mais en signalant les violations sans appliquer effectivement la politique en bloquant des ressources restreintes. Vous pouvez même utiliser les deux entêtes en même temps, l’application d’une politique tout en surveillant l’effet que des changements pourraient avoir dans l’autre.


Exemple pour détecter si le JavaScript « en ligne » est permis dans une page Web.

Encore une fois, même si la fonction eval() affaiblie considérablement un script, les attaques de script de type XSS n’utilisent pas beaucoup l’évaluation de chaine de caractères dans ses attaques, préfèrent l’appel de fonction et charger des scripts externes. Contrairement au JavaScript « en ligne », vecteur de plusieurs attaques classique. C’est-à-dire le JavaScript interprété après le chargement de la page, et donc dans l’impossibilité d’identifier ou d’authentifier la source.

<div class="alert alert-success" id="jsNode"><h5><span class="glyphicon glyphicon-ok"></span> Script « en ligne » bloqué</h5> Si vous pouvez lire ce texte, votre navigateur est compatible avec le CSP et bloque l’interprétation des scripts « en ligne » avec une directive.</div>

<script>
  window.onload=function(){
    var jsNode = document.getElementById("jsNode");
    jsNode.innerHTML = "<h5><span class=\"glyphicon glyphicon-exclamation-sign\"></span> Script « en ligne » bloqué</h5> Votre navigateur est incompatible avec le CSP ou aucune directive n’empêche d’interpréter ce script « en ligne » qui remplace le contenu du DIV.";
    jsNode.className = "alert alert-danger";
  };
</script>
Implentation
// HTML - Exemple avec une métadonnée « http-equiv »
// Qui n’autorise pas le iFrame ni l’objet.
<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">

# Apache config
Header set Content-Security-Policy "default-src 'self';"

# PHP example
header("Content-Security-Policy: default-src 'self'");

# Node.js example
request.setHeader("Content-Security-Policy", "default-src 'self'");

// ASP.NET
public class ContentSecurityPolicyFilterAttribute : ActionFilterAttribute {
  public override void OnActionExecuting( ActionExecutingContext filterContext) {
    var response = filterContext.HttpContext.Response;
    response.AddHeader("Content-Security-Policy" , 
         "default-src https:; 
          script-src 'self' https://code.jquery.com https://ajax.aspnetcdn.com; 
          style-src 'self' https://ajax.aspnetcdn.com");
    base.OnActionExecuting(filterContext);
  }
}

// Web.config / IIS
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Content-Security-Policy" value="'self' https://ajax.googleapis.com" />
        <remove name="X-Content-Type-Options"/>
        <add name="X-Content-Type-Options" value="nosniff"/>
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

# nginx conf file
add_header Content-Security-Policy "default-src 'self';";

Exemple avec médias sociaux, Google et autorisations de scripts en ligne et eval() JavaScript, CSS « en ligne ».

default-src *; script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* ’unsafe-inline’ ’unsafe-eval’ https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com; style-src * ’unsafe-inline’; connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;
Autre métadonnées d’entête

Outre « Content-Security-Policy », il existe plusieurs métadonnées d’entête. Plusieurs sont toutes fois désuètes, remplacées par « Content-Security-Policy » mais certaines sont toujours supportées par les vieux navigateurs, comme « X-XSS-Protection » et Internet Explorer 8+, justement incompatible avec « Content-Security-Policy ». Étant donné que le navigateur ignore simplement la directive et que vous voulez une note de A+ avec le test de SecurityHeaders.io, aussi bien les ajouter.

  1. X-XSS-Protection

    L’entête X-XSS-Protection est conçu pour activer le filtre cross-site scripting (XSS) intégré dans les navigateurs web modernes. Habituellement activée par défaut, son utilisation assure son application. Il est pris en charge par Internet Explorer 8+, Chrome et Safari. Voici un exemple de l’entête :

    x-xss-protection : 1; mode=block
    
    // Activation sous Nginx
    add_header x-xss-protection "1; mode=block" always;
    
    // Activation sous Apache
    header always set x-xss-protection "1; mode=block"
    
  2. X-Content-Type-Options

    L’entête X-Content-Type-Options empêche Internet Explorer et Google Chrome d’envoyer une requête (renifler) au serveur avant la requête officiel. Cela permet de réduire le risque de téléchargements « drive-by » et aide à traiter le contenu de la bonne façon. Voici un exemple d’entête.

    x-content-type: nosniff
    
    // Enable in Nginx
    add_header X-Content-Type-Options "nosniff" always;
    
    // Enable in Apache
    Header always set X-Content-Type-Options "nosniff"
    
  3. X-Frame-Options

    L’entête X-Frame-Options offre une protection « clickjacking » en ne permettant pas les iFrames d’être chargés dans votre site. Supporté par IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Voici un exemple d’en-tête.

    x-frame-options: SAMEORIGIN
    
    // Enable in Nginx
    add_header x-frame-options "SAMEORIGIN" always;
    
    // Enable in Apache
    header always set x-frame-options "SAMEORIGIN"
    
  4. Public-Key-Pins

    L’entête Public-Key-Pins indique au navigateur Web d’associer une clé publique avec le serveur Web pour empêcher les attaques MITM utilisant la falsification des certificats X.509. Cela protège les utilisateurs si l’autorité du certification est compromise. Lire l’excelent tutoriel de Scott Helme « how to setup public key pinning ». Voici un exemple d’entête.

    public-key-pins: pin-sha256="t/OMbKSZLWdYUDmhOyUzS+ptUbrdVgb6Tv2R+EMLxJM="; pin-sha256="PvQGL6PvKOp6Nk3Y9B7npcpeL40twdPwZ4kA2IiixqA="; pin-sha256="ZyZ2XrPkTuoiLk/BR5FseiIV/diN3eWnSewbAIUMcn8="; pin-sha256="0kDINA/6eVxlkns5z2zWv2/vHhxGne/W0Sau/ypt3HY="; pin-sha256="ktYQT9vxVN4834AQmuFcGlSysT1ZJAxg+8N1NkNG/N8="; pin-sha256="rwsQi0+82AErp+MzGE7UliKxbmJ54lR/oPheQFZURy8="; max-age=600; report-uri="https://www.keycdn.com"
    
  5. HTTP Strict Transport Security (HSTS)

    L’entête HTTP Strict Transport Security est une amélioration de la sécurité qui force les navigateurs Web à accéder aux serveurs web uniquement via HTTPS. Cela garantit que la connexion ne peut pas être établie par le biais d’une connexion HTTP insécure, plus vulnérable.

    Les principaux navigateurs modernes prennent actuellement en charge le « HTTP Strict Transport Security » sauf Opera Mini et les versions antérieures d’Internet Explorer. Pour en savoir plus sur cet entête et voir la mise en œuvre sur Nginx et Apache, assurez-vous de lire HTTP Strict Transport Security.

    Voici un exemple d’entête. Vous pouvez inclure l’âge maximum, les sous-domaines et le préchargement.

    strict-transport-security: max-age=31536000; includeSubDomains; preload
    
IIS 8 : Gestionnaire d’entête HTTP (CSP)

Via le gestionnaire IIS

Utiliser le gestionnaire IIS pour ajouter vos entête HTTP et vos directives de « Politique de sécurité du contenu (CSP) ».

IIS
  1. Ouvrez le gestionnaire des services Internet (IIS) ;
  2. Sélectionnez votre site ;
  3. Dans l’onglet IIS, cliquer « En-tête de réponse HTTP » ;
  4. Ajoutez vos entête HTTP.
Ressources
, Analyste programmeurConception oznogco multimédia (http://oznogco.com), Trucsweb
Dernière mise à jour :

Commentaires

9/10 sur 1 revues.
       Visites : 3494 - Pages vues : 3637
X

Trucsweb.com Connexion

Connexion

X

Trucsweb.com Mot de passe perdu

Connexion

X

Trucsweb.com Conditions générales

Conditions

Responsabilité

La responsabilité des Trucsweb.com ne pourra être engagée en cas de faits indépendants de sa volonté. Les informations mises à disposition sur ce site le sont uniquement à titre purement informatif et ne sauraient constituer en aucun cas un conseil ou une recommandation de quelque nature que ce soit.

Aucun contrôle n'est exercé sur les références et ressources externes, l'utilisateur reconnaît que les Trucsweb.com n'assume aucune responsabilité relative à la mise à disposition de ces ressources, et ne peut être tenue responsable quant à leur contenu.

Droit applicable et juridiction compétente

Les règles en matière de droit, applicables aux contenus et aux transmissions de données sur et autour du site, sont déterminées par la loi canadienne. En cas de litige, n'ayant pu faire l'objet d'un accord à l'amiable, seuls les tribunaux canadien sont compétents.

X

Trucsweb.com Trucsweb

X

Trucsweb.com Glossaire

X

Trucsweb.com Trucsweb

X

Trucsweb.com Trucsweb

Conditions

Aucun message!

Merci.

X
Aucun message!
X

Trucsweb.com Créer un compte

Créer un compte

.
@