Remarques sur la configuration de la protection de la sécurité personnelle

Protection XSS

Filtrage d'entrée et de sortie

• xss.js - échappement HTML
• encodeURIou encodeURIComponent- échappement de l'adresse URL

Paramétrage des cookies HttpOnly

Le paramètre de cookie HttpOnly interdit la lecture de Cookie via JS.

Politique de sécurité du contenu Content-Security-Policy

CSP (Content-Security-Policy) est essentiellement un système de liste blanche que les développeurs peuvent personnaliser, qui peut indiquer au navigateur quelles ressources externes peuvent être chargées et exécutées.

Il existe deux façons d'activer CSP :

1. Définir les en-têtes de réponse HTTPContent-Security-Policy
2. Définir le <meta>libellé de la page

Protection CSRF

**Suggestion : **Le client envoie une demande avec un jeton et le serveur vérifie la validité du jeton (comme les identifiants de connexion de l'utilisateur)

Autres façons de compléter:

1. Le serveur vérifie si le référent d'en-tête de requête est une source sécurisée. Inconvénients : Certains plugins peuvent être falsifiés
2. N'activez pas CORS et interdisez les requêtes interdomaines. Inconvénients : peut <img> <script>être résolu par un proxy inverse, etc.
3. Les opérations sensibles utilisent des captchas. Inconvénients : expérience utilisateur peu conviviale

détournement de clic

Le détournement de clics incite principalement les utilisateurs à accéder à leurs propres pages et à interagir avec elles via des iframes ou le blocage d'images (comme la publication d'articles avec des adresses d'images malveillantes).

solution:

• Définissez l'en-tête de réponse X-Frame-Options pour empêcher d'autres sites d'intégrer des pages Web via iframe.
• Faites un bon travail de protection XSS et CSRF pour empêcher les attaquants d'injecter du code malveillant dans le site Web

attaque de l'homme du milieu

Les attaques de l'homme du milieu se réfèrent principalement aux attaquants qui interceptent les appels aux deux extrémités de la communication et insèrent un nouveau contenu.

Solution : utilisez le protocole de communication HTTPS.

fenêtre.ouverte

API DOM

Par défaut, la fenêtre ouverte par window.open() et la fenêtre appelant la méthode peuvent accéder au contexte de l'autre via l'API DOM (si la politique de même origine est satisfaite, elles peuvent également accéder aux propriétés et méthodes de l'autre) :

// http://a.example.com
const newWindow = window.open('http://b.example.com')
console.log(newWindow.opener === window) // true

// http://b.example.com
console.log(window.opener)

Il est recommandé de préciser lors de l'ouverture d'une page externe non fiable noopener:

window.open('http://b.example.com', '_blank', 'noopener=yes')

Par défaut, la page demandée en ouvrant la fenêtre portera Refererl'en-tête de la requête, tel que Referer: http://a.example.com.

noreferrerCet en-tête peut être spécifié pour être omis, et il définira égalementnoopener :

window.open('http://b.example.com', '_blank', 'noreferrer=yes')

En-tête de réponse Cross Origin Opener Policy

COOP (Cross-Origin-Opener-Policy) , politique d'ouverture cross-origin.

Par défaut, open est appelé dans la page window.open(<页面地址>), et COOP est utilisé pour limiter window.open()l'accès à la fenêtre ouverte par la méthode opener.

COOP a trois valeurs :

• unsafe-none
• same-origin-allow-popups
• same-origin

**Exemple :** Supposons qu'il y ait trois pages, appelez la page A window.open()pour ouvrir respectivement B et C (sans préciser noopeneret noreferrer), les adresses des trois pages sont :

• Page A : http://127.0.0.1:3000(Ouvrez le côté fenêtre)
• Page B : http://127.0.0.1:5000(le côté où la fenêtre est ouverte, source différente de A)
• Page C : http://127.0.0.1:3000(fenêtre ouverte, même origine que A)

Quelle que soit la valeur COOP de la page A, A peut obtenir et accéder aux références de contexte ( windowobjets) de B et C, et window.openerles valeurs auxquelles accèdent les pages B et C sont les suivantes :

	UNunsafe-none	UNsame-origin-allow-popups	UNsame-origin
Bunsafe-none	windowUn objet fenêtre	windowUn objet fenêtre	null
Bsame-origin-allow-popups	null	null	null
Bsame-origin	null	null	null
Cunsafe-none	windowUn objet fenêtre	windowUn objet fenêtre	null
Csame-origin-allow-popups	null	windowUn objet fenêtre	null
Csame-origin	null	null	windowUn objet fenêtre

Les règles se résument ainsi :

1. unsafe-noneA n'autorise que unsafe-noneles fenêtres avec le même paramètre à accéder à lui-même, qu'il soit ou non de la même origine
2. same-origin-allow-popupsA n'autorise l'accès à lui-même unsafe-nonequ'aux fenêtres de même et même originesame-origin-allow-popups
3. same-originA n'autorise same-originl'accès à lui-même qu'aux fenêtres de même et même origine

COOP empêche uniquement l'acquisition inversée des fenêtres ouvertes opener, ce qui équivaut à protéger les sites non fiables du serveur. Par rapport au fait de window.open()s'assurer que noopenerou est spécifié lors de l'appel noreferrer, COOP est plus pratique et plus sûr.

Cependant , COOP ne fournit que plusieurs scénarios de configuration basés sur trois valeurs et la même politique d'origine. Si vous souhaitez limiter le contexte d'accès mutuel de la fenêtre ouverte dans d'autres scénarios, vous devez toujours le spécifier dans la window.open()méthode noopener.

Enfin, il est recommandé de configurer l'en-tête de réponse Cross-Origin-Opener-Policyen tant que same-origin.