Loading

Häufig gestellte Fragen zur Sicherheit der Salesforce CRM-Service-Plattform

Veröffentlichungsdatum: Jan 22, 2025
Beschreibung


Die folgende Dokumentation enthält Antworten auf häufig gestellte Fragen zur Sicherheit der App Cloud-Plattform.

Darüber hinaus werden hier falsch-positive Ergebnisse der Sicherheitsbewertungen für die App Cloud-Plattform von Drittanbietern thematisiert.

 

Lösung

Inhalt

 

 

Sichere Cookies

Warum sind bestimmte Cookies, die über die Domäne von salesforce.com bereitgestellt werden, nicht als sicher oder persistent festgelegt?
Es gibt mehrere Cookies, die die Plattform zur Verbesserung der Funktionalität verwendet und die keine Sitzungsinformationen enthalten. Sie können nicht verwendet werden, um Zugang zu erhalten oder Berechtigungen zu erweitern, wenn sie von einem Angreifer verändert oder aufgerufen werden. Die sid des Sitzungscookies wird als "sicher" markiert und ist nicht persistent (d. h., das Cookie wird gelöscht, sobald der Benutzer den Browser schließt).

 

Warum ist für das Sitzungscookie nicht das HTTP Only-Flag festgelegt?
Unter Setup | Sicherheitssteuerungen | Sitzungseinstellungen | HttpOnly-Attribut erforderlich können Sie HttpOnly-Cookies für Ihre Organisation als erforderlich festlegen. Dadurch wird das HttpOnly-Attribut für das Sitzungscookie mit der SID festgelegt.

 

Datenvalidierung

Warum werden Daten aus bestimmten Eingabefeldern nicht serverseitig validiert, bevor sie in Objekten gespeichert werden?
Datenvalidierungs- oder Qualitätsprobleme wie diese fallen nicht in den Bereich Sicherheit. Die meisten Standardregeln zur Datenvalidierung oder -qualität werden clientseitig durchgesetzt.

Ein Beispiel hierfür ist das Aktualisieren eines Auswahllistenwerts auf einen nicht definierten Wert über die API oder das Ändern einer standardmäßigen POST-Anforderung zum Bearbeiten von Seiten.

Beispiele für Datenvalidierungsregeln, die serverseitig erzwungen werden:

  • Einrichten einer Nachschlage-ID für eine nicht vorhandene Datensatz-ID.
  • Mit dem Datentyp für ein Feld kann beispielsweise kein Zahlenfeld mit Textwerten festgelegt werden.
  • Explizite Datenvalidierungsregeln, die in Objektvalidierungsregeln oder Apex-Triggern eingerichtet werden.

 

Clickjacking

Verfügt die Plattform über Clickjack-Schutz?
Der Clickjack-Schutz kann aktiviert werden über: Setup | Sicherheitssteuerungen | Sitzungseinstellungen. Er ist für alle Salesforce-Setup-Seiten standardmäßig aktiviert.

Sie können den Clickjack-Schutz für eine Website auf eine der folgenden Ebenen festlegen:

  • Framing für alle Seiten zulassen (kein Schutz)
  • Framing nur für denselben Ursprung zulassen (empfohlen)
  • Framing für keine Seite zulassen (höchster Schutz)


Der Clickjack-Schutz von Salesforce Communities besteht aus zwei Teilen:

  • Der Force.com Communities-Site, die in Force.com auf der Seite "Site-Details" festgelegt wird
  • Der Site.com Communities-Site, die auf der Seite für die Site.com-Konfiguration festgelegt wird Es empfiehlt sich, für beide Einstellungen den gleichen Wert festzulegen.


Weitere Informationen finden Sie in der Dokumentation zum Aktivieren des Clickjack-Schutzes.

 

CrossSite Request Forgery

Verfügt die Plattform über einen Schutz vor Cross-Site Request Forgery?
Der CSRF-Schutz ist standardmäßig aktiviert. Sie können die Einstellung unter Setup | Sicherheitssteuerungen | Sitzungseinstellungen. anzeigen oder ändern.

 

Warum werden Salesforce CSRF-Token wiederverwendet?
Der Umfang von CSRF-Token ist für einen bestimmten Benutzer, eine bestimmte Einheit und Sitzung festgelegt.

Das Token selbst wird nach dem Zufallsprinzip generiert, sodass es von Angreifern nicht ermittelt werden kann. Für Angreifer ist es genauso schwierig, die Sitzungs-ID des Benutzers zu ermitteln wie das CSRF-Token.

 

Cross Site Scripting

Verfügt die Plattform über einen Schutz vor Cross-Site Scripting?
Alle Standardseiten codieren benutzergesteuerte Daten im richtigen Kontext, in dem sie verwendet werden. Bei VisualForce-Seiten sind alle Platzhalter standardmäßig HTML-codiert.

Alle Cross Site-Scripting-Schwachstellen, die auf benutzerdefinierten VisualForce-Seiten auftreten, müssen entsprechend den Empfehlungen für bewährte Vorgehensweisen und den für Entwickler bereitgestellten Tools behoben werden.

Apex und VisualForce bieten zusätzliche Tools zur Codierung für andere Kontexte. Entwickler sind für die richtige Ausgabecodierung für andere Nicht-HTML-Kontexte verantwortlich.

Weitere Informationen finden Sie in der Dokumentation Apex and VisualForce XSS guidelines (Richtlinien für Apex und VisualForce XSS).


Warum werden die Daten beim Speichern in Objekten nicht codiert, um sie vor XSS zu schützen?
Die Plattform implementiert eine kontextspezifische Ausgabecodierung für benutzergesteuerte Daten. Salesforce-Daten können in einer Vielzahl von Kontexten und Systemen dargestellt werden und es ist schwierig, den richtigen Kontext für die Daten zum Zeitpunkt der Eingabe zu erkennen.

Standardseiten sind so konzipiert, dass sie die Daten im entsprechenden Kontext, in dem sie angezeigt werden, richtig codieren. Wenn eine Eingabecodierung erforderlich ist, implementieren Sie benutzerdefinierte Auslöser für die gewünschten Objekte oder Felder, um die Eingabecodierung durchzuführen.

 

Datei-Upload

Wir wissen, dass Dateien, die von böswilligen Benutzern hochgeladen werden, schädliche Inhalte enthalten können und Benutzer, die die Datei herunterladen, gefährdet sein könnten, wenn Antiviren-Software die Datei nicht als schädlich erkennt.

Optional können Kunden, die die Sicherheit ihrer Endpunkte durch das Scannen von Dateien, die über Salesforce hoch- und heruntergeladen werden, verbessern möchten, hierfür Produkte von Drittanbietern verwenden, die auf Salesforce AppExchange zu finden sind. 

Bestimmte Dateitypen und das Verhalten beim Hoch- oder Herunterladen können Sie unter Setup | Sicherheitssteuerungen | Sicherheit für Hochladen und Herunterladen von Dateien verwalten. Die hochgeladenen Dateierweiterungen für andere Dateitypen können durch benutzerdefinierte Apex-Auslöser für verwandte Objekte eingeschränkt werden.

 

Werden gespeicherte Dateien auf schädliche Inhalte gescannt?
Dateien werden nicht auf schädliche Inhalte gescannt. Die Daten werden als Binärdateien auf Salesforce-Servern gespeichert. Bestimmte Dateitypen werden für die Suchindizierung oder für die Anzeige in der Vorschau analysiert. Es wurden Kontrollen eingerichtet, um sicherzustellen, dass dieser Vorgang in einer isolierten Umgebung mit eingeschränkten Berechtigungen ausgeführt wird.

Folgende Ressourcen können ebenfalls hilfreich sein:


Dateien und Anhänge werden innerhalb der Services so gespeichert, dass ein Upload von infizierten Dateien aufgrund der Art der Speicherung keine Auswirkungen auf die übrigen Services oder andere Dateien haben würde. Wir schützen also die Plattform und das ist alles, was wir tun können. Es liegt in der Verantwortung des Kunden, dafür zu sorgen, dass die Endpunkte mit einem aktuellen Virenschutz ausgestattet sind.

Daher wird zwischen der von uns verwalteten und geschützten Infrastrukturebene und der Anwendungsebene unterschieden, auf der die Benutzer alle gewünschten Daten sicher hochladen können. Es ist allerdings nicht möglich, zu kontrollieren, ob der Benutzer eine infizierte Datei oder, wie im Fall einiger unserer Kunden, absichtlich infizierte Daten hochlädt.

 

Beliebige Ausführung von SQL-Abfragen

Das Ergebnis enthält keine SQL, sondern SOQL, sodass es keine Sicherheitseinbußen gibt.

Die Anforderung ist ein an die REST-API gerichteter Aufruf, der es den Benutzern ermöglicht, Objekte und Felder abzufragen, auf die sie auf der Grundlage der vom Administrator der Organisation festgelegten Zugriffssteuerung bereits Zugriff haben.

Die REST-API erzwingt die richtigen Berechtigungen, einschließlich Freigabe, CRUD und FLS. Daher wird für die Benutzer nichts offengelegt, wofür sie nicht bereits eine Zugriffsberechtigung haben, und es werden keine Geheimnisse, geschützten Informationen oder für Angreifer nützliche Informationen offengelegt.

Weitere Informationen zu REST-API- und SOQL-Abfragen finden Sie an folgenden Stellen:

FRONTDOOR.JSP SID

Die über login.salesforce.com verwendete FRONTDOOR.JSP SID ist eine temporäre Sitzung, die bei der Anmeldung nicht verwendet werden kann. Salesforce ist bekannt, dass Sie sich über frontdoor.jsp?sid=<sessionid> über die API anmelden können (die temporäre Sitzungs-ID kann dabei nicht verwendet werden, aber die SID, die bei der Anmeldung erstellt wurde).

Eine Dokumentation zu diesem Verhalten finden Sie unter Verwenden von Frontdoor.jsp für die Anmeldung bei Salesforce..

 

JSESSIONID

JSESSIONID ist eine temporäre Sitzungs-ID und das Cookie kann nicht missbraucht werden. Das Hauptsitzungscookie ist die SID und diese ist als sicher gekennzeichnet.

 

HTTP-Kopfzeilen

X-Content-Type-Options: no sniff
Die HTTP-Kopfzeile kann unter Setup | Sicherheitssteuerungen | Sitzungseinstellungen | Schutz vor Inhaltsermittlung aktivieren für jede Organisation aktiviert oder deaktiviert werden.

Der vom Server zurückgegebene Content-Type-Header kann von Browsern ignoriert werden und es kann vorkommen, dass der Content-Type anhand des tatsächlichen Inhalts der Textantwort ermittelt wird. Dies kann ausgenutzt werden, um die Ausführung von bösartigem JavaScript oder CSS im Browser zu erzwingen.

Mit der Option "HTTP header X-Content-Type-Options: nosniff" wird verhindert, dass der Browser den Dateityp anhand des Inhalts oder Einbettungs-Tags ermittelt. Der Browser akzeptiert den vom Server gesendeten Content-Type.


Directive: referrer

Nur Aloha
Diese Direktive gibt an, dass der Referrer-Header bei der Weiterleitung von Salesforce zu einer fremden Domäne nur die Salesforce-Domäne und nicht den vollständigen URL enthalten soll. Dadurch wird verhindert, dass vertrauliche Informationen vom URL an andere Websites weitergegeben werden, wenn Datenbestände (Bilder, Skripts) geladen werden oder ein Benutzer auf einen Link klickt.

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

Der Referrer-Header bleibt innerhalb derselben Domäne unverändert.
 

HTTP Public Key Pinning

Public Key Pinning (HPKP, Verankerung öffentlicher Schlüssel) bietet die Möglichkeit, die Liste gültiger Zertifikate für eine Website im an den Server gesendeten HPKP-Header anzugeben. Wie bei HSTS sind diese Informationen für die im HPKP-Header angegebene Zeitspanne gültig.

Der HPKP-Header enthält einen Hash-Wert aller gültigen öffentlichen Schlüssel aller SSL-Zertifikate in der Kette. Wie bei CSP ist es möglich, nur Verstöße zu melden und/oder nicht übereinstimmende Zertifikate zu blockieren.

Salesforce verwendet HPKP nur im Berichtsmodus (report-only). Wenn das Zertifikat mit keiner der PINs übereinstimmt, wird kein Inhalt blockiert.
 

Inhaltssicherheitsrichtlinie (CSP): Berichterstellung

Nur Aloha
Mit dem Antwortheader "Content-Security-Policy-Report-Only" kann Salesforce die Verwendung von Drittanbieter-Datenbeständen überwachen, um HTTP-Inhalte zu erkennen, die auf HTTPS-Websites geladen werden.

Mit diesem Header wird eine Richtlinie definiert. Die Richtlinie wird vom Browser (Chrome, Firefox und Safari - nicht Internet Explorer) auf jeder Seite überprüft, aber nicht durchgesetzt. Der Browser sendet bei jedem Verstoß gegen die Richtlinie einen Bericht an Salesforce. Dieser Header ist auf allen Seiten standardmäßig aktiviert (Aloha). Lightning setzt eine eigene Inhaltssicherheitsrichtlinie durch.

Die Inhaltssicherheitsrichtlinie besteht aus mehreren Direktiven. In Aloha geben die Direktiven an, dass Datenbestände (Bilder, Webschriftarten, Formatvorlagen usw.) über HTTPS oder inline geladen werden können.

Die Direktive "frame-ancestor" gibt an, dass nur salesforce.com und force.com einen IFRAME der Salesforce-Services enthalten sollen.
 

HTTP Strict Transport Security (HSTS)

HSTS ist für login.salesforce.com, MyDomains, Lightning- und Inhaltsdomänen, VisualForce, die Communities-Unterdomäne und die Nicht-Community-Sites-Unterdomäne aktiviert.

HSTS für alle Sites und Communities kann unter Setup | Sicherheitssteuerungen | Sitzungseinstellungen | HSTS für alle Sites und Communities mit der standardmäßigen force.com-Unterdomäne aktivieren, die eine sichere Verbindung (HTTPS) erfordern aktiviert werden

HSTS für alle benutzerdefinierten Domänen kann unter Setup | Domänenverwaltung | Klick auf den Domänennamen | Strict Transport Security-Kopfzeilen aktivieren aktiviert werden.
 

Kopfzeile "X-FRAME Options"

Kunden können das Einfügen von Salesforce-IFRAMEs auf Drittanbieter-Sites verhindern, indem Sie unter Sicherheitssteuerungen | Sitzungseinstellungen | Clickjack-Schutz die Option "Clickjacking verhindern" aktivieren.

Es wird empfohlen, dass Kunden diese Funktion für alle Visualforce-Seiten aktivieren.

 

Verschiedenes

Zwischenspeicherung: Warum werden bestimmte HTTP-Antworten der Plattform in Browsern zwischengespeichert? (Cache-Steuerung ist auf "Privat" gesetzt)
Salesforce speichert die Daten aus Leistungsgründen im Cache. Dies wird über HTTP-Header-Cache-Antwortdirektiven gesteuert. Das größte Sicherheitsproblem besteht hier darin, dass Angreifer Zugriff auf den lokalen Client-Computer erhalten.

Damit das Risiko des Zugriffs auf die im Cache gespeicherten Daten in diesem Szenario verringert wird, sollten Sie die Browser der Benutzer so konfigurieren, dass Anforderungen nicht zwischengespeichert werden. Es wird von Fall zu Fall und abhängig vom Inhalt geprüft, ob bestimmte Seiten oder Ressourcen nicht zwischengespeichert werden sollten.

 

Stellt Salesforce die Verwendung der RC4- und 3DES-Ciphersuites ein?
Die RC4- und 3DES-Verschlüsselungen für HTTPS werden nicht mehr unterstützt.

Nummer des Knowledge-Artikels

000383448

 
Laden
Salesforce Help | Article