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

A6 Verlust der Vertraulichkeit sensibler Daten (Fehlerhafte Autorisierung auf Anwendungsebene / Nutzung von Komponenten mit bekannten Schwachstellen)


Anwendungs- spezifisch	Ausnutzbarkeit SCHWIERIG	Verbreitung SELTEN	Auffindbarkeit DURCHSCHNITTLICH	Auswirkung SCHWERWIEGEND	Application / Business Specific
Jeder mit Zugriff auf Ihre vertraulichen Daten (Backups inkl.) ist zu betrachten. Das betrifft die Speicherung, die Übertragung und auch die Daten im Browser der Kunden. Externe und interne Bedrohungen sind relevant.	Angreifer brechen i.d.R. nicht die Verschlüsselung selbst. Stattdessen stehlen sie Schlüssel, führen Seiten- oder MITM-Angriffe aus oder stehlen Klartext vom Server, während der Übertragung oder aus dem Browser des Kunden heraus.	Fehlende Verschlüsselung vertraulicher Daten ist die häufigste Schwachstelle. Die Nutzung von Kryptographie erfolgt oft mit schwacher Schlüsselerzeugung und -verwaltung und der Nutzung schwacher Algorithmen, insbesondere für das Password Hashing. Browser Schwachstellen sind verbreitet und leicht zu finden, aber nur schwer auszunutzen. Ein eingeschränkter Zugriff lässt ext. Angreifer Probleme auf dem Server i.d.R. nur schwer finden und ausnutzen.		Fehler kompromittieren regelmäßig vertrauliche Daten. Es handelt sich hierbei oft um sensitive Daten wie personenbezogene Daten, Benutzernamen und Passwörter oder Kreditkarteninformationen.	Betrachten Sie den Wert verlorener Daten und die Auswirkungen auf die Reputation des betroffenen Unternehmens. Hat es ggf. auch juristische Konsequenzen, wenn die Daten bekannt werden?

Mögliche Angriffsszenarien

Szenario 1: Eine Anwendung verschlüsselt Kreditkartendaten automatisch bei der Speicherung in einer Datenbank. Das bedeutet aber auch durch SQL-Injection erlangte Kreditkartendaten in diesem Fall automatisch entschlüsselt werden. Die Anwendung hätte die Daten mit eine Public Key verschlüsseln sollen und nur nachgelagerte Anwendungen und nicht die Webanwendung selbst hätten die Daten mit dem Private Key entschlüsseln dürfen.
Szenario 2: Eine Webseite schützt die authentisierten Seiten nicht mit SSL. Der Angreifer stiehlt das Sitzungscookie des Nutzers durch einfaches Mitlesen der Kommunikation (z.B. in einem offenen WLAN). Durch Wiedereinspielen dieses Cookies übernimmt der Angreifer die Sitzung des Nutzers und erlangt Zugriff auf die privaten Daten des Nutzers.
Szenario 3: Die Passwortdatenbank benutzt Hashwerte ohne Salt zur Speicherung der Passwörter. Eine Schwachstelle in der Downloadfunktion erlaubt dem Angreifer den Zugriff auf die Datei. Zu allen Hashes kann über eine Rainbowtabelle mit vorausberechneten Hashes der Klartext gefunden werden.

Wie kann ich 'Verlust der Vertraulichkeit sensibler Daten' verhindern?

Eine Übersicht über alle Tücken unsicherer Kryptografie, SSL-Verwendung und Datensicherheit liegt weit außerhalb der Top 10. Für alle vertraulichen Daten sollten Sie zumindest:

Klärung der Bedrohungen, vor denen die Daten zu schützen sind (z. B. Innen- und Außentäter) und sicherstellen, dass vertrauliche Daten bei der Übertragung/Speicherung geeignet durch Verschlüsselung geschützt werden.
Kein unnötiges Speichern vertraulicher Daten. Löschung nicht mehr benötigter Daten. Daten, die es nicht gibt, können auch nicht gestohlen werden.
Sicherstellen, dass starke Algorithmen und Schlüssel (z.B. gemäß FIPS-140, BSI TR-02102-2) verwendet werden.
Sicherstellen, dass Passwörter mit einem speziell für Passwortschutz entwickelten Algorithmus gespeichert werden (bcrypt, PBKDF2 oder scrypt).
Deaktivieren der Autovervollständigung und des Cachings in Formularen mit vertraulichen Informationen.

JAVA
JAVA2
PHP
Test

JAVA-Teil 1: Kryptografisch unsichere Speicherung

Verteidigungs-Option 1 gegen 'Verlust der Vertraulichkeit sensibler Daten':

Ein einfaches Beispiel für die Veschlüsselung von Texten, hier mit dem AES-128 Algorithmus. Die Auswahl an Verschlüsselungsparametern wie beispielsweise Algorithmus, Ciphermodus oder Schlüssellänge ist groß und kommt immer auf die jeweiligen Daten und die Anwendung an.

String plainText = "HelloWorld";

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

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:

CipherText ciphertext =
   ESAPI.encryptor().encrypt( new PlainText(myplaintext) );

Verteidigungs-Option 2 gegen 'Verlust der Vertraulichkeit sensibler Daten':

Beispiele für das Hashen von Passwörtern. Um die Sicherheit zu erhöhen sollte jedes Passwort mit einem Zufallswert (Salt) berechnet und gespeichert werden sowie möglichst viele Iterationen beim Hashing genutzt werden.

String password = "mypassword";

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

PBKDF2

Sicherer ist allerdings die Nutzung einer PBKDF2 (Password-Based Key Derivation Function 2) wie im folgenden Beispiel:

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

bcrypt

Eine weiterer empfohlener Algorithmus ist bcrypt, hier bespielsweise unter Verwendung der jBCrypt-Bibliothek (siehe Referenzen).

String hashed = BCrypt.hashpw(password, BCrypt.gensalt(12));

Zu bcrypt gibt es mittlerweile eine noch sicherere Variante scrypt, der Link zu einer Beispielimplementierung findet sich bei den Referenzen.

Verteidigungs-Option 3 gegen 'Verlust der Vertraulichkeit sensibler Daten':

Um geheime Schlüssel sicher, aber auch gleichzeitig einfach zugänglich und austauschbar aufzubewahren empfiehlt sich eine spezielle Schlüsseldatei, wie beispielweise der Java KeyStore. In dieser Datei werden die Schlüssel mit einem Master-Password gesichert, die Datei selbst sollte getrennt von den verschlüsselten Daten abgelegt werden:

// Erzeugung eines symmetrischen Schlüssels mittels der vorher beschriebenen PBKDF2

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

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

« JAVA

JAVA-Teil 2: Unzureichende Absicherung der Transportschicht

Verteidigungs-Option 1 gegen 'Verlust der Vertraulichkeit sensibler Daten':

Absicherung der Transportschicht (beim Deployment)

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>
   
   <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 2a gegen 'Verlust der Vertraulichkeit sensibler Daten':

Absicherung der Transportschicht (auf dem Webserver - Teil 1)

Sichere Verschlüsselung

Nutzen Sie aktuelle Empfehlungen zur SSL/TLS-Sicherheit, das Thema ist derzeit sehr(!) dynamisch. Z.B.:

aktuelle Verschlüsselungsbibliotheken einsetzen, die aktuelle Protokolle und Verfahren unterstützen
Nur sichere Verschlüsselungsprotokolle unterstützen (TLS1.2, TLS1.1, ggf auch TLS1.0)
Die Verschlüsselungsverfahren auf dem Server priorisieren
sichere, ephemerale Verschlüsselungsverfahren (Cipher-Suites), die 'Forward Secrecy' unterstützen (z.B. DHE_RSA, ECDHE_RSA) mit hoher Prio versehen. Derzeit sollte dabei DHE bevorzugt werden, da es an vertrauenswürdigen Kurven für ECDHE mangelt, vgl http://safecurves.cr.yp.to; Aussichtsreichster Kandidat ist 'Curve25519', die noch nicht für TLS definiert ist (vgl IANA, DRAFT_tls-curve25519).
sichere Schlüssellängen für assymetrische und symmetrische Verfahren (gem. BSI TR-02102 Teil 2):

Schlüsseleinigung und Authentisierung: DHE(-Parameter), RSA, DSS: 2000 bits bzw. (nach 2015:) 3000 bits für RSA; ECDHE: 224 bzw. (nach 2015:) 250 bits
(symmetrische) Verschlüsselung: AES: 128 bits

RC4 und andere schwache Cipher vermeiden, ohne den Zugriff von (noch) unterstützten Browsern, oder Suchmaschinen-Bots (Webcrawlern) zu verlieren.
Richtlinie erstellen, welche Browser und Betriebssysteme, unterstützt werden sollen, sowie welche Protokolle und welche Cipher für die verschlüsselte Verbindung jeweils ausgewählt werden sollen (z.B. vorübergehend noch SSLv3, TLS_RSA_WITH_3DES_EDE_CBC_SHA).
TLS/SSL-Konfiguration des Webservers härten:

nur sichere Server-initiierte Renegotiation
keine Komprimierung
Einstellungen aller virtuellen Server (virtualHosts) prüfen
Bei Einsatz von Server Name Indication (SNI), prüfen, welcher Server der Default-Server ist. Alte Browser bzw. Betriebssysteme, ohne SNI-Unterstützung erreichen nur diesen!
Prüfen der, von der installierten OpenSSL-Version unterstützten Cipher
Reduktion der SSL-Extensions auf das notwendige Maß, z.B. Deaktivieren von Heart-Beat (vgl Heartbleed), kein Aktivieren von unsicheren Extension-DRAFTS wie z.B. Additional random, Opaque PRF Input (vgl. DualECTLS)

Konfigurations-Beispiel für Apache:

SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1

SSLCompression off 

SSLHonorCipherOrder on 

#<in Diskussion:> 

SSLCipherSuite 'EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA'

#optional kann ':!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' ergänzt werden.

Anmerkungen: - Der Cipher-String mit den SSL-Cipher-Suites wurde als (weitgehend) Whitelist formuliert, um die Kompatibilität mit alten Versionen von OpenSSL zu erhöhen.
- Das Verfahren 'DHE-RSA-AES128-SHA' wird unterdrückt, da ältere Internet-Explorer- und Java-Versionen keine Diffie-Hellman-Parameter > 1024 bit unterstützen
- Die Verfahren 'ECDHE-RSA-AES256-SHA' und 'ECDHE-RSA-AES128-SHA' explizit für ältere OpenSSL-Versionen eingefügt
- Überwachen Sie die Performance Ihres Servers, der Verbindungsaufbau mit DHE ist ca. 2,4 Mal CPU-intensiver als mit ECDHE (vgl [Vincent Bernat, 2011], [nmav's Blog, 2011])

Prüfen der Cipher-Einstellungen mittels openssl:

#<in Diskussion:> 

openssl ciphers -V "EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA:-DHE-RSA-AES128-SHA" 

#add optionally ':!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!ADH:!IDEA' to protect older Versions of OpenSSL

#use openssl ciphers -v "..." for openssl < 1.0.1:


0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x6B - DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x67 - DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
0xC0,0x14 - ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
0xC0,0x13 - ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x9D - AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0x9C - AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x35 - AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x2F - AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x0A - DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

Achtung/CAUTION: Der Cipher-String wurde nur mit einzelnen, älteren OpenSSL-Versionen getestet, es können ungewollt weitere Cipher-Suiten dadurch benutzt werden. (ONLY tested with some elder Versions of OpenSSL!)

sichere Zertifikate

Nutzen Sie eine vertrauenswürdige Zertifizierungsstelle (CA) für öffentlich erreichbare, verschlüsselte Webserver; Prüfen Sie die Vergabe-Politik der CA.
zeitgemäße, starke Verfahren mit sicheren Schlüssellängen (vgl. BSI TR-02102-2 Teil 2: 2000 bits bzw. (nach 2015:) 3000 bits für RSA), auch für alle Zwischenzertifikate und das Root-Zertifikat der CA.
Angabe der 'Fully Qualified Names' und bei 'www' auch des Domänennamens im Zertifikat, damit ein Redirekt möglich ist (z.B. von 'https://example.com' zu 'https://www.example.com').
Dedizierte Zuertifikate, je Server; keine 'Sammelzertifikate' (Wildcard-Zertifikate, z.B. *.example.com)
Überwachung der Gültigkeit der Zertifikate
IP-Adressen in Zertifikaten vermeiden, keine RFC 1918-Adressen (z.B. 192.168.1.1)
stellen Sie die, zum Verifizieren benötigte Zertifikats-Kette auf dem Webserver zur Verfügung (auch die Zwischenzertifikate)

Testen der Einstellungen und des Zertifikats:

Weitere Details im Transport Layer Protection Cheat Sheet und OWASP Testing Guide: Chapter on SSL/TLS Testing.
Links mit Beispielen für viele Plattformen:

Verteidigungs-Option 2b gegen 'Verlust der Vertraulichkeit sensibler Daten':

Absicherung der Transportschicht (auf dem Webserver - Teil 2)

Wirksamer Schutz gegen Man In The Middle-Angriffe
Die Sicherheitskonfiguration unter Option 2a 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

JAVA »

Verteidigungs-Option 2 gegen 'Verlust der Vertraulichkeit sensibler Daten':

Um vorerstellte Hash-Tabellen zu verhindern, kann jedem Datensatz eine zufällige Zeichenfolge hinzugefügt werden, welche als Salt (Deutsch: Salz) bezeichnet wird. Ein Beispiel für die sichere Erstellung eines Hashwerts ist im Folgendemn gegeben. Dafür muss das GIT-Projekt [1] eingebunden werden, ab PHP-Version 5.5 ist dies im Kern enthalten. Das Salt wird bspw. bei einem Linuxsystem in der Funktion password_hash() durch Zugriff auf /dev/urandom erstellt. Der Rückgabewert der Funktion ist eine Zeichenkette und beinhaltet u.a. den Hashwert, das Salt und den genutzten Algorithmus. Die Kosten, welche die Anzahl der Hash-Iterationen angeben, können über den dritten Parameter festgelegt werden.

$options = [
    'cost' => 12,];

$inputHash = password_hash($_GET['password'], CRYPT_SHA256, $options);

storeHash($user, $inputHash); // Speichere Hash

$hash = getHash($user); // Hole Hash aus der Datenbank

// Prüfe eingegebenes Passwort gegen gespeichertes Passwort:

$isPasswordVerified = password_verify($_GET['password'], $hash);
 
if($isPasswordVerified) {
	// Password korrekt} else {
	throw new PasswordVerificationException("");}

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

« PHP

PHP »

Verteidigungs-Option 1 gegen 'Verlust der Vertraulichkeit sensibler Daten': tbd Text	Verteidigungs-Option 2 gegen 'Verlust der Vertraulichkeit sensibler Daten': tbd Text
Verteidigungs-Option gegen 'Verlust der Vertraulichkeit sensibler Daten': tbd Text
Auswirkung(en) auf den Benutzer (ganze Breite) Text	Referenzen