Loading

FAQ sur la sécurité de la plate-forme des services Salesforce CRM

Date de publication: Jan 22, 2025
Description


La documentation suivante offre des réponses aux questions de sécurité courantes pour la plate-forme App Cloud.

Elle couvre également les recherches de faux positifs courants à partir des évaluations de sécurité tierce sur la plate-forme App Cloud.

 

Résolution

Table des matières

 

 

Secure Cookies

Pourquoi certains cookies du domaine salesforce.com ne sont-ils pas définis comme étant sécurisés ou persistants ?
Il y a plusieurs cookies que la plate-forme utilise pour améliorer la fonctionnalité qui ne contiennent aucune information de session. Ils ne peuvent pas être utilisés pour avoir accès ou augmenter les privilèges s'ils sont modifiés ou accédés par un attaquant. Le cookie de session « sid » est marqué comme étant sécurisé et n'est pas persistant (c'est-à-dire que le cookie est supprimé lorsque l'utilisateur quitte le navigateur).

 

Pourquoi le cookie de session n'est-il pas défini avec l'indicateur HttpOnly ?
Vous pouvez exiger les cookies HttpOnly pour votre organisation dans Installation | Contrôles de sécurité | Paramètres de session | Exiger un attribut HttpOnly. Cela définira l'attribut HttpOnly uniquement pour le cookie de session SID.

 

Validation de données

Pourquoi les données des champs d'entrée particuliers ne sont-elles pas validées côté serveur avant l'enregistrement dans les objets ?
Les problèmes de validation ou de qualité des données comme ceux-là ne relèvent pas de la sécurité. La plupart des règles de validation ou de qualité des données par défaut sont appliquées côté client.

Un exemple est l'actualisation d'une valeur de liste de choix vers une valeur non définie via l'API ou la modification d'une édition de page standard POST.

Exemples de règles de validation de données appliquées côté serveur :

  • Définition d'un ID de recherche vers un ID d'enregistrement non existant.
  • Type de données pour un champ, par exemple, ne peut pas définir un champ numérique avec des valeurs de texte.
  • Installation des règles de validation de données explicites dans les règles de validation d'objets ou les déclencheurs Apex.

 

Détournement de clics

La plate-forme dispose-t-elle d'une protection contre le détournement de clic ?
La protection contre le détournement de clic peut être activée via : Installation | Contrôles de sécurité | Paramètres de session. Elle est activée par défaut pour toutes les pages d'installation Salesforce.

Vous pouvez définir la protection contre le détournement de clic pour un site à un des niveaux suivants :

  • Autoriser la formulation par n'importe quelle page (aucune protection)
  • Autoriser la formulation par la même origine seulement (recommandé)
  • N'autoriser la formulation par aucune page (plus grande protection)


Les communautés Salesforce ont deux parties de protection contre le détournement de clic :

  • Le site des communautés Force.com, défini à partir de la page de détails du site Force.com
  • Le site des communautés Site.com, défini à partir de la page de configuration Site.com. Il est recommandé que les deux aient la même valeur.


Pour plus d'informations, consultez notre documentation Activation de la protection contre le détournement de clic.

 

Cross site request forgery

La plate-forme dispose-t-elle de protections Cross site request forgery ?
La protection CSRF est activée par défaut. Vous pouvez voir ou modifier les paramètres via installation | Contrôles de sécurité | Paramètres de sessions.

 

Pourquoi les jetons CSRF Salesforce sont-ils réutilisés ?
Les jetons CSRF sont limités à un utilisateur en particulier, à une entité exploitée et à une session, et sont réutilisés dans la session d'un utilisateur.

Le jeton lui-même est généré aléatoirement afin qu'il ne puisse pas être deviné par un attaquant. Il sera aussi difficile pour un attaquant d'obtenir l'ID de session de l'utilisateur que le jeton CSRF.

 

Cross site scripting

La plate-forme dispose-t-elle de protections Cross site scripting ?
Toutes les pages standard génèrent des données codées contrôlées par l'utilisateur dans le contexte approprié dans lequel elles sont utilisées. Pour les pages VisualForce, tous les champs fusionnés sont codés HTML par défaut.

Chaque vulnérabilité Cross site scripting se produisant à partir des pages personnalisées VisualForce doit être traitée avec les recommandations des meilleures pratiques et les outils fournis aux développeurs.

Apex et VisualForce fournissent des utilitaires de codage supplémentaires pour d'autres contextes. Les développeurs sont responsables du codage de sortie approprié pour les autres contextes non HTML.

Pour plus d'informations, consultez notre documentation Directives Apex et VisualForce XSS.


Pourquoi les données d'entrée ne sont-elles pas codées lors de l'enregistrement dans les objets pour se protéger contre XSS ?
La plate-forme implémente au codage de sortie de contexte spécifique pour les données contrôlées par l'utilisateur. Les données Salesforce peuvent être présentées dans une multitude de contextes et de systèmes, et il est difficile d'anticiper avec succès le bon contexte des données au moment de l'entrée.

Les pages standard sont conçues pour coder correctement les données dans le bon contexte dans lequel elles sont affichées. Si le codage d'entrée est requis, implémentez les déclencheurs personnalisés sur les objets ou les champs désirés pour effectuer un encodage d'entrée.

 

Envoi de fichiers

Nous sommes conscients qu'il est possible que les fichiers chargés par un utilisateur malveillant contiennent du contenu malveillant. L'utilisateur qui télécharge le fichier pourrait être compromis si le logiciel antivirus ne détecte pas le fichier comme étant malveillant.

En option, les clients qui souhaiteraient améliorer la sécurité de leur point de terminaison en analysant les fichiers chargés et téléchargés à partir de Salesforce peuvent le faire en utilisant des produits d'analyse tiers détectés dans Salesforce AppExchange. 

Certains types de fichiers et comportements de chargement ou de téléchargement peuvent être gérés dans Installation | Contrôles de sécurité | Sécurité d'envoi et de téléchargement de fichiers. Pour les autres types de fichiers, les déclencheurs Apex personnalisés des objets associés peuvent limiter les extensions du fichier chargées.

 

Les fichiers stockés sont-ils analysés pour le contenu malveillant ?
Les fichiers ne sont pas analysés pour le contenu malveillant. Les données sont stockées sous forme binaire dans les serveurs Salesforce. Certains types de fichiers sont analysés pour l'indexation de recherche ou pour l'affichage d'aperçu et des contrôles ont été mis en place afin d'assurer que cela se produit dans un environnement isolé avec des privilèges limités.

Les ressources suivantes peuvent également être utiles :


Les fichiers et les pièces joints sont stockés dans les services de telle manière que si quelque chose d'infecté a été chargé, il n'y aura aucun impact sur le reste du service ou sur les autres fichiers en raison de la façon dont il est stocké. De ce fait, tout ce que nous pouvons faire est de protéger la plate-forme. Nous ne pouvons pas contrôler les points de terminaison du client, et il en est de leur responsabilité d'assurer que ces points de terminaison ont une protection antivirus à jour.

La couche d'application est abstraite à partir de la couche d'infrastructure via notre modèle multilocataire (la couche d'infrastructure que nous gérons et protégeons et la couche d'application dans laquelle les utilisateurs peuvent charger en toute sécurité tout ce qu'ils veulent). C'est la raison pour laquelle nous parlons depuis deux parties différentes. Mais nous ne pouvons pas contrôler le choix de l'utilisateur concernant le chargement d'un fichier infecté, ou dans le cas de certains de nos clients, charger intentionnellement des éléments connus pour être infectés.

 

Exécution de requête SQL arbitraire

La recherche ne contient pas de SQL, mais plutôt de SOQL, donc il n'y a pas d'impact sur la sécurité…

La demande est un appel à notre REST API qui autorise les utilisateurs à interroger les objets et les champs auxquels ils peuvent déjà accéder, selon les paramètres de contrôle d'accès définis par l'administrateur de l'organisation.

Le REST API applique les bonnes autorisations, y compris Sharing, CRUD et FLS. Par conséquent, l'utilisateur ne voit que ce dont il a déjà l'autorisation d'accéder. De plus, aucun secret, information exclusive ou information utile à un attaquant n'est exposé.

Pour plus d'informations sur le REST API et les requêtes SOQL, consultez :

FRONTDOOR.JSP SID

FRONTDOOR.JSP SID utilisé via login.salesforce.com est une session temporaire qui ne peut pas être utilisée lors de la connexion. Salesforce est conscient de la possibilité de se connecter via frontdoor.jsp?sid=<sessionid> via l'API (vous ne pourrez pas utiliser l'ID de session temporaire, mais le SID créé lors de la connexion).

Pour obtenir de la documentation sur ce comportement, consultez Utilisation de Frontdoor.jsp pour vous connecter à Salesforce​.

 

JSESSIONID

JSESSIONID est un ID de session temporaire et le cookie ne peut pas être exploité. Le principal cookie de session est le SID et il est marqué comme étant sécurisé.

 

En-tête HTTP

X-Content-Type-Options: no sniff
L'en-tête HTTP peut être allumé ou éteint par chaque organisation dans Installation | Contrôles de sécurité | Paramètres de session | Activer la protection contre le reniflage de contenu.

Les navigateurs peuvent ignorer l'en-tête Content-Type retourné par le serveur et deviner le content-type à partir du contenu actuel du corps de réponse. Cela peut être utilisé pour forcer le navigateur à exécuter des JavaScript ou CSS malveillants.

L'en-tête HTTP X-Content-Type-Options: nosniff empêche le navigateur de deviner le type de fichier selon son contenu ou la balise d'intégration. Le navigateur obéit au content-type envoyé par le serveur.


Directif : référent

Aloha uniquement
Cette directive indique que lors du passage du domaine Salesforce vers un domaine tiers, l'en-tête Référent ne doit contenir que le domaine Salesforce et non pas l'URL complète. Cela empêche la fuite d'informations confidentielles à partir de l'URL vers d'autres sites lors du chargement de ressources (images, scripts) ou en cliquant sur un lien.

Référent : https://domain.my.salesforce.com/page.jsp?oid=XXXXXX&secret=YYYYY devient Référent : https://domain.my.salesforce.com

L'en-tête Référent reste inchangé dans le même domaine.
 

HTTP Public Key Pinning

L'épinglage de clé publique (HPKP) autorise un site Web à déclarer la liste des certificats valides pour ce site Web dans l'en-tête HPKP envoyé au serveur. De la même manière que HSTS, cette information est valide pendant la durée spécifiée dans l'en-tête HPKP.

L'en-tête HPKP contient un hachage de toutes les clés publiques valides de n'importe quel certificat SSL de la chaîne. De la même manière que CSP, il est possible de ne signaler que les violations et/ou de bloquer les incompatibilités de certificats.

Salesforce utilise HPKP dans le mode rapport uniquement. Aucun contenu n'est bloqué si le certificat ne correspond à aucun des PIN.
 

Content Security Policy : rapports

Aloha uniquement
L'en-tête de réponse Content-Security-Policy-Report-Only autorise Salesforce à surveiller l'utilisation de ressources tierces dans le but de détecter le contenu HTTP chargé sur les sites Web HTTPS.

Cet en-tête définit une stratégie. La stratégie est vérifiée par le navigateur (Chrome, Firefox et Safari, pas Internet Explorer) sur chaque page mais n'est pas appliquée. Le navigateur envoie un rapport à Salesforce pour chaque violation de stratégie. Cet en-tête est activé par défaut sur toutes les pages (Aloha). Lightning applique ses propres CSP.

La stratégie de sécurité de contenu est faite à partir de plusieurs directives. Chez Aloha, les directives indiquent quelles ressources (images, polices Web, feuilles de style, etc.) peuvent être chargées sur HTTP ou en ligne.

La directive frame-ancestor indique que seuls salesforce.com et force.com doivent inclure un IFRAME des services Salesforce.
 

HTTP Strict Transport Security (HSTS)

HSTS est activé pour login.salesforce.com, MyDomains, sur le domaine de contenu Lightning +, VisualForce, le sous-domaine Communautés et sur le non communautaire, sous-domaine Sites.

Le HSTS pour tous les sites et communautés peut être activé dans Installation | Contrôles de sécurité | Activer HSTS pour tous les sites et communautés avec le sous-domaine par défaut force.com nécessitant une connexion sécurisée (HTTPS)

Le HSTS pour tous les domaines personnalisés peut être activé dans  Installation | Gestion de domaine | Cliquez sur Nom de domaine | Activer les en-têtes Strict Transport Security
 

En-tête X-FRAME Options

Les clients peuvent empêcher l'inclusion d'IFRAMES Salesforce de site tiers en activant « Empêcher le détournement de clic » dans Contrôles de sécurité | Paramètres de session | Protection contre le détournement de clic.

Nous recommandons au client d'activer cette fonctionnalité pour toutes les pages VisualForce.

 

Divers

Mise en cache : pourquoi certaines réponses HTTP de la plate-forme sont-elles mises en cache par les navigateurs ? (Cache-Control défini sur Privé)
Salesforce met en cache pour des raisons de performances et cela est contrôlé via les directives de réponse du cache d'en-tête HTTP. Le principal problème de sécurité ici est si un attaquant réussit à accéder à la machine client locale.

Pour réduire l'accès aux données mises en cache dans ce scénario, configurez les navigateurs des utilisateurs pour ne pas mettre en cache les demandes. Nous examinons au cas par cas si certaines pages ou ressources ne doivent pas être mises en cache, selon le contenu mis en cache.

 

Salesforce désapprouve-t-il l'utilisation des suites cartographiques RC4 et 3DES ?
Les chiffres RC4 et 3DES pour HTTPS ne sont plus pris en charge.

Numéro d’article de la base de connaissances

000383448

 
Chargement
Salesforce Help | Article