2016-07-18 16 views
5

Während eines PA-DSS-Prüfprozesses wurde nach dem Ausführen einer Kreditkartenzahlung die Kreditkartennummer in unserem serverseitigen Code (Prozessspeicherauszug) gefunden.Wie kann java.io.BufferedOutputStream für Speicherabstreifer für vertrauliche Kartendaten gesichert werden?

Ich habe versucht zunächst nur JVM Garbage Collector am Ende der Zahlungstransaktion aufrufen, da unsere Variablen lokal waren, um dieses Problem zu lösen. Aber es gibt immer noch eine einzige Instanz, die sich auf eine Kreditkarte (CC) in dem Speicherabbild bezieht. Diese CC-Zeichenfolge (tatsächlich war es ein Byte []) wurde vom SOAP CXF-Clientobjekt referenziert, das intern sun.net.www.protocol.https.HttpsClient verwendete, das schließlich das BufferedOutputStream-Objekt verwendete.

Blick auf Code für BufferedOutputStream Ich habe bemerkt, dass die private Methode flushBuffer() nur die Count-Variable auf Null gesetzt und das interne Array byte [] nicht zurückgesetzt hat.

Kein Problem in diesem Code für reguläre App (nur Reset-Zählvariable ist einfacher und effizienter), aber dies führte zu einem Flag in unserem sicheren Audit-Prozess, so dass meine Alternative war, ein benutzerdefiniertes java.io.BufferedOutputStream zu erstellen Zerlege dieses Byte-Array und dann müsste ich diese Datei im Tomcat-Boot-Klassenpfad hinzufügen.

private void flushBuffer() throws IOException { 
    if (count > 0) { 
     out.write(buf, 0, count); 

     //NEW - Custom code to reset buffer 
     for (int i = 0; i < count; i++) { 
      buf[i] = 0; 
     } 
     //End custom code 

     count = 0; 
    } 
    } 

Das tatsächlich funktionierte und ich konnte die CC-Daten im Speicher-Dump nicht mehr finden, aber ich fühle mich nicht dies die richtige Lösung ist (individuelle Änderung einer Java-Kern-Klasse).

Irgendwelche Vorschläge, wie ich dieses Problem auf eine andere Weise angehen könnte (ohne irgendeinen Bibliothekscode ändern zu müssen)?

+0

Wird der SOAP-Client irgendwie zwischengespeichert ?? Oder ist die Verbindung, die es verwendet? –

+0

Ich bin überrascht, dass dies der einzige Fall war, den Sie gefunden haben. Im Allgemeinen sind JVM-Dumps nicht überraschend sicher. – EJP

+0

Ich habe in Eclipse Memory Analyzer geschaut und die Klasse, die diese sensiblen Daten zwischenspeichert, ist sun.security.ssl.SSLSocketImpl (innerhalb von HandshakeListeners). Aber ich behalte keinen direkten Bezug zu diesem Soap-Client oder dieser Verbindung. – amboni

Antwort

4

Mit Java können Sie Bibliotheken erweitern, ohne "irgendeinen Bibliothekscode ändern" zu müssen. Sie können BufferedOutputStream erweitern, um SecureBufferedOutputStream zu erstellen. Dadurch wird der Inhalt des Puffers nach einer Flush- und vor einer Garbage Collection auf Null gesetzt (falls Ihre JVM-Implementierung nicht bereits den durch Garbage Collection gesammelten Speicher auf Null setzt).

import java.io.BufferedOutputStream; 
import java.io.IOException; 
import java.io.OutputStream; 
import java.util.Arrays; 

public class SecureBufferedOutputStream extends BufferedOutputStream { 

    public SecureBufferedOutputStream(OutputStream out) { 
     super(out); 
    } 

    public SecureBufferedOutputStream(OutputStream out, int size) { 
     super(out, size); 
    } 

    @Override 
    public synchronized void flush() throws IOException { 
     super.flush(); 
     Arrays.fill(buf, (byte) 0); 
    } 

    @Override 
    protected void finalize() throws Throwable { 
     super.finalize(); 
     Arrays.fill(buf, (byte) 0); 
    } 
} 
+0

Danke für deine Antwort rocketblast, aber wie ich in meiner Frage sagte, war das Problem in einer anderen Java-Bibliothek (CXF), die BufferedOutputStream verwendet. Ich müsste alle relevanten CXF-Klassen ändern, um diesen neuen sicheren Puffer zu verwenden. Also müsste ich diese Apache-Bibliothek noch ändern. – amboni