Sicherheitsfehler - Veracode Bericht - Crlf Injektion

Question

Ich habe den Veracode-Bericht für meine JavaEE App. Es hatte einen Fehler bei jeder Protokollierung (mit log4j), also füge ich die StringEscapeUtils.escapeJava(log) zu allen hinzu, aber veracode meldet sie weiterhin als Sicherheitsfehler.

Ist dies eine richtige Lösung? Was kann ich noch tun?

Dies ist der Bericht Informationen: Titel: Falsche Ausgangs Neutralization für Logs

Beschreibung: Ein Funktionsaufruf in einem Protokoll schmieden Angriff führen könnte. Durch das Schreiben unsanisierter benutzerspezifizierter Daten in eine Protokolldatei kann ein Angreifer Protokolleinträge fälschen oder schädliche Inhalte in Protokolldateien einfügen. Beschädigte Protokolldateien können verwendet werden, um eine Angreiferspur abzudecken oder als Übermittlungsmechanismus für einen Angriff auf ein Protokollanzeige- oder Verarbeitungsdienstprogramm. Wenn beispielsweise ein Webadministrator ein browserbasiertes Dienstprogramm zum Überprüfen von Protokollen verwendet, ist möglicherweise ein Cross-Site-Scripting-Angriff möglich.

Empfehlungen: Vermeiden Sie die direkte Einbettung von Benutzereingaben in Protokolldateien, wenn dies möglich ist. Bereinigen Sie vom Benutzer angegebene Daten zum Erstellen von Protokolleinträgen mithilfe eines sicheren Protokollierungsmechanismus wie dem OWASP ESAPI-Protokollierer, der automatisch unerwartete Zeilenumbrüche und Zeilenvorschübe entfernt und die HTML-Entitätscodierung für nicht alphanumerische -Daten verwenden kann . Schreiben Sie nur bei Bedarf einen benutzerdefinierten Blacklist-Code. Überprüfen Sie die vom Benutzer bereitgestellten Eingaben immer, um sicherzustellen, dass dem erwarteten Format entspricht. Verwenden Sie dabei möglichst zentralisierte Datenvalidierungsroutinen.

Sie empfehlen ESAPI zu verwenden, aber es ist ein sehr großes Projekt, um die einfachste Lösung, die ich brauche, tht ist, warum ich mit String.escape ‚StringEscapeUtils.escapeJava (log)‘ versucht

Thx im fortgeschrittenen!

Answer 1

Ich leite die Veracode Application Security Consulting Gruppe und kann Ihre Frage im Detail beantworten. Der beste Ort für die Konversation ist über Support@veracode.com, da die Diskussion spezifische Details über Ihre Ergebnisse beinhalten kann, die wir wahrscheinlich nicht veröffentlichen möchten.

Die kurze Antwort ist die StringEscapeUtils.escapeJava() ist wirksam bei der Beseitigung der typischen CRLF Risiko, aber es ist nicht einer der Mechanismen unser System erkennt automatisch, da es Situationen gibt, in denen es möglicherweise nicht ausreicht.

Das Veracode-System verfügt über einen Mechanismus, um diese Befunde angemessen zu markieren, damit sie nicht zu Verwechslungen führen.

Wenden Sie sich bitte an den Veracode-Support (support@veracode.com) und wir werden ausführlich darüber sprechen können.

Mit freundlichen Grüßen, Jim.

Answer 2

In diesem Bericht sind zwei Probleme zusammengeführt.

Zuerst wird eine Protokollinjektion durchgeführt. Dabei wird ein Newline-Zeichen verwendet, um in eine separate Protokollzeile zu übergehen. StringEscapeUtils.escapeJava erzeugt Ausgabe, bei der Zeilentrennzeichen und Nicht-ASCII-Zeichen maskiert sind, was im Prinzip dafür sorgt, dass dieses Problem behoben ist. Veracode weiß das jedoch nicht - als automatisierter Scanner weiß es nicht genug darüber, was diese Methode macht, um sicher zu sagen, dass es dort eine Sicherheitslücke geben muss. Natürlich kann Veracode nicht über jede ausbrechende Funktion im Code von Drittanbietern Bescheid wissen.

Die Protokollinjektion kann auch auftreten, wenn Sie in einer Protokollzeile eigene Separatoren verwenden, z. B. Bad thing happened with parameters {0} and {1}. In diesem Fall, wenn ein Angreifer die Zeichenfolge in einem der Parameter hätte, könnten Sie nicht genau wiederherstellen, welche Daten in welchem ​​Parameter waren. Die Antwort hier ist, die Parameter mit Begrenzern zu umgeben, die nicht in der Ausgabe der Escape-Funktion erscheinen - z. B. setzen Sie doppelte Anführungszeichen um jeden Wert und verwenden Sie escapeJava, um jedes doppelte Anführungszeichen im Wert zu vermeiden.

Der zweite Angriff geschieht außerhalb Ihrer Anwendung, wenn ein Tool zum Anzeigen der Protokolle verwendet wird. Wenn dieses Tool eine Sicherheitsanfälligkeit durch Injektion aufweist, können Metazeichen in den Protokolldaten aktiv werden. Das klassische Beispiel ist das Anzeigen von Protokollen in einer Weboberfläche, die sie direkt in die Seite kopiert, ohne zu fliehen. Dies führt zu HTML-Injection und folglich zu Cross-Site-Scripting in der Protokollanzeigeanwendung.

Wenn Sie sicher sein können, dass Sie nur Protokolle in Tools anzeigen, die nicht unter solchen dämlichen Bugs leiden, müssen Sie sich keine Gedanken darüber machen.

Versuchen Sie andernfalls, alle Metazeichen von Sprachen zu entfernen, die Ihrer Meinung nach betroffen sein könnten. In der Regel < und & für HTML. Wenn Sie nicht möchten, dass alle Ihre Nicht-HTML-Protokolldaten in HTML-Code umgewandelt werden, können Sie diese Zeichen auch durch entgangene Entsprechungen wie \u003E in der Ausgabe escapeJava ersetzen.

Wieder Veracode wird automatisch nicht in der Lage sein, um herauszufinden, dass das, was Sie tun es unbedingt sicher ist, so dass Sie diese Berichte als ignoriert/behandelt-mit markieren müssen werden, wenn Sie mit ihm zufrieden sind.

Answer 3

Verwenden Sie StringEscapeUtils.escapeHtml (log), um die HTML-Injektionen zu vermeiden und möglicherweise Ihr Problem zu lösen.

Answer 4

Ich bin auf das gleiche Problem gestoßen und ignoriere diesen Fehler aus einem einfachen Grund: Ein Logger gibt mir nur ein Log-Ereignis. Es sollte nicht Formatierung kümmern (sensible Daten ausgesetzt ist ein anderes Problem).

Die Lösung hier ist, die richtige Filterung/Nachbearbeitung in der Appender hinzuzufügen, die das Protokollereignis in die Protokolldatei schreibt. In diesem Schritt können Sie Sonderzeichen entfernen (\0, \r - Wagenrücklauf, \b - Backspace, \x1b - Flucht und \x7f - löschen) und ersetzen \n mit \n... es unmöglich zu machen, gefälschten Protokollzeilen in das Protokoll zu injizieren.

Wenn Sie dies tun, können Sie alle diese Fehler ignorieren.

Auch, wenn ein Systemadministrator die falschen Werkzeuge benutzt bei Log-Dateien (alles, was Escape-Sequenzen führt, \r und Backspace) zu suchen, sollte er entlassen werden.