This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten
← A5-Sicherheitsrelevante Fehlkonfiguration | A7-Fehlerhafte Autorisierung auf Anwendungsebene → |
Anwendungs- spezifisch |
Ausnutzbarkeit SCHWIERIG |
Verbreitung SELTEN |
Auffindbarkeit DURCHSCHNITTLICH |
Auswirkung SCHWERWIEGEND |
Anwendungs-/ Geschäftsspezifisch |
Jeder mit Zugriff auf Ihre vertraulichen Daten (Backups inkl.) ist zu betrachten. Das betrifft die Speicherung, die Übertragung und auch die Daten im Browser der Kunden. Externe und interne Bedrohungen sind relevant. | Angreifer brechen i.d.R. nicht die Verschlüsselung selbst. Stattdessen stehlen sie Schlüssel, führen Seiten- oder MITM-Angriffe aus oder stehlen Klartext vom Server, während der Übertragung oder aus dem Browser des Kunden heraus. | Fehlende Verschlüsselung vertraulicher Daten ist die häufigste Schwachstelle. Die Nutzung von Kryptographie erfolgt oft mit schwacher Schlüsselerzeugung und -verwaltung und der Nutzung schwacher Algorithmen, insbesondere für das Password Hashing. Browser Schwachstellen sind verbreitet und leicht zu finden, aber nur schwer auszunutzen. Ein eingeschränkter Zugriff lässt ext. Angreifer Probleme auf dem Server i.d.R. nur schwer finden und ausnutzen. | Fehler kompromittieren regelmäßig vertrauliche Daten. Es handelt sich hierbei oft um sensitive Daten wie personenbezogene Daten, Benutzernamen und Passwörter oder Kreditkarteninformationen. | Betrachten Sie den Wert verlorener Daten und die Auswirkungen auf die Reputation des betroffenen Unternehmens. Hat es ggf. auch juristische Konsequenzen, wenn die Daten bekannt werden? |
Mögliche Angriffsszenarien
Szenario 1: Eine Anwendung verschlüsselt Kreditkartendaten automatisch bei der Speicherung in einer Datenbank. Das bedeutet aber auch durch SQL-Injection erlangte Kreditkartendaten in diesem Fall automatisch entschlüsselt werden. Die Anwendung hätte die Daten mit eine Public Key verschlüsseln sollen und nur nachgelagerte Anwendungen und nicht die Webanwendung selbst hätten die Daten mit dem Private Key entschlüsseln dürfen. |
Wie kann ich 'Verlust der Vertraulichkeit sensibler Daten' verhindern?
Eine Übersicht über alle Tücken unsicherer Kryptografie, SSL-Verwendung und Datensicherheit liegt weit außerhalb der Top 10. Für alle vertraulichen Daten sollten Sie zumindest:
|
JAVA-Teil 1: Kryptografisch unsichere Speicherung
Verteidigungs-Option 1 gegen 'Verlust der Vertraulichkeit sensibler Daten':
Ein einfaches Beispiel für die Veschlüsselung von Texten, hier mit dem AES-128 Algorithmus. Die Auswahl an Verschlüsselungsparametern wie beispielsweise Algorithmus, Ciphermodus oder Schlüssellänge ist groß und kommt immer auf die jeweiligen Daten und die Anwendung an. String plainText = "HelloWorld";
CipherText ciphertext =
|
Verteidigungs-Option 2 gegen 'Verlust der Vertraulichkeit sensibler Daten':
Beispiele für das Hashen von Passwörtern. Um die Sicherheit zu erhöhen sollte jedes Passwort mit einem Zufallswert (Salt) berechnet und gespeichert werden sowie möglichst viele Iterationen beim Hashing genutzt werden. String password = "mypassword";
}
Sicherer ist allerdings die Nutzung einer PBKDF2 (Password-Based Key Derivation Function 2) wie im folgenden Beispiel: public byte[] generatePBKDF2Hash(String password)
}
Eine weiterer empfohlener Algorithmus ist bcrypt, hier bespielsweise unter Verwendung der jBCrypt-Bibliothek (siehe Referenzen). String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12)); Zu bcrypt gibt es mittlerweile eine noch sicherere Variante scrypt, der Link zu einer Beispielimplementierung findet sich bei den Referenzen. |
Verteidigungs-Option 3 gegen 'Verlust der Vertraulichkeit sensibler Daten':
Um geheime Schlüssel sicher, aber auch gleichzeitig einfach zugänglich und austauschbar aufzubewahren empfiehlt sich eine spezielle Schlüsseldatei, wie beispielweise der Java KeyStore. In dieser Datei werden die Schlüssel mit einem Master-Password gesichert, die Datei selbst sollte getrennt von den verschlüsselten Daten abgelegt werden: // Erzeugung eines symmetrischen Schlüssels mittels der vorher beschriebenen PBKDF2
KeyStore.SecretKeyEntry entry = new KeyStore.SecretKeyEntry(mySecretKey); |
Referenzen
OWASP
Andere
|
JAVA-Teil 2: Unzureichende Absicherung der Transportschicht
Verteidigungs-Option 1 gegen 'Verlust der Vertraulichkeit sensibler Daten':
Um die Verschlüsselung auf der Transportebene sollte sich der Entwickler nie selbst kümmern, sondern dies immer dem Webserver überlassen. Im J2EE-Deployment-Descriptor der Anwendung (= web.xml) ist die folgende Konfiguration vorzunehmen, um sicherzustellen, dass nur ausschließlich über https kommuniziert wird: <security-constraint>
</security-constraint>
<session-config>
</session-config>
Header set Cache-Control "no-cache, no store, must-revalidate" Weitere Hinweise im Transport Layer Protection Cheat Sheet |
Verteidigungs-Option 2a gegen 'Verlust der Vertraulichkeit sensibler Daten':
Sichere Verschlüsselung
SSLProtocol +TLSv1.2 # for Cipher-String 'A+', 'A' Anmerkungen: - Der Cipher-String mit den SSL-Cipher-Suites wurde als Whitelist formuliert, um die serverseitige Kompatibilität mit alten Versionen von OpenSSL zu erhöhen.
openssl ciphers -V "DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256" 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
Achtung/CAUTION: Der Cipher-String wurde nur mit einzelnen, älteren OpenSSL-Versionen getestet, es können ungewollt weitere Cipher-Suiten dadurch benutzt werden. (ONLY tested with some elder Versions of OpenSSL!)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Verteidigungs-Option 2b gegen 'Verlust der Vertraulichkeit sensibler Daten':
Wirksamer Schutz gegen Man In The Middle-Angriffe
Header set Strict-Transport-Security
HTTP Strict Transport Security |
Referenzen
OWASP
Andere
|
Comment: Bitte senden Sie uns weitere gute Beispiele mit PHP für diesen Abschnitt.
Verteidigungs-Option 2 gegen 'Verlust der Vertraulichkeit sensibler Daten':
Um vorerstellte Hash-Tabellen zu verhindern, kann jedem Datensatz eine zufällige Zeichenfolge hinzugefügt werden, welche als Salt (Deutsch: Salz) bezeichnet wird. Ein Beispiel für die sichere Erstellung eines Hashwerts ist im Folgendemn gegeben. Dafür muss das GIT-Projekt [4] eingebunden werden, ab PHP-Version 5.5 ist dies im Kern enthalten. Das Salt wird bspw. bei einem Linuxsystem in der Funktion password_hash() durch Zugriff auf /dev/urandom erstellt. Der Rückgabewert der Funktion ist eine Zeichenkette und beinhaltet u.a. den Hashwert, das Salt und den genutzten Algorithmus. Die Kosten, welche die Anzahl der Hash-Iterationen angeben, können über den dritten Parameter festgelegt werden. $options = [
];
} else {
} |
Referenzen
OWASP
Andere
|
← A5-Sicherheitsrelevante Fehlkonfiguration | A7-Fehlerhafte Autorisierung auf Anwendungsebene → |