Zurück zur Schwachstellen-Datenbank

Fehlerhafte Verwendung von Autoboxing und Unboxing bei leistungskritischen Operationen

Beschreibung

Fehlerhafte Verwendung von Autoboxing und Unboxing bei leistungskritischen Operationen tritt auf, wenn Code Boxed Primitives verwendet, die Ineffizienzen in leistungskritische Operationen einführen können. Sprachen wie Java und C# konvertieren primitive Typen automatisch in entsprechende Wrapper-Klassen (Autoboxing) und umgekehrt (Unboxing). Obwohl dies den Code vereinfacht, erzeugt die Verwendung von Boxed Primitives in leistungssensiblen Kontexten erheblichen Overhead, einschließlich Objektallokation, Garbage-Collection-Druck und Cache-Ineffizienz.

Risiko

Autoboxing in leistungskritischem Code hat erhebliche Auswirkungen. CPU-Ressourcen können übermäßig verbraucht werden. Der Overhead der Speicherallokation steigt. Garbage-Collection-Pausen können auftreten. Die Cache-Effizienz wird reduziert. Antwortzeiten können sich verschlechtern. Ressourcenerschöpfung kann möglich sein. Denial-of-Service-Bedingungen können entstehen. Die Systemverfügbarkeit kann beeinträchtigt werden.

Lösung

Verwenden Sie primitive Typen anstelle von Boxed Types in leistungskritischem Code. Beschränken Sie Boxed Primitives auf Situationen, die typisierte Parameter erfordern. Vermeiden Sie Autoboxing in Schleifen oder häufig aufgerufenen Methoden. Verwenden Sie spezialisierte Collections wie IntStream anstelle von Stream. Erwägen Sie SparseArrays oder ArrayMap anstelle von HashMap. Profilieren Sie Code, um Autoboxing-Hotspots zu identifizieren. Überprüfen Sie wissenschaftlichen Berechnungscode auf primitive Verwendung. Verwenden Sie statische Analysetools zur Erkennung von Autoboxing.

Häufige Auswirkungen

AuswirkungDetails
VerfügbarkeitBereich: Verfügbarkeit

DoS: Ressourcenverbrauch (CPU/Speicher) – Autoboxing/Unboxing in leistungskritischem Code verursacht reduzierte Leistung und potenzielle Ressourcenerschöpfung, was die Systemverfügbarkeit beeinträchtigt.

Beispielcode und Lösung

Verwundbarer Code

// VERWUNDBAR: Boxed Primitives in leistungskritischer Schleife verwenden

public class VulnerableAutoboxing {

    // VERWUNDBAR: Long statt long verursacht massives Autoboxing
    public long vulnerableSum() {
        Long count = 0L;  // Boxed Long

        for (long i = 0; i < Integer.MAX_VALUE; i++) {
            count += i;  // Autoboxing bei jeder Iteration!
        }

        return count;
    }
}

Sichere Lösung

// SICHER: Primitive Typen in leistungskritischem Code verwenden

public class SecurePrimitiveUsage {

    // SICHER: Primitives long verwenden
    public long efficientSum() {
        long count = 0L;  // Primitives long

        for (long i = 0; i < Integer.MAX_VALUE; i++) {
            count += i;  // Kein Autoboxing!
        }

        return count;
    }

    // SICHER: IntStream für bessere Leistung verwenden
    public int streamSum(List<Integer> numbers) {
        return numbers.stream()
            .mapToInt(Integer::intValue)  // In IntStream konvertieren
            .sum();  // Primitive Operationen
    }

    // SICHER: Methodensignatur verwendet Primitives
    public int efficientAdd(int a, int b) {
        return a + b;  // Rein primitive Operation
    }
}

CVE-Beispiele

Autoboxing-Leistungsprobleme wurden in verschiedenen Anwendungen identifiziert, bei denen enge Schleifen mit Boxed Primitives Denial of Service oder verschlechterte Leistung verursachten.

Verwandte CWEs

  • CWE-400: Uncontrolled Resource Consumption (übergeordnet)
  • CWE-1006: Bad Coding Practices (Kategoriemitglied)

Referenzen

  1. MITRE Corporation. "CWE-1235: Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations." https://cwe.mitre.org/data/definitions/1235.html
  2. Oracle Java-Dokumentation zu Autoboxing
  3. SEI CERT Oracle Coding Standard for Java (EXP04-J)
  4. ISA/IEC 62443 Part 4-1 (Req SI-2)