OWASP - User contributions [en]

User:Michal Vossberg

2013-07-04T11:57:35Z

Michal Vossberg:

Security Architect

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-07-04T11:55:01Z

Michal Vossberg:

{{Top_10_2010_Developer_Edition_De:TopTemplate
|useprev=PrevLink_Germany_Projekte
|usenext=NextLink_Germany_Projekte
|prev=Top_10_fuer_Entwickler/A6_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|6
|language=de
|year=2010}}
|next=Top_10_fuer_Entwickler/A8_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|8
|language=de
|year=2010}}
}}
== Seite in Bearbeitung (BAUSTELLE!!) ==

== A7 Kryptografisch unsichere Speicherung ==

{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate|year=2010|language=de}}
{{Top_10:SummaryTableTemplate|exploitability=3|prevalence=3|detectability=2|impact=1|language=de|year=2013}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder Benutzer des Systems ist zu betrachten.
Haben diese ein Interesse, auf geschützte Daten unberechtigt zuzugreifen?
Wie steht es um Administratoren?</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer brechen üblicherweise nicht die eigentliche Kryptografie. Statt dessen finden Sie Schlüssel, Klartexte oder greifen über Kanäle mit automatischer Entschlüsselung auf Daten zu.</td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Fehlende Verschlüsselung vertraulicher Daten ist die häufigste Schwachstelle, gefolgt von unsicherer Schlüsselerzeugung, der Speicherung statischer Schlüssel und die Nutzung schwacher Algorithmen. Schwache Hashwerte ohne Salt kommen zum Passwortschutz oft vor. Ein eingeschränkter Zugriff lässt externe Angreifer solche Probleme i.d.R. nicht leicht entdecken. Den nötigen Zugriff müssen sie vorher auf andere Weise erlangen.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Fehler kompromittieren regelmäßig vertrauliche Daten. Es handelt sich hierbei oft um sensitive Daten wie personenbezogene Daten, Benutzernamen und Passwörter oder Kreditkarteninformationen.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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?</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=7|year=2010|language=de}}
'''Szenario 1''': Eine Anwendung speichert verschlüsselt Kreditkartendaten in einer Datenbank, um Sie vor Angreifern zu schützen. Die Datenbank ist so eingerichtet, dass die Daten beim Auslesen automatisch entschlüsselt werden. Durch SQL-Injection können in diesem Fall alle Kreditkartendaten im Klartext ausgelesen werden. Das System hätte so konfiguriert sein sollen, dass nur nachgelagerte Anwendungen und nicht die Webanwendung selbst entschlüsseln dürfen. 
'''Szenario 2''': Ein Datensicherungsband speichert verschlüsselte Gesundheitsdaten, aber der Schlüssel ist ebenfalls dort gespeichert. Das Band geht auf dem Transportweg verloren. 
'''Szenario 3''': Die Passwortdatenbank benutzt Hashwerte ohne Salt zur Speicherung der Passwörter. Eine Schwachstelle in der Downloadfunktion ermöglicht einem Angreifer den Zugriff auf die Datei. Zu allen Hashes kann in vier Wochen ein passender Klartext gefunden werden. Bei starken Hashwerten mit Salt hätte dieser Angriff über 3000 Jahre gedauert.

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=7|year=2010|language=de}}
Eine Übersicht über alle Tücken unsicherer Kryptografie liegt weit außerhalb des Rahmens der Top 10. Für alle vertraulichen Daten sollten Sie zumindest:
# Die Bedrohungen betrachten, vor denen Sie die Daten schützen wollen (z. B. Innen- und Außentäter) und sicherstellen, dass diese Daten angemessen durch Verschlüsselung geschützt werden.
# Sicherstellen, dass ausgelagerte Datensicherungen verschlüsselt sind und die Schlüssel getrennt verwaltet und gesichert werden.
# Sicherstellen, dass angemessene, starke Algorithmen und Schlüssel verwendet und verwaltet werden.
# Sicherstellen, dass Passwörter mit einem starken Algorithmus und einem angemessenen Salt gehasht werden.
# Sicherstellen, dass alle Schlüssel und Passwörter vor unberechtigtem Zugriff geschützt sind.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=6|year=2013}}
====temporär: Auszug aus [[Top_10_2013-A6-Sensitive_Data_Exposure| Top 10-2013 RC1: A6-Sensitive_Data_Exposure]]====
Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this means it also decrypts this data automatically when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. The system should have encrypted the credit card numbers using a public key, and only allowed back-end applications to decrypt them with the private key.

Scenario #2: A site simply doesn't use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user’s session cookie. Attacker then replays this cookie and hijacks the user’s session, accessing all their private data.

Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be exposed with a rainbow table of precalculated hashes.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=6|year=2013}}
====temporär: Auszug aus [[Top_10_2013-A6-Sensitive_Data_Exposure| Top 10-2013 RC1: A6-Sensitive_Data_Exposure]]====
The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:
# Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
# Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
# Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
Ensure passwords are stored with an algorithm specifically designed for password protection, such as [http://en.wikipedia.org/wiki/Bcrypt bcrypt], [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2], or [http://en.wikipedia.org/wiki/Scrypt scrypt].
# Disable autocomplete on forms collecting sensitive data and disable caching for pages displaying sensitive data.
{{Top_10:SubsectionTableEndTemplate}}
= '''JAVA''' =

{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=7|year=2010|language=de}}
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.
<nowiki>
String plainText = "HelloWorld";

// password setzen
String password = "my128bitPassword";

// CBC Cipher immer mit einem zufällig erzeugten
// Initialization Vector (IV) initialisieren (Länge 16 Byte)
byte[] ivBytes = new byte[16];
(new SecureRandom()).nextBytes(ivBytes);

// den Schlüssel erzeugen
SecretKeySpec key = new SecretKeySpec(password.getBytes(), "AES");

// Container für die Verschlüsselungs Parameter
IvParameterSpec paramSpec = new IvParameterSpec(ivBytes);

// Chiffrierer erzeugen und initialisieren
// Algorithmus: AES
// Modus: CBC
// Padding: PKCS5Padding
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key, paramSpec);

// Verschlüsselung durchführen
byte[] encrypted = cipher.doFinal(plainText.getBytes());
</nowiki>

Die Benutzung der ESAPI erleichtert die Handhabung, da neben einer großen Bandbreite an Verschlüsselungs-, Hash-, und Signaturalgorithmen auch Methoden für die Schlüsselerzeugung und -verwaltung unterstüzt werden. Nach Initialisierung der Parameter in der Konfigurationsdatei ESAPI.properties, reduziert sich die eigentliche Verschlüsselung eines Textes beispielsweise zu:
<nowiki>
CipherText ciphertext =
ESAPI.encryptor().encrypt( new PlainText(myplaintext) );
</nowiki>

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
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.
<nowiki>
String password = "mypassword";

// salt anlegen und mit zufälligen Bytes befüllen
byte[] salt = new byte[8];
(new SecureRandom()).nextBytes(salt);

// Hash-Generator anlegen (verwendeter Algorithmus ist SHA-256)
// und mit salt initialisieren (=> höhere Sicherheit gegen Angriffe)
MessageDigest digest = MessageDigest.getInstance("SHA-256");
digest.reset();
digest.update(salt);

byte[] input = digest.digest(password.getBytes("UTF-8"));

// Hash in mehreren Iterationen (n = 100.000) berechnen
// mehr Iterationen verlangsamen Angriffe (signifikant?)
for (int i = 0; i < 100000; i++) {
digest.reset();
input = digest.digest(input);
}
// am Ende der Iterationen enthält input den berechneten Hash
</nowiki>

Sicherer ist allerdings die Nutzung einer PBKDF2 (Password-Based Key Derivation Function 2) wie im folgenden Beispiel:
<nowiki>
public byte[] generatePBKDF2Hash(String password)
throws NoSuchAlgorithmException, InvalidKeySpecException {

byte[] salt = new byte[20];
// salt mit zufälligen Bytes befüllen
(new SecureRandom()).nextBytes(salt);

int iterations = 10000;
int keyLength = 160;
// neuen Schlüssel erzeugen
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
PBEKeySpec pbeKeySpec = new PBEKeySpec(password, salt, iterations, keyLength);
SecretKey mySecretKey = factory.generateSecret(pbeKeySpec);
}

byte[] hash = generatePBKDF2Hash(password).getEncoded();
</nowiki>

Eine weiterer empfohlener Algorithmus ist bcrypt, hier bespielsweise unter Verwendung der jBCrypt-Bibliothek (siehe Referenzen).
<nowiki>
String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12));
</nowiki>
Zu bcrypt gibt es mittlerweile eine noch sicherere Variante scrypt, der Link zu einer Beispielimplementierung findet sich bei den Referenzen.

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=3|risk=7|year=2010|language=de}}
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:

<nowiki>
// Erzeugung eines symmetrischen Schlüssels mittels der vorher beschriebenen PBKDF2
String password = "mypassword";
byte[] mySecretKey = generatePBKDF2Hash(password);

// neuen KeyStore für symmetrische Schlüssel erzeugen
KeyStore ks = KeyStore.getInstance("JCEKS");
ks.load(null, null);

// Schlüssel speichern
KeyStore.ProtectionParameter passwordProtection =
new KeyStore.PasswordProtection(password);
KeyStore.SecretKeyEntry entry = new KeyStore.SecretKeyEntry(mySecretKey);
ks.setEntry("beispielkey", entry, passwordProtection);

// KeyStore in Datei speichern
FileOutputStream fos = new FileOutputStream("SecretKeyStoreDatei");
ks.store(fos,password);
fos.close();
</nowiki>

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=1|risk=6|year=2013|language=de}}
;Unzureichende Absicherung der Transportschicht

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:

<nowiki>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</nowiki>

Für Session-Cookies ist immer das Attribute SECURE zu setzen:
<nowiki>
<session-config>
<cookie-config>
<secure>
true
</secure>
</cookie-config>
</session-config>
</nowiki>
In der Server-Configuration ist sicherzustellen, dass nur TLS und SSL3 unterstützt werden.
Das Speichern von vertraulichen Inhalten am Client oder auf einem Proxy kann über den Header Cache-Control verhindert werden:

Header set Cache-Control "no-cache, no store, must-revalidate"

Weitere Hinweise im [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet Transport Layer Protection Cheat Sheet]

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=1a|risk=9|year=2010|language=de}}

Die Sicherheitskonfiguration unter Option 1 hat noch eine Schwachstelle, so das MITM (Man In The Middle attack) nicht zuverlässig verhindert wird. MITM erzeugt einen Zertifikatsfehler am Client, der üblicherweise aber (durch den Anwender) ignoriert wird. Deshalb wurde der HTTP-Header "HTTP Strict Transport Security (HSTS)" eingeführt. Damit werden kompatible Browser (Firefox, Chrome, Opera aber bisher NICHT IE) angewiesen, dass
* der Browser den http-Request ausschließlich über https verschickt (auch falls die Seite mit http aufgerufen wird).
* der Anwender Zertifikatsfehler im Browser nicht mehr ignorieren kann.

Konfiguration im Apache:
Header set Strict-Transport-Security "max-age=16070400; includeSubDomains"

Da der HSTS-Header nur über https übermittelt wird ist zusätzlich ein Redirect nötig:

<VirtualHost *:80>
ServerAlias *
RewriteEngine On
<nowiki>RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]</nowiki>
</VirtualHost>

Quellen:

[https://www.owasp.org/index.php/HTTP_Strict_Transport_Security HTTP_Strict_Transport_Security ]

[http://www.youtube.com/watch?v=zEV3HOuM_Vw&feature=youtube_gdata AppSecTutorial Series - Episode 4]

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}

Einen umfangreicheren Überblick über die Anforderungen und die hierbei zu vermeidenden Probleme gibt es unter [http://www.owasp.org/index.php/ASVS#tab=ASVS ASVS requirements on Cryptography (V7)]. Des Weiteren:
* [[Top_10_2007-Insecure_Cryptographic_Storage | OWASP Top 10-2007 on Insecure Cryptographic Storage]]
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encryptor.html ESAPI Encryptor API]
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
* [[Codereview-Cryptography | OWASP Code Review Guide: Chapter on Cryptography]]
{{Top_10_2010_Developer_Edition_De:SubSubsectionExternalReferencesTemplate|language=de}}
* [http://cwe.mitre.org/data/definitions/310.html CWE Entry 310 on Cryptographic Issues]
* [http://cwe.mitre.org/data/definitions/312.html CWE Entry 312 on Cleartext Storage of Sensitive Information]
* [http://cwe.mitre.org/data/definitions/326.html CWE Entry 326 on Weak Encryption]
* [http://www.mindrot.org/projects/jBCrypt Reine Java Implementierung von BCrypt]
* [https://github.com/wg/scrypt Beispielimplementierung von SCrypt]
{{Top_10:SubsectionTableEndTemplate}}

= '''Test''' =

{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=7|year=2010|language=de}}
{{Top_10_2010:ExampleBeginTemplate}}
tbd
Text
{{Top_10_2010:ExampleEndTemplate}}

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
{{Top_10_2010:ExampleBeginTemplate}}
tbd
Text
{{Top_10_2010:ExampleEndTemplate}}

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=|risk=7|year=2010|language=de}}
tbd
Text

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=7|year=2010|language=de}}
(ganze Breite)
Text

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
{{Top_10:SubsectionTableEndTemplate}}
<headertabs />

{{Top_10_2010_Developer_Edition_De:BottomAdvancedTemplate
|type=0
|useprev=PrevLink_Germany_Projekte
|usenext=NextLink_Germany_Projekte
|prev=Top_10_fuer_Entwickler/A6_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|6
|language=de
|year=2010}}
|next=Top_10_fuer_Entwickler/A8_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|8
|language=de
|year=2010}}
}}

[[Category:OWASP Top 10 fuer Entwickler]]

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-07-04T11:50:39Z

Michal Vossberg:

{{Top_10_2010_Developer_Edition_De:TopTemplate
|useprev=PrevLink_Germany_Projekte
|usenext=NextLink_Germany_Projekte
|prev=Top_10_fuer_Entwickler/A6_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|6
|language=de
|year=2010}}
|next=Top_10_fuer_Entwickler/A8_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|8
|language=de
|year=2010}}
}}
== Seite in Bearbeitung (BAUSTELLE!!) ==

== A7 Kryptografisch unsichere Speicherung ==

{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate|year=2010|language=de}}
{{Top_10:SummaryTableTemplate|exploitability=3|prevalence=3|detectability=2|impact=1|language=de|year=2013}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder Benutzer des Systems ist zu betrachten.
Haben diese ein Interesse, auf geschützte Daten unberechtigt zuzugreifen?
Wie steht es um Administratoren?</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer brechen üblicherweise nicht die eigentliche Kryptografie. Statt dessen finden Sie Schlüssel, Klartexte oder greifen über Kanäle mit automatischer Entschlüsselung auf Daten zu.</td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Fehlende Verschlüsselung vertraulicher Daten ist die häufigste Schwachstelle, gefolgt von unsicherer Schlüsselerzeugung, der Speicherung statischer Schlüssel und die Nutzung schwacher Algorithmen. Schwache Hashwerte ohne Salt kommen zum Passwortschutz oft vor. Ein eingeschränkter Zugriff lässt externe Angreifer solche Probleme i.d.R. nicht leicht entdecken. Den nötigen Zugriff müssen sie vorher auf andere Weise erlangen.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Fehler kompromittieren regelmäßig vertrauliche Daten. Es handelt sich hierbei oft um sensitive Daten wie personenbezogene Daten, Benutzernamen und Passwörter oder Kreditkarteninformationen.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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?</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=7|year=2010|language=de}}
'''Szenario 1''': Eine Anwendung speichert verschlüsselt Kreditkartendaten in einer Datenbank, um Sie vor Angreifern zu schützen. Die Datenbank ist so eingerichtet, dass die Daten beim Auslesen automatisch entschlüsselt werden. Durch SQL-Injection können in diesem Fall alle Kreditkartendaten im Klartext ausgelesen werden. Das System hätte so konfiguriert sein sollen, dass nur nachgelagerte Anwendungen und nicht die Webanwendung selbst entschlüsseln dürfen. 
'''Szenario 2''': Ein Datensicherungsband speichert verschlüsselte Gesundheitsdaten, aber der Schlüssel ist ebenfalls dort gespeichert. Das Band geht auf dem Transportweg verloren. 
'''Szenario 3''': Die Passwortdatenbank benutzt Hashwerte ohne Salt zur Speicherung der Passwörter. Eine Schwachstelle in der Downloadfunktion ermöglicht einem Angreifer den Zugriff auf die Datei. Zu allen Hashes kann in vier Wochen ein passender Klartext gefunden werden. Bei starken Hashwerten mit Salt hätte dieser Angriff über 3000 Jahre gedauert.

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=7|year=2010|language=de}}
Eine Übersicht über alle Tücken unsicherer Kryptografie liegt weit außerhalb des Rahmens der Top 10. Für alle vertraulichen Daten sollten Sie zumindest:
# Die Bedrohungen betrachten, vor denen Sie die Daten schützen wollen (z. B. Innen- und Außentäter) und sicherstellen, dass diese Daten angemessen durch Verschlüsselung geschützt werden.
# Sicherstellen, dass ausgelagerte Datensicherungen verschlüsselt sind und die Schlüssel getrennt verwaltet und gesichert werden.
# Sicherstellen, dass angemessene, starke Algorithmen und Schlüssel verwendet und verwaltet werden.
# Sicherstellen, dass Passwörter mit einem starken Algorithmus und einem angemessenen Salt gehasht werden.
# Sicherstellen, dass alle Schlüssel und Passwörter vor unberechtigtem Zugriff geschützt sind.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=6|year=2013}}
====temporär: Auszug aus [[Top_10_2013-A6-Sensitive_Data_Exposure| Top 10-2013 RC1: A6-Sensitive_Data_Exposure]]====
Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this means it also decrypts this data automatically when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. The system should have encrypted the credit card numbers using a public key, and only allowed back-end applications to decrypt them with the private key.

Scenario #2: A site simply doesn't use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user’s session cookie. Attacker then replays this cookie and hijacks the user’s session, accessing all their private data.

Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be exposed with a rainbow table of precalculated hashes.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=6|year=2013}}
====temporär: Auszug aus [[Top_10_2013-A6-Sensitive_Data_Exposure| Top 10-2013 RC1: A6-Sensitive_Data_Exposure]]====
The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:
# Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
# Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
# Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
Ensure passwords are stored with an algorithm specifically designed for password protection, such as [http://en.wikipedia.org/wiki/Bcrypt bcrypt], [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2], or [http://en.wikipedia.org/wiki/Scrypt scrypt].
# Disable autocomplete on forms collecting sensitive data and disable caching for pages displaying sensitive data.
{{Top_10:SubsectionTableEndTemplate}}
= '''JAVA''' =

{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=7|year=2010|language=de}}
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.
<nowiki>
String plainText = "HelloWorld";

// password setzen
String password = "my128bitPassWord";

// CBC Cipher immer mit einem zufällig erzeugten
// Initialization Vector (IV) initialisieren (Länge 16 Byte)
byte[] ivBytes = new byte[16];
(new SecureRandom()).nextBytes(ivBytes);

// den Schlüssel erzeugen
SecretKeySpec key = new SecretKeySpec(password.getBytes(), "AES");

// Container für die Verschlüsselungs Parameter
IvParameterSpec paramSpec = new IvParameterSpec(ivBytes);

// Chiffrierer erzeugen und initialisieren
// Algorithmus: AES
// Modus: CBC
// Padding: PKCS5Padding
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key, paramSpec);

// Verschlüsselung durchführen
byte[] encrypted = cipher.doFinal(plainText.getBytes());
</nowiki>

Die Benutzung der ESAPI erleichtert die Handhabung, da neben einer großen Bandbreite an Verschlüsselungs-, Hash-, und Signaturalgorithmen auch Methoden für die Schlüsselerzeugung- und verwaltung unterstüzt werden. Nach Initialisierung der Parameter in der Konfigurationsdatei ESAPI.properties, reduziert sich die eigentliche Verschlüsselung eines Textes beispielsweise zu:
<nowiki>
CipherText ciphertext =
ESAPI.encryptor().encrypt( new PlainText(myplaintext) );
</nowiki>

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
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.
<nowiki>
String password = "mypassword";

// salt anlegen und mit zufälligen Bytes befüllen
byte[] salt = new byte[8];
(new SecureRandom()).nextBytes(salt);

// Hash-Generator anlegen (verwendeter Algorithmus ist SHA-256)
// und mit salt initialisieren (=> höhere Sicherheit gegen Angriffe)
MessageDigest digest = MessageDigest.getInstance("SHA-256");
digest.reset();
digest.update(salt);

byte[] input = digest.digest(password.getBytes("UTF-8"));

// Hash in mehreren Iterationen (n = 100.000) berechnen
// mehr Iterationen verlangsamen Angriffe (signifikant?)
for (int i = 0; i < 100000; i++) {
digest.reset();
input = digest.digest(input);
}
// am Ende der Iterationen enthält input den berechneten Hash
</nowiki>

Sicherer ist allerdings die Nutzung einer PBKDF2 (Password-Based Key Derivation Function 2) wie im folgenden Beispiel:
<nowiki>
public byte[] generatePBKDF2Hash(String password)
throws NoSuchAlgorithmException, InvalidKeySpecException {

byte[] salt = new byte[20];
// salt mit zufälligen Bytes befüllen
(new SecureRandom()).nextBytes(salt);

int iterations = 10000;
int keyLength = 160;
// neuen Schlüssel erzeugen
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
PBEKeySpec pbeKeySpec = new PBEKeySpec(password, salt, iterations, keyLength);
SecretKey mySecretKey = factory.generateSecret(pbeKeySpec);
}

byte[] hash = generatePBKDF2Hash(password).getEncoded();
</nowiki>

Eine weiterer empfohlener Algorithmus ist bcrypt, hier bespielsweise unter Verwendung der jBCrypt-Bibliothek (siehe Referenzen).
<nowiki>
String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12));
</nowiki>
Zu bcrypt gibt es mittlerweile eine noch sicherere Variante scrypt, der Link zu einer Beispielimplementierung findet sich bei den Referenzen.

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=3|risk=7|year=2010|language=de}}
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 MasterKey gesichert, die Datei selbst sollte getrennt von den verschlüsselten Daten abgelegt werden:

<nowiki>
// Erzeugung eines symmetrischen Schlüssels mittels der vorher beschriebenen PBKDF2
String password = "mypassword";
byte[] mySecretKey = generatePBKDF2Hash(password);

// neuen KeyStore für symmetrische Schlüssel erzeugen
KeyStore ks = KeyStore.getInstance("JCEKS");
ks.load(null, null);

// Schlüssel speichern
KeyStore.ProtectionParameter passwordProtection =
new KeyStore.PasswordProtection(password);
KeyStore.SecretKeyEntry entry = new KeyStore.SecretKeyEntry(mySecretKey);
ks.setEntry("beispielkey", entry, passwordProtection);

// KeyStore in Datei speichern
FileOutputStream fos = new FileOutputStream("SecretKeyStoreDatei");
ks.store(fos,password);
fos.close();
</nowiki>

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=1|risk=6|year=2013|language=de}}
;Unzureichende Absicherung der Transportschicht

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:

<nowiki>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</nowiki>

Für Session-Cookies ist immer das Attribute SECURE zu setzen:
<nowiki>
<session-config>
<cookie-config>
<secure>
true
</secure>
</cookie-config>
</session-config>
</nowiki>
In der Server-Configuration ist sicherzustellen, dass nur TLS und SSL3 unterstützt werden.
Das Speichern von vertraulichen Inhalten am Client oder auf einem Proxy kann über den Header Cache-Control verhindert werden:

Header set Cache-Control "no-cache, no store, must-revalidate"

Weitere Hinweise im [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet Transport Layer Protection Cheat Sheet]

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=1a|risk=9|year=2010|language=de}}

Die Sicherheitskonfiguration unter Option 1 hat noch eine Schwachstelle, so das MITM (Man In The Middle attack) nicht zuverlässig verhindert wird. MITM erzeugt einen Zertifikatsfehler am Client, der üblicherweise aber (durch den Anwender) ignoriert wird. Deshalb wurde der HTTP-Header "HTTP Strict Transport Security (HSTS)" eingeführt. Damit werden kompatible Browser (Firefox, Chrome, Opera aber bisher NICHT IE) angewiesen, dass
* der Browser den http-Request ausschließlich über https verschickt (auch falls die Seite mit http aufgerufen wird).
* der Anwender Zertifikatsfehler im Browser nicht mehr ignorieren kann.

Konfiguration im Apache:
Header set Strict-Transport-Security "max-age=16070400; includeSubDomains"

Da der HSTS-Header nur über https übermittelt wird ist zusätzlich ein Redirect nötig:

<VirtualHost *:80>
ServerAlias *
RewriteEngine On
<nowiki>RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]</nowiki>
</VirtualHost>

Quellen:

[https://www.owasp.org/index.php/HTTP_Strict_Transport_Security HTTP_Strict_Transport_Security ]

[http://www.youtube.com/watch?v=zEV3HOuM_Vw&feature=youtube_gdata AppSecTutorial Series - Episode 4]

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}

Einen umfangreicheren Überblick über die Anforderungen und die hierbei zu vermeidenden Probleme gibt es unter [http://www.owasp.org/index.php/ASVS#tab=ASVS ASVS requirements on Cryptography (V7)]. Des Weiteren:
* [[Top_10_2007-Insecure_Cryptographic_Storage | OWASP Top 10-2007 on Insecure Cryptographic Storage]]
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encryptor.html ESAPI Encryptor API]
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
* [[Codereview-Cryptography | OWASP Code Review Guide: Chapter on Cryptography]]
{{Top_10_2010_Developer_Edition_De:SubSubsectionExternalReferencesTemplate|language=de}}
* [http://cwe.mitre.org/data/definitions/310.html CWE Entry 310 on Cryptographic Issues]
* [http://cwe.mitre.org/data/definitions/312.html CWE Entry 312 on Cleartext Storage of Sensitive Information]
* [http://cwe.mitre.org/data/definitions/326.html CWE Entry 326 on Weak Encryption]
* [http://www.mindrot.org/projects/jBCrypt Reine Java Implementierung von BCrypt]
* [https://github.com/wg/scrypt Beispielimplementierung von SCrypt]
{{Top_10:SubsectionTableEndTemplate}}

= '''Test''' =

{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=7|year=2010|language=de}}
{{Top_10_2010:ExampleBeginTemplate}}
tbd
Text
{{Top_10_2010:ExampleEndTemplate}}

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
{{Top_10_2010:ExampleBeginTemplate}}
tbd
Text
{{Top_10_2010:ExampleEndTemplate}}

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=|risk=7|year=2010|language=de}}
tbd
Text

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=7|year=2010|language=de}}
(ganze Breite)
Text

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
{{Top_10:SubsectionTableEndTemplate}}
<headertabs />

{{Top_10_2010_Developer_Edition_De:BottomAdvancedTemplate
|type=0
|useprev=PrevLink_Germany_Projekte
|usenext=NextLink_Germany_Projekte
|prev=Top_10_fuer_Entwickler/A6_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|6
|language=de
|year=2010}}
|next=Top_10_fuer_Entwickler/A8_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|8
|language=de
|year=2010}}
}}

[[Category:OWASP Top 10 fuer Entwickler]]

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-07-04T11:40:36Z

Michal Vossberg:

{{Top_10_2010_Developer_Edition_De:TopTemplate
|useprev=PrevLink_Germany_Projekte
|usenext=NextLink_Germany_Projekte
|prev=Top_10_fuer_Entwickler/A6_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|6
|language=de
|year=2010}}
|next=Top_10_fuer_Entwickler/A8_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|8
|language=de
|year=2010}}
}}
== Seite in Bearbeitung (BAUSTELLE!!) ==

== A7 Kryptografisch unsichere Speicherung ==

{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate|year=2010|language=de}}
{{Top_10:SummaryTableTemplate|exploitability=3|prevalence=3|detectability=2|impact=1|language=de|year=2013}}
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder Benutzer des Systems ist zu betrachten.
Haben diese ein Interesse, auf geschützte Daten unberechtigt zuzugreifen?
Wie steht es um Administratoren?</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer brechen üblicherweise nicht die eigentliche Kryptografie. Statt dessen finden Sie Schlüssel, Klartexte oder greifen über Kanäle mit automatischer Entschlüsselung auf Daten zu.</td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Fehlende Verschlüsselung vertraulicher Daten ist die häufigste Schwachstelle, gefolgt von unsicherer Schlüsselerzeugung, der Speicherung statischer Schlüssel und die Nutzung schwacher Algorithmen. Schwache Hashwerte ohne Salt kommen zum Passwortschutz oft vor. Ein eingeschränkter Zugriff lässt externe Angreifer solche Probleme i.d.R. nicht leicht entdecken. Den nötigen Zugriff müssen sie vorher auf andere Weise erlangen.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Fehler kompromittieren regelmäßig vertrauliche Daten. Es handelt sich hierbei oft um sensitive Daten wie personenbezogene Daten, Benutzernamen und Passwörter oder Kreditkarteninformationen.</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>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?</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=7|year=2010|language=de}}
'''Szenario 1''': Eine Anwendung speichert verschlüsselt Kreditkartendaten in einer Datenbank, um Sie vor Angreifern zu schützen. Die Datenbank ist so eingerichtet, dass die Daten beim Auslesen automatisch entschlüsselt werden. Durch SQL-Injection können in diesem Fall alle Kreditkartendaten im Klartext ausgelesen werden. Das System hätte so konfiguriert sein sollen, dass nur nachgelagerte Anwendungen und nicht die Webanwendung selbst entschlüsseln dürfen. 
'''Szenario 2''': Ein Datensicherungsband speichert verschlüsselte Gesundheitsdaten, aber der Schlüssel ist ebenfalls dort gespeichert. Das Band geht auf dem Transportweg verloren. 
'''Szenario 3''': Die Passwortdatenbank benutzt Hashwerte ohne Salt zur Speicherung der Passwörter. Eine Schwachstelle in der Downloadfunktion ermöglicht einem Angreifer den Zugriff auf die Datei. Zu allen Hashes kann in vier Wochen ein passender Klartext gefunden werden. Bei starken Hashwerten mit Salt hätte dieser Angriff über 3000 Jahre gedauert.

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=7|year=2010|language=de}}
Eine Übersicht über alle Tücken unsicherer Kryptografie liegt weit außerhalb des Rahmens der Top 10. Für alle vertraulichen Daten sollten Sie zumindest:
# Die Bedrohungen betrachten, vor denen Sie die Daten schützen wollen (z. B. Innen- und Außentäter) und sicherstellen, dass diese Daten angemessen durch Verschlüsselung geschützt werden.
# Sicherstellen, dass ausgelagerte Datensicherungen verschlüsselt sind und die Schlüssel getrennt verwaltet und gesichert werden.
# Sicherstellen, dass angemessene, starke Algorithmen und Schlüssel verwendet und verwaltet werden.
# Sicherstellen, dass Passwörter mit einem starken Algorithmus und einem angemessenen Salt gehasht werden.
# Sicherstellen, dass alle Schlüssel und Passwörter vor unberechtigtem Zugriff geschützt sind.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=6|year=2013}}
====temporär: Auszug aus [[Top_10_2013-A6-Sensitive_Data_Exposure| Top 10-2013 RC1: A6-Sensitive_Data_Exposure]]====
Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this means it also decrypts this data automatically when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. The system should have encrypted the credit card numbers using a public key, and only allowed back-end applications to decrypt them with the private key.

Scenario #2: A site simply doesn't use SSL for all authenticated pages. Attacker simply monitors network traffic (like an open wireless network), and steals the user’s session cookie. Attacker then replays this cookie and hijacks the user’s session, accessing all their private data.

Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be exposed with a rainbow table of precalculated hashes.
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=6|year=2013}}
====temporär: Auszug aus [[Top_10_2013-A6-Sensitive_Data_Exposure| Top 10-2013 RC1: A6-Sensitive_Data_Exposure]]====
The full perils of unsafe cryptography, SSL usage, and data protection are well beyond the scope of the Top 10. That said, for all sensitive data, do all of the following, at a minimum:
# Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all sensitive data at rest and in transit in a manner that defends against these threats.
# Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
# Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
Ensure passwords are stored with an algorithm specifically designed for password protection, such as [http://en.wikipedia.org/wiki/Bcrypt bcrypt], [http://en.wikipedia.org/wiki/PBKDF2 PBKDF2], or [http://en.wikipedia.org/wiki/Scrypt scrypt].
# Disable autocomplete on forms collecting sensitive data and disable caching for pages displaying sensitive data.
{{Top_10:SubsectionTableEndTemplate}}
= '''JAVA''' =

{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=7|year=2010|language=de}}
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.
<nowiki>
// master key und
String masterKey = "My128bitMastrKey";
String plainText = "HelloWorld";

// CBC Cipher immer mit einem zufällig erzeugten
// Initialization Vector (IV) initialisieren (Länge 16 Byte)
byte[] ivBytes = new byte[16];
(new SecureRandom()).nextBytes(ivBytes);

// den Schlüssel erzeugen
SecretKeySpec key = new SecretKeySpec(masterKey.getBytes(), "AES");

// Container für die Verschlüsselungs Parameter
IvParameterSpec paramSpec = new IvParameterSpec(ivBytes);

// Chiffrierer erzeugen und initialisieren
// Algorithmus: AES
// Modus: CBC
// Padding: PKCS5Padding
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key, paramSpec);

// Verschlüsselung durchführen
byte[] encrypted = cipher.doFinal(plainText.getBytes());
</nowiki>

Die Benutzung der ESAPI erleichtert die Handhabung, da neben einer großen Bandbreite an Verschlüsselungs-, Hash-, und Signaturalgorithmen auch Methoden für die Schlüsselerzeugung- und verwaltung unterstüzt werden. Nach Initialisierung der Parameter in der Konfigurationsdatei ESAPI.properties, reduziert sich die eigentliche Verschlüsselung eines Textes beispielsweise zu:
<nowiki>
CipherText ciphertext =
ESAPI.encryptor().encrypt( new PlainText(myplaintext) );
</nowiki>

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
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.
<nowiki>
String password = "mypassword";

// salt anlegen und mit zufälligen Bytes befüllen
byte[] salt = new byte[8];
(new SecureRandom()).nextBytes(salt);

// Hash-Generator anlegen (verwendeter Algorithmus ist SHA-256)
// und mit salt initialisieren (=> höhere Sicherheit gegen Angriffe)
MessageDigest digest = MessageDigest.getInstance("SHA-256");
digest.reset();
digest.update(salt);

byte[] input = digest.digest(password.getBytes("UTF-8"));

// Hash in mehreren Iterationen (n = 100.000) berechnen
// mehr Iterationen verlangsamen Angriffe (signifikant?)
for (int i = 0; i < 100000; i++) {
digest.reset();
input = digest.digest(input);
}
// am Ende der Iterationen enthält input den berechneten Hash
</nowiki>

Sicherer ist allerdings die Nutzung einer PBKDF2 (Password-Based Key Derivation Function 2) wie im folgenden Beispiel:
<nowiki>
public byte[] generatePBKDF2Hash(String password)
throws NoSuchAlgorithmException, InvalidKeySpecException {

byte[] salt = new byte[20];
// salt mit zufälligen Bytes befüllen
(new SecureRandom()).nextBytes(salt);

int iterations = 10000;
int keyLength = 160;
// neuen Schlüssel erzeugen
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
PBEKeySpec pbeKeySpec = new PBEKeySpec(password, salt, iterations, keyLength);
SecretKey mySecretKey = factory.generateSecret(pbeKeySpec);
}

byte[] hash = generatePBKDF2Hash(password).getEncoded();
</nowiki>

Eine weiterer empfohlener Algorithmus ist bcrypt, hier bespielsweise unter Verwendung der jBCrypt-Bibliothek (siehe Referenzen).
<nowiki>
String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12));
</nowiki>
Zu bcrypt gibt es mittlerweile eine noch sicherere Variante scrypt, der Link zu einer Referenzimplementierung findet sich bei den Referenzen.

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
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 MasterKey gesichert, die Datei selbst sollte getrennt von den verschlüsselten Daten abgelegt werden:

<nowiki>
// Erzeugung eines symmetrischen Schlüssels mittels der vorher beschriebenen PBKDF2
String password = "mypassword";
byte[] mySecretKey = generatePBKDF2Hash(password);

// neuen KeyStore für symmetrische Schlüssel erzeugen
KeyStore ks = KeyStore.getInstance("JCEKS");
ks.load(null, null);

// Schlüssel speichern
KeyStore.ProtectionParameter passwordProtection =
new KeyStore.PasswordProtection(password);
KeyStore.SecretKeyEntry entry = new KeyStore.SecretKeyEntry(mySecretKey);
ks.setEntry("beispielkey", entry, passwordProtection);

// KeyStore in Datei speichern
FileOutputStream fos = new FileOutputStream("SecretKeyStoreDatei");
ks.store(fos,password);
fos.close();
</nowiki>

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=1|risk=6|year=2013|language=de}}
;Unzureichende Absicherung der Transportschicht

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:

<nowiki>
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</nowiki>

Für Session-Cookies ist immer das Attribute SECURE zu setzen:
<nowiki>
<session-config>
<cookie-config>
<secure>
true
</secure>
</cookie-config>
</session-config>
</nowiki>
In der Server-Configuration ist sicherzustellen, dass nur TLS und SSL3 unterstützt werden.
Das Speichern von vertraulichen Inhalten am Client oder auf einem Proxy kann über den Header Cache-Control verhindert werden:

Header set Cache-Control "no-cache, no store, must-revalidate"

Weitere Hinweise im [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet Transport Layer Protection Cheat Sheet]

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=left|title=1a|risk=9|year=2010|language=de}}

Die Sicherheitskonfiguration unter Option 1 hat noch eine Schwachstelle, so das MITM (Man In The Middle attack) nicht zuverlässig verhindert wird. MITM erzeugt einen Zertifikatsfehler am Client, der üblicherweise aber (durch den Anwender) ignoriert wird. Deshalb wurde der HTTP-Header "HTTP Strict Transport Security (HSTS)" eingeführt. Damit werden kompatible Browser (Firefox, Chrome, Opera aber bisher NICHT IE) angewiesen, dass
* der Browser den http-Request ausschließlich über https verschickt (auch falls die Seite mit http aufgerufen wird).
* der Anwender Zertifikatsfehler im Browser nicht mehr ignorieren kann.

Konfiguration im Apache:
Header set Strict-Transport-Security "max-age=16070400; includeSubDomains"

Da der HSTS-Header nur über https übermittelt wird ist zusätzlich ein Redirect nötig:

<VirtualHost *:80>
ServerAlias *
RewriteEngine On
<nowiki>RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]</nowiki>
</VirtualHost>

Quellen:

[https://www.owasp.org/index.php/HTTP_Strict_Transport_Security HTTP_Strict_Transport_Security ]

[http://www.youtube.com/watch?v=zEV3HOuM_Vw&feature=youtube_gdata AppSecTutorial Series - Episode 4]

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}

Einen umfangreicheren Überblick über die Anforderungen und die hierbei zu vermeidenden Probleme gibt es unter [http://www.owasp.org/index.php/ASVS#tab=ASVS ASVS requirements on Cryptography (V7)]. Des Weiteren:
* [[Top_10_2007-Insecure_Cryptographic_Storage | OWASP Top 10-2007 on Insecure Cryptographic Storage]]
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/Encryptor.html ESAPI Encryptor API]
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
* [[Codereview-Cryptography | OWASP Code Review Guide: Chapter on Cryptography]]
{{Top_10_2010_Developer_Edition_De:SubSubsectionExternalReferencesTemplate|language=de}}
* [http://cwe.mitre.org/data/definitions/310.html CWE Entry 310 on Cryptographic Issues]
* [http://cwe.mitre.org/data/definitions/312.html CWE Entry 312 on Cleartext Storage of Sensitive Information]
* [http://cwe.mitre.org/data/definitions/326.html CWE Entry 326 on Weak Encryption]
{{Top_10:SubsectionTableEndTemplate}}

= '''Test''' =

{{Top_10:SubsectionTableBeginTemplate|type=headertab}} {{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=firstLeft|title=1|risk=7|year=2010|language=de}}
{{Top_10_2010:ExampleBeginTemplate}}
tbd
Text
{{Top_10_2010:ExampleEndTemplate}}

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
{{Top_10_2010:ExampleBeginTemplate}}
tbd
Text
{{Top_10_2010:ExampleEndTemplate}}

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=|risk=7|year=2010|language=de}}
tbd
Text

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=7|year=2010|language=de}}
(ganze Breite)
Text

{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
{{Top_10:SubsectionTableEndTemplate}}
<headertabs />

{{Top_10_2010_Developer_Edition_De:BottomAdvancedTemplate
|type=0
|useprev=PrevLink_Germany_Projekte
|usenext=NextLink_Germany_Projekte
|prev=Top_10_fuer_Entwickler/A6_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|6
|language=de
|year=2010}}
|next=Top_10_fuer_Entwickler/A8_{{Top_10_2010_Developer_Edition_De:ByTheNumbers
|8
|language=de
|year=2010}}
}}

[[Category:OWASP Top 10 fuer Entwickler]]

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-04-22T11:02:41Z

Michal Vossberg:

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-04-22T11:01:12Z

Michal Vossberg:

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-04-18T12:34:49Z

Michal Vossberg:

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-04-09T09:33:28Z

Michal Vossberg:

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-04-09T09:14:45Z

Michal Vossberg:

Category:OWASP Top 10 fuer Entwickler

2013-04-08T14:29:29Z

Michal Vossberg:

{{Top_10_2010_Developer_Edition_De:TopTemplate|useprev=Nothing|usenext=NextLink_Germany_Projekte|next=Top_10_fuer_Entwickler/Risiken|prev=}}
==Projekt-Seite 'Top 10 fuer Entwickler'==
{| width="100%" style="background-color:inherit;"
| width="70%" style="vertical-align:top; padding-right:0.5em;" |
== Ziele des Projekts: ==
Beim German OWASP Day 2012 entstand die Idee eine Version der OWASP Top 10 für Entwickler zu erstellen.
Inhaltlich sollen die Top 10 für Entwickler 'schmackhaft' gemacht werden, d.h. es soll eine '''Brücke''' von den '''OWASP Top 10''' zu den ''' 'Good Practices' (Cheat Sheets)''' bilden.

'''Geplanter Inhalt:'''
# Problem verstehen (aus [https://www.owasp.org/images/b/b8/OWASPTop10_DE_Version_1_0.pdf OWASP Top 10 2010 - German PDF], 'Master' für das Dokument, gleiches Aussehen wie das englische [[Top_10_2010]]-Wiki (gepl: [[Top_10_2013]])), ggf. etwas mehr Platz für Erklärungen als in der Original-Version
# wie programmiere ich richtig (mit Quelltext-Beispiel(en) (zunächst Java, weitere Sprachen sind vorbereitet))
# wo finde ich mehr Infos => [[Cheat Sheets]], [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Download/Vorabversionen/Baustein_Webanwendungen.pdf BSI: IT-Grundschutz Baustein Webanwendungen'] etc.

Inhaltlich nicht neu, jedoch für Anwendungsentwickler neu zusammengestellt. Damit die Hürde für den 1. Einstieg geringer ist, wird das Dokument in Deutsch erstellt.
Das Dokument soll für Schulungen und als Nachschlagewerk geeignet sein.

'''Wer Lust & Zeit hat mitzumachen (Autor, Wiki-Designer, Software-Entwickler, Reviewpartner etc) bitte Info an [[User:T.Gigler|T.Gigler]].'''
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |
== Top 10 Developer Edition in German ==
The objectives of the '''project''' is to add ''' ''Good Practices'' (like the Cheat Sheets)''' to the '''OWASP Top 10'''. Its aim is to bridge the gap between awareness, theoretical knowledge to effective know-how to build good programs. It is written in German to make it easier for German developers to use it. 
 
'''IMPORTANT NOTICE: We started to compile this wiki. It is in early alpha state!''' 
All templates will we developed as 'multilingual' templates. So it should be easy to use them for other languages (for Top-10 Wikis in other languages than English or other Developer Editions of the Top-10).

If you like to join us or if you have questions, please do not hesitate to contact [[User:T.Gigler|T.Gigler]].
|}
----
  
==Actual Work in Progress==
Hier eine Auflistung der einzelnen Kapitel / Teile / Review-TODOs - wer einen Teil übernehmen möchte schreibt sich bitte einfach ein (im Feld Ersteller(in)). Alle Rollen können gerne mit zwei oder mehr Personen besetzt werden.

Im Kommentarfeld bitte angeben, bis wann ihr plant, den Punkt fertig bearbeitet zu haben (und natürlich sonstige notwendigen Kommentare). Das Kommentarfeld eignet sich auch, um anzugeben, wer den peer review für diesen Teil macht (vgl. Status "in Diskussion").

Unter Status könnt Ihr das Folgende angeben:
* offen (dieser Teil ist noch unbearbeitet)
* in Arbeit (dieser Teil wird aktuell bearbeitet: Sichten der 'Good Practices', ggf. Diskussion mit dessen Erstellern, Erstellen der Wiki-Seite)
* im Review (Arbeit des initialen Reviewers abgeschlossen; Kommentierung / peer review durch andere wird durchgeführt)
* geschlossen (die Kommentierung dieses Teils ist abgeschlossen)
* übernommen (Die Review-Anmerkungen wurden in das Wiki übernommen)

{| class="wikitable" cellspacing="1" cellpadding="1" border="1" width="100%;"
|-
! style="min-width: 20%" |Kapitel / Teil / Task
! style="min-width: 10%" |Ersteller(in) Wiki-Seite inkl JAVA
! style="min-width: 10%" |1. Review-Partner(in)
! style="min-width: 7%" |Status
! Kommentar (Fragen, Besonderheiten, Hilfe benötigt, Termine etc)
! style="min-width: 10%" |Ersteller(in) für weitere Programmiersprachen
|-
|colspan="6"| '''Administratives/Allgemeines'''
|-
|  Basis-Wiki inkl. Templates erstellen
|  Torsten
|  Achim
|  in Arbeit
|  Basis: derzeit: Top 10 - 2010, Internationalisierung des englischen Wikis (inkl. Templates), geplant: Schwenk auf Top 10 - 2013, wenn die deutsche Übersetzung vorhanden ist.
|  <center>---</center>
|-
|colspan="6"| '''Dokument'''
|-
!  style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A1 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|1|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|1|language=de|year=2010}}]]</center>

|  Torsten, Ralf
|  <offen>
|  in Arbeit
|  Referenz-Eintrag zur Diskussion
| 
|-
!style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A2 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|2|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|2|language=de|year=2010}}]]</center>

|  Thomas, Ralf
|  <offen>
|  in Arbeit
| 
| 
|-
!  style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A3 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|3|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|3|language=de|year=2010}}]]</center>


|  Thomas
|  <offen>
|  in Arbeit
| 
| 
|-
!  style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A4 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|4|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|4|language=de|year=2010}}]]</center>

|  Thomas
|  <offen>
|  offen
| 
| 
|-
!  style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A5 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|5|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|5|language=de|year=2010}}]]</center>

|  Torsten, Ralf
|  <offen>
|  in Arbeit
| 
| 
|-
! style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A6 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|6|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|6|language=de|year=2010}}]]</center>

| 
|  <offen>
|  offen
| 
| 
|-
!  style="background:#E0E0E0"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A7 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|7|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|7|language=de|year=2010}}]]</center>

|  Michal V.
|  <offen>
|  offen
| 
| 
|-
!  <center>[[Germany/Projekte/Top 10 fuer Entwickler/A8 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|8|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|8|language=de|year=2010}}]]</center>
| 
|  <offen>
|  offen
|  Tbd (Prio 3)
| 
|-
| <center>[[Germany/Projekte/Top 10 fuer Entwickler/A9 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|9|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|9|language=de|year=2010}}]]</center>
| 
|  <offen>
|  offen
|  Tbd (Prio 3)
| 
|-
!  style="background:#CAE1FF"|<center>[[Germany/Projekte/Top 10 fuer Entwickler/A10 {{Top_10_2010_Developer_Edition_De:ByTheNumbers|10|language=de|year=2010}}|{{Top_10_2010_Developer_Edition_De:ByTheNumbers|10|language=de|year=2010}}]]</center>

| 
|  <offen>
|  offen
| 
| 
|}

'''Anmerkung:''' Risiken, die sich in der im Review befindlichen Version der [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20RC1.pdf OWASP Top 10 - 2013 RC1] nicht ändern, sind '''blau''' und Änderungen sind '''grau''' unterlegt.

Weitere Informationen und die aktuellen Arbeitsstände gibt es unter [[Category Talk:OWASP Top 10 fuer Entwickler| "Discussion"]].

=Project About=
{{:Projects/OWASP_Top_10_Fuer_Entwickler_Project}}

----
'''[[Germany/Projekte/Top_10_fuer_Entwickler/Risiken|hier gehts los / please start here ==>]]'''
----

{{Top_10_2010_Developer_Edition_De:BottomTemplate|type={{Top_10_2010:StyleTemplate}}|usenext=NextLink_Germany_Projekte|next=Top_10_fuer_Entwickler/Risiken|useprev=Nothing||prev=}}

[[Category:Germany]] [[Category:OWASP Project]] [[Category:OWASP Top Ten Project]]

Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten

2013-04-08T14:26:03Z

Michal Vossberg:

User:Michal Vossberg

2013-04-05T13:04:40Z

Michal Vossberg:

Principal Security Architect :: here.com :: NOKIA

User:Michal Vossberg

2013-04-05T13:01:57Z

Michal Vossberg:

<nowiki>
Principal Security Architect
here.com
NOKIA
</nowiki>