ZW3B :-: API Client * Contents * Docs by LAB3W.ORJ

Translate this page

Name : BETA-TESTERS

Project name : ZW3B-API-BETA-TESTERS

Authorized. - 200 - Client API Name and Origin Wildcard OK

¿Comment? 'Ou' ¿Que faire?, Développement, Sec-Fetch - Aller chercher/demander/protéger une ressource Web HTTP - Content-Security-Policy - Cross-Origin - X-Frame - X-Content

Options X-Frame et Processus de réponses aux documents http en mode Sec-Fetch d'origine croisée - La norme Fetch définit les requêtes HTTP, les réponses HTTP et le processus qui les lie : la récupération.

Author : O.Romain.Jaillet-ramey - lab3w (dot) orj (at) zw3b (dot) fr

NdM : 2021/09/04 - Cette page est en cours de complément rédactionnel..

J'écris cette documentation pour comprendre la norme de sécurité Sec-Fetch-* - "aller chercher/demander/protéger" une ressource Web.

Dans ce papier je vais d'écrire certaines fonctionnalités de sécurité pour site Web - Que cela (la ressource) soit inter-sites soit intra-site :)

Pour commencer je vais parler du header X-Frame-Options qui permet de bloquer les contenus de nos sites Web qu'un attaquant voudrait inclure à son site via une iframe par exemple en simulant que le contenu pourrait lui appartenir !

Puis je vais d'écrire les fonctionnalité récentes tel que CORS, les demandes et réponses d'origines croisées de partage de ressources pour différents type de format de documents transitant pour le web - js/css/html/json et d'autres.

X-Frame-Options :

L'en-tête de réponse HTTP X-Frame-Options peut être utilisé pour indiquer si un navigateur doit être autorisé ou non à afficher une page dans une frame, iframe, embed ou object. Les sites peuvent l'utiliser pour éviter les attaques de détournement de clic, en s'assurant que leur contenu n'est pas intégré à d'autres sites.

La sécurité supplémentaire n'est fournie que si l'utilisateur qui accède au document utilise un navigateur prenant en charge X-Frame-Options.

Directives :

Les sites web peuvent utiliser les entêtes X-Frame-Options ou une stratégie de sécurité du contenu (CSP) pour contrôler si d'autres sites web peuvent les intégrer dans leurs propres pages. C'est une fonctionnalité de sécurité importante pour empêcher le détournement de clic (clickjacking) (attaque qui permet à des sites malveillants de duper les utilisateurs et utilisatrices pour les amener à cliquer sur les liens d'un site) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de malware.

Pour exemple en ajoutant un header('X-Frame-Options: deny'); en haut d'une page Web cela permet que personne ne puisse inclure votre site/page web via une iframe.

X-Content-Type-Options : les en-têtes Content-Type ne doivent pas être modifiés ou et suivis

L'entête X-Content-Type-Options est un marqueur utilisé par le serveur pour indiquer que les types MIME annoncés dans les en-têtes Content-Type ne doivent pas être modifiés ou et suivis. Cela permet de se détacher du sniffing de type MIME, ou, en d'autres termes, c'est une façon de dire que les webmasters savaient ce qu'ils faisaient.

Cet en-tête a été introduit par Microsoft dans IE 8 comme un moyen pour les webmasters de bloquer le reniflement de contenu qui se passait et pouvait transformer les types MIME non exécutables en types MIME exécutables. Depuis, d'autres navigateurs l'ont introduit, même si leurs algorithmes de reniflage MIME étaient moins agressifs.

A partir de Firefox 72, la désactivation du reniflement MIME est également appliqué aux documents de premier niveau si un Content-type est fourni. Les pages web HTML qui sont servies avec un type MIME différent de text/html, peuvent alors être juste téléchargées au lieu d'êtres rendues (interprétées et affichées par le navigateur). Assurez vous de valoriser correctement ces 2 en-têtes.

Les testeurs de sécurité du site s'attendent généralement à ce que cet en-tête soit défini.

Note: X-Content-Type-Options ne s'appliquent qu'au blocage des demandes par nosniff pour les destinations de demandes de "script" et "style". Il permet également le blocage en lecture croisé (CORB) pour les fichiers HTML, TXT, JSON, et XML (à l'exception des images SVG image/svg+xml).

Directives

Content-Security-Policy (CSP ) : Politique de sécurité de contenu

L'en-tête de réponse HTTP Content-Security-Policy permet aux administrateurs d'un site web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Bien qu'il y ait quelques exceptions, ces règles impliquent la plupart du temps de définir les origines du serveur et les points d'accès pour les scripts. Cet en-tête aide à se protéger contre les attaques de cross-site scripting (XSS (en-US) ).

Directives de récupération (fetch)

Les directives de récupération (ou fetch directives en anglais) contrôlent les emplacements à partir desquels certains types de ressource peuvent être chargés.

Directives de document

Les directives de document permettent de paramétrer les propriétés d'un document ou d'un environnement pour un web worker auquel une règle de sécurité s'applique.

Directives de rapport

Les directives de rapport permettent de contrôler ce qui se passe lorsqu'une règle CSP est violée. Voir également l'en-tête Content-Security-Policy-Report-Only.

Autres directives

Les directives de rapport permettent de contrôler ce qui se passe lorsqu'une règle CSP est violée. Voir également l'en-tête Content-Security-Policy-Report-Only.


Exemples :

Dans cet exemple, on désactive les scripts écrits à même le document (inline), les opérations eval() et les ressources (images, polices, scripts, etc.) peuvent uniquement être chargées via HTTPS :

Script avec 5 lignes


001// en-tête HTTP
002Content-Security-Policy: default-src https:
003
004// version avec la balise HTML meta
005<meta http-equiv="Content-Security-Policy" content="default-src https:">
Retirer les numéros de lignes

Dans cet exemple, on ne met pas en place la règle de sécurité mais on récolte les enfreintes qui se seraient produites pour cette règle :

Script avec 1 ligne


001Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
Retirer les numéros de lignes


Cross-Origin : Origine croisée

Les requêtes de n'importe quelle origine (à la fois sur le même site et entre sites) peuvent lire la ressource.

Cross-origin Resource Sharing (CORS ) : Partage des ressources entre origines multiples

Le cross-origin resource sharing (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP multi-origine (cross-origin) lorsqu'il demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante.

Quelles requêtes utilisent le CORS ?

Le standard CORS est utilisé afin de permettre les requêtes multi-origines pour :

Cross-Origin-Read-Blocking (CORB) : Blocage de lecture d'origine croisée

Le blocage de lecture cross-origin, mieux connu sous le nom de CORB, est un algorithme qui identifie les récupérations de ressources cross-origin douteuses (par exemple, les récupérations qui échoueraient de toute façon comme les tentatives de rendu JSON dans un élément img) et les bloque avant qu'elles n'atteignent une page Web. CORB réduit le risque de fuite de données sensibles en les éloignant des pages Web d'origine croisée.

Cross-Origin-Resource-Policy (CORP) : Politique de ressources d'origine croisée

Cross-Origin Resource Policy est une stratégie définie par l'en-tête HTTP Cross-Origin-Resource-Policy qui permet aux sites Web et aux applications d'opter pour la protection contre certaines demandes provenant d'autres origines (telles que celles émises avec des éléments tels que script et img), pour atténuer les attaques spéculatives par canal latéral, comme Spectre, ainsi que les attaques par inclusion de scripts intersites.

CORP est une couche de protection supplémentaire au-delà de la politique de même origine par défaut. Cross-Origin Resource Policy complète le Cross-Origin Read Blocking (CORB), qui est un mécanisme pour empêcher certaines lectures cross-origin par défaut.

Directives :

Cross-Origin-Opener-Policy (COOP) : Politique d'ouverture d'origine croisée

L'en-tête de réponse HTTP Cross-Origin-Opener-Policy (COOP) vous permet de vous assurer qu'un document de niveau supérieur ne partage pas un groupe de contexte de navigation avec des documents d'origine croisée.

COOP traitera et isolera votre document et les attaquants potentiels ne pourront pas accéder à votre objet global s'ils l'ouvraient dans une fenêtre contextuelle, empêchant ainsi un ensemble d'attaques d'origine croisée appelée XS-Leaks.

Si un document d'origine croisée avec COOP est ouvert dans une nouvelle fenêtre, le document d'ouverture n'y fera pas référence et la propriété window.opener de la nouvelle fenêtre sera nulle. Cela vous permet d'avoir plus de contrôle sur les références à une fenêtre que rel=noopener, ce qui n'affecte que les navigations sortantes.

Directives :
Exemples :

Certaines fonctionnalités dépendent de l'isolement des origines croisées

Certaines fonctionnalités telles que les objets SharedArrayBuffer ou Performance.now() avec des minuteries non étranglées ne sont disponibles que si votre document a un en-tête COOP avec la valeur de même origine définie.

Script avec 2 lignes


001Cross-Origin-Opener-Policy: same-origin
002Cross-Origin-Embedder-Policy: require-corp
Retirer les numéros de lignes

Voir aussi l'en-tête Cross-Origin-Embedder-Policy que vous devrez également définir.
Pour vérifier si l'isolation d'origine croisée a réussi, vous pouvez tester la propriété crossOriginIsolated disponible pour les contextes de fenêtre et de travail :

Script avec 5 lignes


001if (crossOriginIsolated) {
002  // Post SharedArrayBuffer
003} else {
004  // Do something else
005}
Retirer les numéros de lignes

Cross-Origin-Embedder-Policy (COEP) : Politique d'intégration d'origine croisée

L'en-tête de réponse HTTP Cross-Origin-Embedder-Policy (COEP) empêche un document de charger des ressources d'origine croisée qui n'accordent pas explicitement l'autorisation de document (à l'aide de CORP ou CORS).

Directives :
Exemples :

Certaines fonctionnalités dépendent de l'isolement des origines croisées

Vous ne pouvez accéder à certaines fonctionnalités telles que les objets SharedArrayBuffer ou Performance.now() avec des minuteries non étranglées, si votre document a un en-tête COEP avec la valeur require-corp définie.

Script avec 2 lignes


001Cross-Origin-Embedder-Policy: require-corp
002Cross-Origin-Opener-Policy: same-origin
Retirer les numéros de lignes

Voir aussi l'en-tête Cross-Origin-Opener-Policy que vous devrez également définir.
Pour vérifier si l'isolation d'origine croisée a réussi, vous pouvez tester la propriété crossOriginIsolated disponible pour les contextes de fenêtre et de travail :

Script avec 5 lignes


001if (crossOriginIsolated) {
002  // Post SharedArrayBuffer
003} else {
004  // Do something else
005}
Retirer les numéros de lignes

Éviter le blocage COEP avec CORS
Si vous activez COEP à l'aide de require-corp et qu'une ressource d'origine croisée doit être chargée, elle doit prendre en charge CORS et vous devez explicitement marquer la ressource comme chargeable à partir d'une autre origine pour éviter le blocage de COEP. Par exemple, vous pouvez utiliser l'attribut crossorigin pour cette image à partir d'un site tiers :

Script avec 1 ligne


001<img src="https://thirdparty.com/img.png" crossorigin>
Retirer les numéros de lignes


Same-origin policy : Politique de même origine

La politique de même origine est un mécanisme de sécurité critique qui restreint la manière dont un document ou un script chargé par une origine peut interagir avec une ressource d'une autre origine.

Il aide à isoler les documents potentiellement malveillants, réduisant ainsi les vecteurs d'attaque possibles. Par exemple, il empêche un site Web malveillant sur Internet d'exécuter JS dans un navigateur pour lire les données d'un service de messagerie Web tiers (auquel l'utilisateur est connecté) ou d'un intranet d'entreprise (qui est protégé contre l'accès direct par l'attaquant par n'ayant pas d'adresse IP publique) et relayant ces données à l'attaquant.


Fetch : aller chercher/demander/protéger une ressource Web

La norme Fetch définit les requêtes, les réponses et le processus qui les lie : la récupération.

Sec-Fetch-*

Présentation des métadonnées Fetch : firefox 90 supports fetch metadata request headers .

Comme illustré dans le scénario d'attaque ci-dessus, l'en-tête de demande HTTP Sec-Fetch-Site permet au serveur d'applications Web de faire la distinction entre une demande de même origine provenant de l'application Web correspondante et une demande d'origine croisée provenant d'un site Web contrôlé par un attaquant.

L'inspection des en-têtes Sec-Fetch-* permet finalement au serveur d'applications Web de rejeter ou d'ignorer également les demandes malveillantes en raison du contexte supplémentaire fourni par la famille d'en-têtes Sec-Fetch-*. Au total, il existe quatre en-têtes Sec-Fetch-* différents : Dest, Mode, Site et User qui, ensemble, permettent aux applications Web de se protéger et de protéger leurs utilisateurs finaux contre les attaques intersites mentionnées précédemment.

Aller de l'avant

Alors que Firefox sera bientôt livré avec sa nouvelle architecture de sécurité d'isolation de site qui résoudra quelques-uns des problèmes ci-dessus, nous recommandons que les applications Web utilisent les en-têtes Fetch Metadata nouvellement pris en charge qui fournissent un mécanisme de défense en profondeur pour les applications de toutes sortes.

Sec-Fetch-Dest : indique la destination de la demande

L'en-tête de demande de métadonnées d'extraction Sec-Fetch-Dest indique la destination de la demande. C'est l'initiateur de la demande d'extraction d'origine, c'est-à-dire où (et comment) les données extraites seront utilisées.

Cela permet aux serveurs de déterminer s'il faut traiter une demande en fonction de son adéquation avec la manière dont elle est censée être utilisée. Par exemple, une demande avec une destination audio doit demander des données audio, pas un autre type de ressource (par exemple, un document qui inclut des informations utilisateur sensibles).

Script avec 21 lignes


001Sec-Fetch-Dest: audio
002Sec-Fetch-Dest: audioworklet
003Sec-Fetch-Dest: document
004Sec-Fetch-Dest: embed
005Sec-Fetch-Dest: empty
006Sec-Fetch-Dest: font
007Sec-Fetch-Dest: frame
008Sec-Fetch-Dest: iframe
009Sec-Fetch-Dest: image
010Sec-Fetch-Dest: manifest
011Sec-Fetch-Dest: object
012Sec-Fetch-Dest: paintworklet
013Sec-Fetch-Dest: report
014Sec-Fetch-Dest: script
015Sec-Fetch-Dest: serviceworker
016Sec-Fetch-Dest: sharedworker
017Sec-Fetch-Dest: style
018Sec-Fetch-Dest: track
019Sec-Fetch-Dest: video
020Sec-Fetch-Dest: worker
021Sec-Fetch-Dest: xslt
Retirer les numéros de lignes
Directives

Ces directives correspondent aux valeurs retournées par Request.destination.

Exemples

Une requête intersites générée par un élément img entraînerait une requête avec les en-têtes de requête HTTP suivants (notez que la destination est une image) :

Script avec 3 lignes


001Sec-Fetch-Dest: image
002Sec-Fetch-Mode: no-cors
003Sec-Fetch-Site: cross-site
Retirer les numéros de lignes

Sec-Fetch-Mode : Ces directives correspondent aux valeurs de Request.mode.

L'en-tête de demande de métadonnées d'extraction Sec-Fetch-Mode indique le mode de la demande.

De manière générale, cela permet à un serveur de faire la distinction entre : les requêtes provenant d'un utilisateur naviguant entre les pages HTML, et les requêtes de chargement d'images et d'autres ressources. Par exemple, cet en-tête contiendrait naviguer pour les requêtes de navigation de niveau supérieur, tandis que no-cors est utilisé pour charger une image.

Directives
Exemples

Si un utilisateur clique sur un lien de page vers une autre page sur la même origine, la requête résultante aurait les en-têtes suivants (notez que le mode est navigation) :

Script avec 3 lignes


001Sec-Fetch-Dest : document
002Sec-Fetch-Mode : navigate (navigation)
003Sec-Fetch-Site : same-origin (même origine)
Retirer les numéros de lignes

Une requête intersites générée par un élément img entraînerait une requête avec les en-têtes de requête HTTP suivants (notez que le mode est no-cors) :

Script avec 3 lignes


001Sec-Fetch-Dest: image
002Sec-Fetch-Mode : no-cors (sans cors)
003Sec-Fetch-Site : same-site (même origine)
Retirer les numéros de lignes

Sec-Fetch-Site : indique la relation entre l'origine d'un initiateur de demande et l'origine de la ressource demandée.

L'en-tête de demande de métadonnées d'extraction Sec-Fetch-Site indique la relation entre l'origine d'un initiateur de demande et l'origine de la ressource demandée. En d'autres termes, cet en-tête indique à un serveur si une demande de ressource provient de la même origine, du même site, d'un site différent, ou est une demande "initiée par l'utilisateur". Le serveur peut ensuite utiliser ces informations pour décider si la demande doit être autorisée.

Les demandes de même origine sont généralement autorisées par défaut, mais ce qui se passe pour les demandes provenant d'autres origines peut en outre dépendre de la ressource demandée ou des informations contenues dans d'autres en-têtes de demande de métadonnées Fetch. Par défaut, les demandes qui ne sont pas acceptées doivent être rejetées avec un code de réponse 403.

Directives
Exemples

Une requête d'extraction vers https://mysite.example/foo.json provenant d'une page Web sur https://mysite.example (avec le même port) est une requête de même origine. Le navigateur générera l'en-tête Sec-Fetch-Site: same-origin comme indiqué ci-dessous, et le serveur autorisera généralement la requête :

Script avec 4 lignes


001GET /foo.json
002Sec-Fetch-Dest : none (vide)
003Sec-Fetch-Mode : cors
004Sec-Fetch-Site : same-origin (même origine)
Retirer les numéros de lignes

Une requête d'extraction vers la même URL à partir d'un autre site, par exemple potentiellement-evil.com, amène le navigateur à générer un en-tête différent (par exemple Sec-Fetch-Site : cross-site), que le serveur peut choisir d'accepter ou de rejeter :

Script avec 4 lignes


001GET /foo.json
002Sec-Fetch-Dest : none (vide)
003Sec-Fetch-Mode : cors
004Sec-Fetch-Site : cross-site (intersites)
Retirer les numéros de lignes

Sec-Fetch-User :

L'en-tête de requête de récupération de métadonnées Sec-Fetch-User n'est envoyé que pour les requêtes initiées par l'activation de l'utilisateur, et sa valeur sera toujours ?1.

Un serveur peut utiliser cet en-tête pour identifier si une requête de navigation à partir d'un document, d'un iframe, etc., a été émise par l'utilisateur.

Directives
Exemples

Si un utilisateur clique sur un lien vers une autre page de la même origine, la requête résultante aura les en-têtes suivants :

Script avec 4 lignes


001Sec-Fetch-Dest: document
002Sec-Fetch-Mode: navigate
003Sec-Fetch-Site: same-origin
004Sec-Fetch-User: ?1
Retirer les numéros de lignes



Bonne gestion de vos ressources à travers le réseau international.

Cordialement,
Romain.

Liens de documentations CORS avec plus d'informations : CORP, COOP, COEP - CSP :

OAuth : Open Authorization >>