Loading

Domande frequenti sulla sicurezza della piattaforma dei servizi Salesforce CRM

Data pubblicazione: Jan 22, 2025
Descrizione


La seguente documentazione risponde alla domande più comuni sulla sicurezza della piattaforma App Cloud.

Inoltre, elenca i risultati falsi positivi più comuni ottenuti dalle valutazioni della sicurezza relative alla piattaforma App Cloud eseguite da terze parti.

 

Risoluzione

Sommario

 

 

Cookie sicuri

Perché alcuni cookie serviti dal dominio salesforce.com non sono impostati come sicuri o persistenti?
Molti cookie utilizzati dalla piattaforma per ottimizzare la funzionalità non contengono informazioni sulla sessione. Se alterati o acquisiti da un hacker, non possono essere utilizzati per ottenere l'accesso o inoltrare i privilegi al livello superiore. Il 'sid' del cookie di sessione è contrassegnato come sicuro e non persistente (ossia il cookie viene eliminato appena l'utente esce dal browser).

 

Perché il cookie di sessione non è impostato con il flag solo HTTP?
È possibile richiedere cookie HttpOnly per la propria organizzazione in Imposta | Controlli protezione | Impostazioni di sessione | Richiedi attributo HttpOnly. Questa operazione permette di impostare l'attributo HttpOnly solo per il SID del cookie di sessione.

 

Convalida dei dati

Perché i dati provenienti da particolari campi di input non vengono convalidati lato server prima del salvataggio in Oggetti?
I problemi di convalida o qualità dei dati come questi non rientrano nella categoria sicurezza. La maggior parte delle regole predefinite di convalida o qualità dei dati viene imposta lato client.

Un esempio può essere l'aggiornamento di un valore elenco di selezione a un valore non definito mediante l'API o la modifica di un post su una pagina standard.

Esempi di regole di convalida dei dati imposte lato server:

  • Impostazione di un ID ricerca per un ID record non esistente.
  • Tipo di dati di un campo, ad es. non è possibile impostare valori di testo in un campo numerico.
  • Impostazione di regole di convalida dei dati esplicite nelle regole di convalida oggetti o nei trigger Apex.

 

Clickjack

La piattaforma dispone di una protezione dal clickjack?
La protezione dal clickjack può essere abilitata da: Imposta | Controlli protezione | Impostazioni di sessione. Viene abilitata per impostazione predefinita per tutte le pagine Imposta di Salesforce.

È possibile impostare la protezione dal clickjack per un sito a uno dei seguenti livelli:

  • Consenti inserimento in frame da qualsiasi pagina (nessuna protezione)
  • Consenti inserimento in frame solo dalla stessa origine (consigliato)
  • Non consentire inserimento in frame da alcuna pagina (protezione massima)


Le comunità Salesforce hanno due contesti di protezione dal clickjack:

  • Comunità del sito Force.com, impostata dalla pagina dei dettagli del sito Force.com
  • Comunità del sito Site.com, impostata dalla pagina di configurazione di Site.com. Si consiglia di impostare lo stesso valore in entrambi i siti.


Per maggiori informazioni, consultare la nostra documentazione Abilita protezione dal clickjack.

 

Cross Site Request Forgery

La piattaforma dispone di protezioni da Cross-Site Request Forgery?
La protezione CSRF è abilitata per impostazione predefinita. È possibile visualizzare o modificare l'impostazione in Imposta | Controlli protezione | Impostazioni di sessione.

 

Perché i token CSRF di Salesforce vengono riutilizzati?
I token CSRF vengono assegnati a un particolare utente, all'entità utilizzata e alla sessione specifica e vengono riutilizzati nell'ambito della sessione di un utente.

Il token stesso viene generato in modalità casuale, così che sia impossibile per un hacker indovinarlo. Allo stesso modo, per un eventuale hacker ottenere l'ID sessione dell'utente sarà difficile quanto accedere al token CSRF.

 

Cross Site Scripting

La piattaforma dispone di protezioni da Cross-Site Scripting?
Tutte le pagine standard codificano in uscita i dati controllati dall'utente nel contesto in cui vengono utilizzati. Per le pagine Visualforce, tutti i campi di unione sono protetti da codice HTML per impostazione predefinita.

Eventuali vulnerabilità da cross-site scripting che si verificano nelle pagine Visualforce personalizzate devono essere eliminate seguendo le procedure ottimali consigliate e utilizzando gli strumenti forniti dagli sviluppatori.

Apex e Visualforce offrono utilità di codifica aggiuntive per altri contesti. Gli sviluppatori sono responsabili della corretta codifica in uscita per gli altri contesti non HTML.

Per maggiori informazioni, consultare la nostra documentazione Linee guida XSS per Apex e Visualforce.


Perché i dati non vengono codificati in ingresso al momento del salvataggio in Oggetti, come protezione da XSS?
La piattaforma implementa la codifica in ingresso contestuale per i dati controllati dall'utente. I dati Salesforce possono essere presentati in svariati contesti e sistemi, pertanto è difficile riuscire a prevedere l'esatto contesto dei dati in fase di input.

Le pagine standard sono progettate in modo tale da codificare correttamente i dati nel contesto preciso in cui viene visualizzato. Se è richiesta la codifica in ingresso, implementare dei trigger personalizzati sugli oggetti o sui campi desiderati.

 

Caricamento file

Sappiamo che è possibile che i file caricati da un utente malintenzionato contengano contenuti dannosi e che un utente che scarichi questi file potrebbe essere compromesso, se il software antivirus non rileva il pericolo.

In alternativa, i clienti che desiderano migliorare la sicurezza dei propri endpoint eseguendo la scansione di file caricati e scaricati da Salesforce possono farlo utilizzando prodotti di scansione di terze parti disponibili in Salesforce AppExchange. 

È possibile gestire certi tipi di file e alcuni comportamenti di caricamento o download in Imposta | Controlli protezione | Sicurezza caricamento e download dei file. Per altri tipi di file, alcuni trigger Apex personalizzati applicati agli oggetti correlati possono limitare le estensioni file caricate.

 

I file archiviati vengono scansionati per rilevare eventuali contenuti dannosi?
No, non viene eseguita la scansione dei file a tale scopo. I dati vengono archiviati in formato binario sui server Salesforce. Alcuni tipi di file vengono analizzati per scopi di indicizzazione della ricerca o per la visualizzazione dell'anteprima; sono stati impostati dei controlli per garantire che ciò avvenga in un ambiente isolato con privilegi limitati.

Anche le risorse elencate di seguito possono risultare utili:


File e allegati vengono archiviati all'interno dei servizi in modo tale che, nel caso in cui sia stato caricato del contenuto infetto, ciò non si ripercuote sul resto del servizio o su altri file grazie al modo in cui avviene l'archiviazione. Quindi, tutto ciò che possiamo fare è proteggere la piattaforma. Non possiamo controllare gli endpoint dei clienti, che sono tenuti a verificare che tali endpoint siano dotati di una protezione antivirus aggiornata.

Il livello app viene estrapolato dal livello infrastruttura grazie al nostro modello multi-tenant. Per questo motivo parliamo di due parti diverse: il livello infrastruttura che gestiamo e proteggiamo e il livello app in cui gli utenti possono caricare tutto ciò che vogliono in modo sicuro. Tuttavia, non possiamo sapere se un utente decide di caricare un file infetto o, come nel caso di alcuni nostri clienti, caricare intenzionalmente elementi che sanno essere infetti.

 

Esecuzione di query SQL arbitrarie

I risultati non contengono query SQL, ma SOQL, quindi non esiste alcun impatto in termini di sicurezza.

La richiesta è una chiamata alla nostra API REST che consente agli utenti di interrogare gli oggetti e i campi a cui possono già accedere in base alle impostazioni di controllo accesso impostate dall'amministratore dell'organizzazione.

L'API REST imposta le autorizzazioni corrette, incluse Condivisione, CRUD e FLS. In questo modo, all'utente non viene esposto nulla a cui non possa già accedere con la relativa autorizzazione, senza divulgare segreti, informazioni proprietarie o dati che potrebbero essere utili a un eventuale hacker.

Per maggiori informazioni sull'API REST e sulle query SOQL, vedere:

FRONTDOOR.JSP SID

FRONTDOOR.JSP SID si utilizza da login.salesforce.com; è una sessione temporanea non utilizzabile in fase di accesso. Il personale Salesforce sa che è possibile accedere tramite frontdoor.jsp?sid=<sessionid> mediante l'API (non sarà possibile utilizzare l'ID della sessione temporanea, ma il SID creato in fase di accesso).

Per la documentazione relativa a questo comportamento vedere Utilizzo di Frontdoor.jsp per collegare una sessione esistente in Salesforce.

 

JSESSIONID

JSESSIONID è l'ID di una sessione temporanea; i relativi cookie non sono utilizzabili. Il cookie principale della sessione è il SID, contrassegnato come sicuro.

 

Intestazioni HTTP

X-Content-Type-Options: no sniff
L'intestazione HTTP può essere attivata o disattivata dalle singole organizzazioni in Imposta | Controlli protezione | Impostazioni di sessione | Abilita protezione con sniffing di contenuti.

I browser possono ignorare l'intestazione relativa al tipo di contenuto restituita dal server e tentare di indovinarlo dal contenuto effettivo della risposta nel corpo. Ciò può essere sfruttato per forzare il browser a eseguire file JavaScript o CSS dannosi.

L'intestazione HTTP "X-Content-Type-Options: no sniff" impedisce che il browser indovini il tipo di file in base al relativo contenuto o al tag di integrazione. Il browser si conforma al tipo di contenuto inviato dal server.


Directive: referrer

Solo Aloha
Questa direttiva indica che, quando si passa da Salesforce a un dominio di terze parti, l'intestazione Referrer deve contenere solo il dominio Salesforce, non l'intero URL. Ciò impedisce la trasmissione di informazioni riservate dall'URL ad altri siti durante il caricamento degli asset (immagini, script) o quando si seleziona un link.

Referrer: https://domain.my.salesforce.com/page.jsp?oid=XXXXXX&secret=YYYYY diventa Referrer: https://domain.my.salesforce.com

L'intestazione Referrer rimane invariata nello stesso dominio.
 

HTTP Public Key Pinning

Public Key Pinning (HPKP) consente a un sito web di dichiarare l'elenco di certificati validi per lo stesso nell'intestazione HPKP inviata al server. Come per l'intestazione HSTS, queste informazioni sono valide per il periodo di tempo specificato nell'intestazione HPKP.

L'intestazione HPKP contiene un hash di tutte le chiavi pubbliche valide di qualsiasi certificato della catena. Come per l'intestazione CSP, è possibile segnalare esclusivamente eventuali violazioni e/o bloccare i certificati che non corrispondono.

Salesforce utilizza HPKP in modalità solo rapporto. Se il certificato non corrisponde a nessuno dei PIN il contenuto non viene bloccato.
 

Policy sulla sicurezza dei contenuti (CSP) - Segnalazione

Solo Aloha
L'intestazione di risposta Content-Security-Policy-Report-Only consente a Salesforce di monitorare l'uso di asset di terze parti allo scopo di rilevare i contenuti HTTP caricati sui siti web HTTPS.

Questa intestazione definisce dei criteri. Questi criteri vengono controllati dal browser (Chrome, Firefox e Safari, non Internet Explorer) su ogni pagina, ma non imposti. Il browser invia a Salesforce un rapporto per ogni violazione dei criteri rilevata. Questa intestazione è abilitata su tutte le pagine per impostazione predefinita (Aloha). Lightning adotta la propria CSP.

La policy sulla sicurezza dei contenuti è composta da una serie di direttive. In Aloha, le direttive indicano che gli asset (immagini, font per il web, fogli di stile, ecc.) si possono caricare tramite HTTPS oppure in linea.

La direttiva frame-ancestor indica che solo salesforce.com e force.com devono includere un IFRAME dei servizi Salesforce.
 

HTTP Strict Transport Security (HSTS)

L'intestazione HSTS è abilitata per login.salesforce.com, Dominio personale, il dominio di contenuti Lightning+, Visualforce, il sottodominio Comunità e il sottodominio Siti esterno alla comunità.

Per abilitare l'intestazione HSTS per tutti i Siti e le Comunità andare a Imposta | Controlli protezione | Impostazioni di sessione | Abilita HSTS per tutti i Siti e le Comunità con il sottodominio force.com predefinito che richiedono una connessione protetta (HTTPS)

Per abilitare l'intestazione HSTS per tutti i Domini personalizzati andare a  Imposta | Gestione domini | Fare clic su Nome dominio | Abilita intestazioni STS (Strict Transport Security)
 

Intestazione X-FRAME Options

I clienti possono impedire l'inclusione degli IFRAME Salesforce su un sito di terze parti abilitando 'Previeni clickjack' in Controlli protezione | Impostazioni di sessione | Protezione dal clickjack.

Consigliamo ai clienti di abilitare questa funzione per tutte le pagine VisualForce.

 

Varie

Caching: perché alcune risposte HTTP provenienti dalla piattaforma vengono archiviate nella cache dai browser? (Controllo cache impostato su Privato)
Salesforce le inserisce nella cache per motivi di prestazioni; questa operazione è controllata dalle direttive di risposta cache dell'intestazione HTTP. In questo caso il principale problema in termini di sicurezza si pone se un hacker ottiene l'accesso al computer client locale.

In questo scenario, per evitare l'accesso ai dati presenti nella cache, è necessario configurare i browser dell'utente in modo tale che non inserisca le richieste nella cache. Analizziamo caso per caso la necessità di non inserire nella cache particolari pagine o risorse, a seconda del contenuto archiviato nella cache stessa.

 

Salesforce intende dichiarare obsoleto l'uso delle cipher suite RC4 e 3DES?
Non è più disponibile il supporto per le cipher suite RC4 e 3DES per HTTPS.

Numero articolo Knowledge

000383448

 
Caricamento
Salesforce Help | Article