CWE-Referenz › CWE-492: Use of Inner Class Containing Sensitive Data
CWE-492: Use of Inner Class Containing Sensitive Data
CWE ID: 492
Name: Use of Inner Class Containing Sensitive Data
Beschreibung
“Innere Klassen werden in Klassen übersetzt, die auf Paket-Scope zugänglich sind und dabei Code, den der Programmierer als privat beabsichtigt hatte, potenziell für Angreifer freilegen können.”
Erweiterte Beschreibung
“Innere Klassen führen stillschweigend mehrere Sicherheitsbedenken aufgrund der Art und Weise ein, wie sie in Java Bytecode übersetzt werden. Im Java-Quellcode scheint es, als ob eine innere Klasse nur für die umschließende Klasse zugänglich deklariert werden kann. Java Bytecode kennt jedoch kein Konzept der inneren Klasse, sodass der Compiler eine innere Klassendeklaration in eine Peer-Klasse mit Paket-Level-Zugriff auf die ursprüngliche äußere Klasse transformieren muss. Noch heimtückischer ist, dass eine innere Klasse auf private Felder in ihrer umschließenden Klasse zugreifen kann. Sobald eine innere Klasse jedoch zu einer Peer-Klasse im Bytecode wird, konvertiert der Compiler private Felder, auf die die innere Klasse zugreift, in protected Felder.”
Risikominderungsmaßnahmen
Maßnahme (Implementation)
Effektivität: Unknown
Beschreibung: “Die Verwendung von sealed classes schützt objektorientierte Kapselungsparadigmen und bewahrt somit den Code vor unerwarteten Erweiterungen.”
Maßnahme (Implementation)
Effektivität: Unknown
Beschreibung: “Inner Classes bieten keinen inhärenten Schutz. Warnung: Verringern Sie niemals die Sicherheit eines Objekts von einer äußeren Klasse hin zu einer inneren Klasse. Wenn eine äußere Klasse als final oder private deklariert ist, stellen Sie sicher, dass auch ihre innere Klasse als private deklariert ist.”
Verwandte Schwachstellen
Ist Ihre IT-Infrastruktur betroffen?
Schwachstellen wie CWE-492: Use of Inner Class Containing Sensitive Data werden von Angreifern gezielt gesucht — meist automatisiert und ohne Rücksicht darauf, wie groß das betroffene Unternehmen ist. Ob eine solche Lücke bei Ihnen tatsächlich offen steht, lässt sich nur durch Prüfung feststellen:
- Schwachstellen-Scan — wiederkehrende Prüfung Ihrer Infrastruktur auf bekannte Lücken wie diese
- Penetrationstest — manuelle Prüfung eigener Software auf Schwachstellen, die kein Werkzeug findet
- Threat Modeling — Schwachstellenklassen im Entwurf vermeiden, statt sie später zu suchen