Paramètres de connexion sécurisée (HTTPS)

Nom du contrôle

Paramètres de connexion sécurisée (HTTPS)

Configuration recommandée

• Activer Forcer la reconnexion après la connexion en tant qu'utilisateur
• Activer Demander l'attribut HTTPOnly
• Forcer les plages IP de connexion à chaque requête
• Activez Utiliser la demande de publication pour envoyer des informations sur les sessions inter-domaines

Configuration>Paramètres de session>Forcer la reconnexion après la connexion en tant qu'utilisation|Exiger un attribut HTTPOnly|Plages IP de connexion à chaque requête|Utiliser Post Request pour envoyer des informations de session pour des sessions inter-domaines.

Vue d'ensemble du contrôle

Cette infrastructure de contrôle à plusieurs niveaux renforce l'intégrité de la session en imposant la validation IP continue pour chaque requête et en protégeant les jetons de session contre tout accès non autorisé aux scripts via l'attribut HTTPOnly. De plus, il évite les fuites de session pendant la navigation inter-domaines en utilisant des requêtes POST et garantit la responsabilité administrative en exigeant une nouvelle connexion immédiatement après toute session « Se connecter en tant que ».

Risque de sécurité s'il n'est pas configuré

Si vous n'activez pas ces contrôles, les sessions sont exposées à des attaques par script inter-site (XSS) et à une fuite d'URL pendant la navigation inter-domaines, ce qui augmente considérablement le risque de piratage de session. De plus, l'organisation est confrontée à la persistance d'un accès non autorisé si des utilisateurs se déplacent vers des réseaux non approuvés en cours de session ou si des administrateurs maintiennent des sessions actives après avoir usurpé l'identité d'utilisateurs sans réauthentification.

Scénarios de menace

Un assaillant exploite une vulnérabilité de script inter-site (XSS) pour voler un cookie de session qui n'est pas protégé par HTTPOnly, puis conserve de façon transparente l'accès à partir d'un réseau non approuvé, car le système ne parvient pas à revérifier l'adresse IP de l'utilisateur à chaque requête. Pendant ce temps, des ID de session confidentiels sont divulgués dans les journaux de navigateur pendant la navigation inter-domaines, et un compte administrateur piraté reste actif et sans contestation longtemps après la fin d'une session « Se connecter en tant que ».

Plage de score CVSS estimée

Critique (9,0 à 10,0).

Considérations relatives à l'impact sur le risque

Le nombre d'utilisateurs, les divers profils attribués aux utilisateurs et les données ou objets auxquels chaque profil a accès.

Risque plus élevé quand

Le risque de laisser ces paramètres désactivés est considérablement accru par l'absence d'une stratégie de sécurité des contenus (CSP) robuste, qui rend le système vulnérable aux scripts qui peuvent facilement supprimer les cookies de session si l'attribut HTTPOnly est manquant.

Risque faible ou nul

Pour limiter les risques lorsque ces paramètres de sécurité de session spécifiques ne sont pas activés, vous pouvez implémenter une stratégie « Défense en profondeur » en utilisant les contrôles compensatoires suivants :

• Authentification multifacteur obligatoire (MFA) : Même si un ID de session est divulgué via une URL (POST manquant) ou volé via un script (HTTPOnly manquant), un assaillant sera toujours mis en cause pour un deuxième facteur s'il tente d'exécuter des actions à haut risque ou de rétablir l'accès.
• Expiration de session plus stricte : Si vous ne forcez pas une reconnexion après une session « Connexion en tant que », la réduction de l'expiration globale de la session (par exemple, à 15 ou 30 minutes) limite la période de validité d'une session non suivie ou piratée.
• Plages IP de connexion au niveau du profil : Bien que l'idéal soit de « forcer à chaque requête », la définition de plages IP strictes au niveau Profil garantit que la session initiale peut être établie uniquement à partir d'un réseau de confiance.
• Stratégie de sécurité des contenus (CSP) robuste : Une CSP bien configurée peut empêcher l'exécution de scripts malveillants, ce qui réduit considérablement le danger de ne pas avoir l'attribut HTTPOnly dans vos cookies.
• Sanitisation stricte des entrées et codage des sorties : En empêchant le Cross-Site Scripting (XSS) au niveau du code (composants LWC/Aura), vous retirez la méthode principale qu'un assaillant utiliserait pour voler les jetons de session qui ne sont pas protégés par HTTPOnly.

Considérations relatives à l'entreprise et à l'intégration

L'implémentation de ces contrôles renforce considérablement la sécurité, mais les reconnections fréquentes après les sessions de support peuvent gêner les utilisateurs mobiles si leurs adresses IP changent pendant une session.

Remédiation recommandée

Implémentez des paramètres de connexion sécurisés sur la plate-forme.

Guide d'examen sanitaire de sécurité

Security Health Review vérifie si les paramètres de connexion sécurisée sont appliqués dans l'organisation pour sécuriser les sessions.