Difference between revisions of "Germany/Projekte/Top 10 fuer Entwickler-2013/A6-Verlust der Vertraulichkeit sensibler Daten"

From OWASP
Jump to: navigation, search
m
m (kleinere Textänderungen (ohne inhaltliche Änderung))
(29 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Top_10_2010_Developer_Edition_De:TopTemplate|useprev=PrevLink_Germany_Projekte|usenext=NextLink_Germany_Projekte|next=Top_10_fuer_Entwickler/A8_Mangelhafter_URL-Zugriffsschutz|prev=Top_10_fuer_Entwickler/A6 Sicherheitsrelevante Fehlkonfiguration}}
+
{{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!!) ==
 
== Seite in Bearbeitung (BAUSTELLE!!) ==
  
 
== A7 Kryptografisch unsichere Speicherung ==  
 
== A7 Kryptografisch unsichere Speicherung ==  
  
{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate}}
+
{{Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate|year=2010|language=de}}
 
{{Top_10_2010:SummaryTableValue-3-Template|Ausnutzbarkeit|SCHWIERIG}}
 
{{Top_10_2010:SummaryTableValue-3-Template|Ausnutzbarkeit|SCHWIERIG}}
 
{{Top_10_2010:SummaryTableValue-3-Template|Verbreitung|SELTEN}}
 
{{Top_10_2010:SummaryTableValue-3-Template|Verbreitung|SELTEN}}
Line 14: Line 25:
 
Wie steht es um Administratoren?</td>
 
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 {{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 ein-geschränkter Zugriff lässt externe Angreifer solche Probleme i.d.R. nicht leicht ent-decken. Den nötigen Zugriff müssen sie vorher auf andere Weise erlangen.</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}}>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>
 
     <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_2010:SummaryTableEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=1|risk=7}}   
+
{{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}}   
 
'''<u>Szenario 1</u>''': 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.<br/>  
 
'''<u>Szenario 1</u>''': 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.<br/>  
 
'''<u>Szenario 2</u>''': Ein Datensicherungsband speichert verschlüsselte Gesundheitsdaten, aber der Schlüssel ist ebenfalls dort gespeichert. Das Band geht auf dem Transportweg verloren.<br/>
 
'''<u>Szenario 2</u>''': Ein Datensicherungsband speichert verschlüsselte Gesundheitsdaten, aber der Schlüssel ist ebenfalls dort gespeichert. Das Band geht auf dem Transportweg verloren.<br/>
 
'''<u>Szenario 3</u>''': 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.
 
'''<u>Szenario 3</u>''': 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}}|number=2|risk=7}}  
+
{{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 vertrau-lichen Daten sollten Sie zumindest:
+
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.
 
# 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 ausgelagerte Datensicherungen verschlüsselt sind und die Schlüssel getrennt verwaltet und gesichert werden.
Line 32: Line 42:
 
# Sicherstellen, dass Passwörter mit einem starken Algorithmus und einem angemessenen Salt gehasht 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.
 
# Sicherstellen, dass alle Schlüssel und Passwörter vor unberechtigtem Zugriff geschützt sind.
</td> </tr>
+
{{Top_10:SubsectionTableEndTemplate}}
</table>
+
  
 
= '''JAVA''' =   
 
= '''JAVA''' =   
 
<!-- z.Z ohne Template --->
 
<!-- z.Z ohne Template --->
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=11|risk=1}} <!-- war number=3 -->
+
{{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}}
==== Tbd ====
+
Beispiel für das sichere Hashen von Passwörtern. Um die Sicherheit zu erhöhen sollte jedes Passwort mit einem Zufallswert (Salt) berechnet und möglichst viele Iterationen beim Hashing genutzt werden.
 +
<span style="color: red;">'''Geheime Schlüssel sollten natürlich nicht wie im Beispiel im Quellcode stehen.'''</span>
 +
  <nowiki>
 +
String password = "Password";
  
{{Top_10_2010:ExampleBeginTemplate}}
+
// salt anlegen und mit zufälligen Bytes befüllen
 +
byte[] salt = new byte[8];
 +
(new SecureRandom()).nextBytes(salt);
  
{{Top_10_2010:ExampleEndTemplate}}
+
// 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);
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=1}}
+
byte[] input = digest.digest(password.getBytes("UTF-8"));
==== Tbd ====
+
{{Top_10_2010:ExampleBeginTemplate}}
+
  
{{Top_10_2010:ExampleEndTemplate}}
+
// 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>
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=5|risk=1}}
+
Und dies ist 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ß. Bei der Wahl der Parameter kommt es dabei immer auf die jeweiligen Daten und die Anwendung an.
==== Tbd ====
+
<span style="color: red;">'''Geheime Schlüssel sollten natürlich nicht wie im Beispiel im Quellcode stehen.'''</span>
 +
  <nowiki>
 +
// 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);
  
{{Top_10_2010:ExampleBeginTemplate}}
+
// den Schlüssel erzeugen
 +
SecretKeySpec key = new SecretKeySpec("My128bitMastrKey".getBytes(), "AES");
  
{{Top_10_2010:ExampleEndTemplate}}
+
// 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>
 +
 
 +
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=right|title=2|risk=7|year=2010|language=de}}
 +
Geheime Schlüssel sollten natürlich nicht wie im nebenstehenden Beispiel im Quellcode stehen. Um 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>
 +
char[] password = getMasterKey();
 +
byte[] salt = new byte[20];
 +
// salt mit zufälligen Bytes befüllen
 +
(new SecureRandom()).nextBytes(salt);
 +
 
 +
// neuen Schlüssel erzeugen
 +
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
 +
PBEKeySpec pbeKeySpec = new PBEKeySpec(password, salt, 1000, 128);
 +
SecretKey mySecretKey = factory.generateSecret(pbeKeySpec);
 +
 
 +
// 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=left|title=3|risk=7|year=2010|language=de}}
 +
Grundsätzlich gibt es bei der Verschlüsselung immer viele Wahlmöglichkeiten. Die Benutzung der ESAPI erleichtert die Handhabung ungemein, da neben einer großen Bandbreite an Verschlüsselungs-, Hash-, und Signaturalgorithmen auch Methoden für die Schlüsselerzeugung- und verwaltung unterstüzt werden. Die Verschlüsselung eines Textes beispielsweise reduziert sich dann 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=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>
 +
  <!-- auth-constraint an dieser Stelle für Authentisierung  -->
 +
  <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}}|number=8|risk=1}}
+
{{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}}
 
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
  
Line 65: Line 204:
 
* [http://www.owasp.org/index.php/Guide_to_Cryptography#Insecure_transmission_of_secrets OWASP Development Guide: Chapter on Cryptography]
 
* [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]]
 
* [[Codereview-Cryptography | OWASP Code Review Guide: Chapter on Cryptography]]
{{Top_10_2010:SubSubsectionExternalReferencesTemplate}}
+
{{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/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/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://cwe.mitre.org/data/definitions/326.html CWE Entry 326 on Weak Encryption]
{{Top_10_2010:BottomAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|useprev=2010PrevLink|usenext=2010NextLink|prev=A6-Security Misconfiguration|next=A8-Failure to Restrict URL Access}}
+
{{Top_10:SubsectionTableEndTemplate}}
</td></tr></table>
+
  
 
= '''Test''' =
 
= '''Test''' =
 
<!-- weitere Programmiersprachen oder evtl Anti-Beispiele --->
 
<!-- weitere Programmiersprachen oder evtl Anti-Beispiele --->
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=11|risk=7}}
+
{{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}}
 
{{Top_10_2010:ExampleBeginTemplate}}
 
tbd
 
tbd
Line 80: Line 218:
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=4|risk=7}}
+
{{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}}
 
{{Top_10_2010:ExampleBeginTemplate}}
 
tbd
 
tbd
Line 86: Line 224:
 
{{Top_10_2010:ExampleEndTemplate}}
 
{{Top_10_2010:ExampleEndTemplate}}
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=6|risk=7}}
+
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=defOp|position=whole|title=|risk=7|year=2010|language=de}}
 
tbd
 
tbd
 
Text
 
Text
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=7|risk=7}}
+
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=userImpact|position=left|risk=7|year=2010|language=de}}
 
(ganze Breite)
 
(ganze Breite)
 
Text
 
Text
  
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=9|risk=7}}
+
{{Top_10_2010_Developer_Edition_De:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2010|language=de}}
</td></tr></table>
+
{{Top_10:SubsectionTableEndTemplate}}
 
+
 
<headertabs />
 
<headertabs />
  
{{Top_10_2010_Developer_Edition_De:BottomAdvancedTemplate|type=0|usenext=NextLink_Germany_Projekte|next=Top_10_fuer_Entwickler/A8_Mangelhafter_URL-Zugriffsschutz|useprev=PrevLink_Germany_Projekte|prev=Top_10_fuer_Entwickler/A6 Sicherheitsrelevante Fehlkonfiguration}}
+
{{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]]
 
[[Category:OWASP Top 10 fuer Entwickler]]

Revision as of 14:06, 2 May 2013

← Top_10_fuer_Entwickler/A6_Sicherheitsrelevante Fehlkonfiguration
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top_10_fuer_Entwickler/A8_Mangelhafter URL-Zugriffsschutz →

Seite in Bearbeitung (BAUSTELLE!!)

A7 Kryptografisch unsichere Speicherung

Bedrohungsquelle
Angriffsvektor
Schwachstellen
Technische Auswirkung
Auswirkung auf das Unternehmen
______ Ausnutzbarkeit
SCHWIERIG
Verbreitung
SELTEN
Auffindbarkeit
SCHWIERIG
Auswirkung
SCHWERWIEGEND
Application / Business Specific
Jeder Benutzer des Systems ist zu betrachten.

Haben diese ein Interesse, auf geschützte Daten unberechtigt zuzugreifen?

Wie steht es um Administratoren?
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. 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. 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 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.

Wie kann ich 'Kryptografisch unsichere Speicherung' verhindern?

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:

  1. 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.
  2. Sicherstellen, dass ausgelagerte Datensicherungen verschlüsselt sind und die Schlüssel getrennt verwaltet und gesichert werden.
  3. Sicherstellen, dass angemessene, starke Algorithmen und Schlüssel verwendet und verwaltet werden.
  4. Sicherstellen, dass Passwörter mit einem starken Algorithmus und einem angemessenen Salt gehasht werden.
  5. Sicherstellen, dass alle Schlüssel und Passwörter vor unberechtigtem Zugriff geschützt sind.
[edit]

Verteidigungs-Option 1 gegen 'Kryptografisch unsichere Speicherung':

Beispiel für das sichere Hashen von Passwörtern. Um die Sicherheit zu erhöhen sollte jedes Passwort mit einem Zufallswert (Salt) berechnet und möglichst viele Iterationen beim Hashing genutzt werden. Geheime Schlüssel sollten natürlich nicht wie im Beispiel im Quellcode stehen.

 
String password = "Password";

// 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

Und dies ist 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ß. Bei der Wahl der Parameter kommt es dabei immer auf die jeweiligen Daten und die Anwendung an. Geheime Schlüssel sollten natürlich nicht wie im Beispiel im Quellcode stehen.

 
// 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("My128bitMastrKey".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());
  
Verteidigungs-Option 2 gegen 'Kryptografisch unsichere Speicherung':

Geheime Schlüssel sollten natürlich nicht wie im nebenstehenden Beispiel im Quellcode stehen. Um 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:

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

// neuen Schlüssel erzeugen 
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
PBEKeySpec pbeKeySpec = new PBEKeySpec(password, salt, 1000, 128);
SecretKey mySecretKey = factory.generateSecret(pbeKeySpec);

// 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();
  


Verteidigungs-Option 3 gegen 'Kryptografisch unsichere Speicherung':

Grundsätzlich gibt es bei der Verschlüsselung immer viele Wahlmöglichkeiten. Die Benutzung der ESAPI erleichtert die Handhabung ungemein, da neben einer großen Bandbreite an Verschlüsselungs-, Hash-, und Signaturalgorithmen auch Methoden für die Schlüsselerzeugung- und verwaltung unterstüzt werden. Die Verschlüsselung eines Textes beispielsweise reduziert sich dann zu:

 
CipherText ciphertext = 
   ESAPI.encryptor().encrypt( new PlainText(myplaintext) );
  
Verteidigungs-Option 1 gegen 'Verlust der Vertraulichkeit sensibler Daten':
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:

 
<security-constraint>
   <web-resource-collection>
     <web-resource-name>Protected Context</web-resource-name>
     <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <!-- auth-constraint an dieser Stelle für Authentisierung  -->
   <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>
  

Für Session-Cookies ist immer das Attribute SECURE zu setzen:

 
<session-config> 
   <cookie-config> 
      <secure>
         true
      </secure> 
   </cookie-config> 
</session-config> 
  

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 Transport Layer Protection Cheat Sheet

Verteidigungs-Option 1a gegen 'Unzureichende Absicherung der Transportschicht':

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
      RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301]
  </VirtualHost>

Quellen:

HTTP_Strict_Transport_Security

AppSecTutorial Series - Episode 4

Referenzen

OWASP

Einen umfangreicheren Überblick über die Anforderungen und die hierbei zu vermeidenden Probleme gibt es unter ASVS requirements on Cryptography (V7). Des Weiteren:

Andere

Verteidigungs-Option 1 gegen 'Kryptografisch unsichere Speicherung':

tbd Text

Verteidigungs-Option 2 gegen 'Kryptografisch unsichere Speicherung':

tbd Text

Verteidigungs-Option gegen 'Kryptografisch unsichere Speicherung':

tbd Text

Auswirkung(en) auf den Benutzer

(ganze Breite) Text

Referenzen


← Top_10_fuer_Entwickler/A6_Sicherheitsrelevante Fehlkonfiguration
Top 10 fuer Entwickler-2013: Inhaltsverzeichnis

Die Top-10-Risiken

Top_10_fuer_Entwickler/A8_Mangelhafter URL-Zugriffsschutz →

© 2002-2013 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png