Frage:
Ist es wirklich eine Sicherheitsfehlkonfiguration, eine Versionsnummer anzuzeigen?
stormtrooper
2019-08-13 13:34:53 UTC
view on stackexchange narkive permalink

Unsere Webanwendung verwendet eine HTML-Datei, in die jQuery eingebettet ist. Gemäß der jQuery-Lizenz ( https://jquery.org/license/) müssen wir den Lizenzheader intakt lassen, einschließlich die Versionsnummer.

Unser Kunde berichtete, dass die Kombination aus Produkt und Version ein Sicherheitsrisiko darstellt. Seltsamerweise wird die Bootstrap-Version in derselben Datei nicht als Sicherheitsrisiko gemeldet.

Viele Anwendungen verwenden Bibliotheken mit Versionsnummern. Es ist sogar möglich, Versionsnummern abzurufen, indem Sie Code in Firebug oder in der Chrome Developer Console ausführen.

Unter welchen Umständen führt diese "Sicherheitsfehlkonfiguration" ( https://www.owasp.org/index) dazu. php / Top_10-2017_A6-Security_Misconfiguration) gelten für die Anzeige von Produkt- und Versionsnummer? Und wie können wir dieses Problem beheben, ohne die jQuery-Lizenz zu verletzen?

Ich denke, Sie haben einen logischen Fehler darin, dass die Offenlegung von Informationen als Sicherheitsfehlkonfiguration gleichgesetzt wird.Sie sind in keiner Weise gleich oder verwandt.
"* Seltsamerweise wird die Bootstrap-Version in derselben Datei nicht als Sicherheitsrisiko gemeldet. *" Möglicherweise haben sie die jQuery-Versionsnummer zufällig entdeckt und dies gemeldet.Oder sie denken, dass es überflüssig ist, jede gefundene Versionsnummer nicht zu überprüfen.Oder ihr automatisiertes Tool hat gerade das jQuery entdeckt.So wie Software niemals fehlerfrei ist, weil der Programmierer nicht an jeden Randfall denkt oder jede Eigenart kennt (oder vielleicht nicht genug Zeit dafür hat), ist Pentesting auch ein ungenaues Geschäft.
Das Entfernen der Versionsnummer aus der Lizenzdatei würde Ihnen sowieso nicht helfen, da ein Angreifer einfach manuell überprüfen kann, welche Version Sie verwenden.
@MechMK1 nicht, wenn Sie nicht erreichbaren Code (wie `if (true === false) {}`) oder zufällige Leerzeichen irgendwo / überall hinzufügen, dann könnten ihre automatischen Matcher nicht definitiv mit einer Version übereinstimmen.
@MonkeyZeus Wenn Sie eine naive exakte Übereinstimmung verwenden, dann haben Sie Recht.Wenn Sie jedoch nach einem gewissen Grad an Ähnlichkeit suchen, sehen geringfügige Änderungen an jQuery 3.1.7 immer noch zu 99,8% wie jQuery 3.1.7 aus.
@MechMK1 Es wurde unzählige Male erwähnt, dass, wenn ein Angreifer Sie gezielt angreift, nichts davon von Bedeutung ist, insbesondere wenn es um Code geht, der wie JS an den Client gesendet wird. Wenn Sie jedoch nur versuchen, Script-Kiddies zu vermeiden, hilft selbst die geringste Dunkelheit.Die eigentliche Sicherheitsfehlkonfiguration verwendet eine anfällige Version.Selbst wenn Sie keine anfällige Version verwenden, ist es kinderleicht, den Browser dazu zu bringen, eine anfällige Version zu verwenden.Ganz ehrlich, wenn Ihre Website aufgrund von JS anfällig ist, machen Sie aus Sicherheitsgründen etwas falsch.
@MonkeyZeus Ja, ich bin mir bewusst, aber das war nicht wirklich der Punkt.Script Kiddies verwenden gut gemachte automatisierte Tools, keine schlecht gemachten selbstgeschriebenen.Jeder grundlegende Webapp-Analysator kann eine modifizierte jQuery-Version identifizieren. Wenn Sie also versuchen, sie zu verschleiern, führt dies nur zu Problemen und zu keinem Sicherheitsvorteil.Obwohl ich gerne wissen möchte, wie Sie einen Browser veranlassen würden, eine anfällige jQuery-Version zu verwenden, wenn die Site eine Version ohne bekannte Vulns enthält.
@MechMK1 Kopieren + Einfügen + In das Konsolenfenster eingeben: `var script = document.createElement ('script');script.type = 'text / javascript';script.src = 'https://ajax.googleapis.com/ajax/libs/jquery/1.2.3/jquery.min.js';document.head.appendChild (Skript);alert (jQuery.fn.jquery); `
Wenn Sie Zeit damit verbringen, clientseitige Bibliotheksversionen auszublenden, anstatt Zeit damit zu verbringen, echte Sicherheitsprobleme zu beheben, sind Sie möglicherweise anfälliger.
@MonkeyZeus Ja, aber Sie können dies nur sich selbst antun, nicht anderen.Sie konnten mich beispielsweise nicht dazu bringen, eine anfällige jQuery-Version zu verwenden.
Ich sehe auf https://jquery.org/license/ keinen Hinweis darauf, dass die Versionsnummer intakt bleiben muss.Es heißt, der Copyright-Header muss ... solange Sie das `Copyright 2005, 2014 jQuery Foundation, Inc. und andere Mitwirkende haben;Veröffentlicht unter der MIT-Lizenz;http: // jquery.org / license` Ich würde nicht erwarten, dass sie ein Auge schlagen.
@ceejayoz Wie bereits erwähnt, würde es Ihnen sowieso nicht helfen, die Version zu verschleiern.
@MechMK1 Sicher, aber es würde OP helfen, den Sicherheitsscanner des Kunden vom Rücken zu bekommen.
@ceejayoz "Beheben" von Problemen, damit der Scanner nicht mehr klagt, ist eines der schlimmsten Dinge, die Sie tun können.Sicher, das Löschen einer Version in einer Lizenzdatei reicht nicht aus, aber es ist der grundlegend falsche Ansatz.Aus diesem Grund ist der Debian PRNG-Fehler entstanden.
@MechMK1 Solange OP über eine sichere Version von jQuery verfügt, ist das Scannerergebnis hier * falsch positiv *.Ich befürworte nicht, eine unsichere Version zu vertuschen.Ich sage, dass die gekennzeichnete Versionsoffenlegung auf diese Weise sicher behandelt werden kann.
@ceejayoz Ja, das stimmt, und in diesem speziellen Fall würde ich kein Problem damit sehen.Aber ich würde argumentieren, dass es im Allgemeinen besser ist, zu lernen, wie man Berichte als falsch positiv kennzeichnet, als einen "Fix" zu beschleunigen und zu implementieren.
@MechMK1 Fair genug, dem kann ich zustimmen.
Fünf antworten:
#1
+64
Sjoerd
2019-08-13 14:26:25 UTC
view on stackexchange narkive permalink

Die Sicherheitsauswirkung der Offenlegung der Versionsnummer besteht darin, dass ein Angreifer sofort erkennen kann, ob Ihre Version für eine bekannte Sicherheitsanfälligkeit anfällig ist. Beispielsweise ist jQuery vor 3.4.0 für CVE-2019-11358 anfällig. Daher ist es für einen Angreifer eine nützliche Information, zu wissen, ob Ihre jQuery 3.3.9 oder 3.4.1 ist.

Allerdings mit JavaScript Wenn der Browser ausgeführt wird, kann der Angreifer auf den gesamten Quellcode zugreifen. Daher kann nicht ausgeblendet werden, ob Ihre jQuery anfällig ist. Selbst wenn Sie die Version ausblenden, kann der Angreifer den Code vergleichen oder einfach einen Exploit versuchen, um festzustellen, ob Sie anfällig sind. Durch das Ausblenden der Versionsnummer wird möglicherweise etwas mehr Arbeit geleistet, aber realistischerweise wird wenig erreicht.

Darüber hinaus gibt es andere Möglichkeiten, dies zu verringern:

  • Bleiben Sie über die Sicherheit auf dem Laufenden Probleme in den Bibliotheken, die Sie verwenden. Abonnieren Sie eine Mailingliste oder eine andere Veröffentlichungsmethode für Sicherheitsprobleme.
  • Aktualisieren Sie die Clientbibliotheken, wenn ein Sicherheitsproblem festgestellt wird.

Wenn Sie immer eine nicht anfällige Person haben Version Da Sie regelmäßig aktualisieren, ist es kein Problem, dass die Version veröffentlicht wird. Und Sie können Ihrem Kunden mitteilen, dass Sie auf diese Weise die Offenlegung von Informationen verringern.

Einverstanden, nur eine kleine Anmerkung: "* Das Ausblenden der Versionsnummer kann etwas mehr Arbeit machen *" Ich würde behaupten, es ist etwas mehr als "leicht": um Code wieder einer Versionsnummer zuzuordnen (um das zu schließen)Versionsnummer in eine CVE-Suche), müssen Sie einen Index aller Varianten (minimiert, möglicherweise mit unterschiedlichen Packern) aller Versionen aller relevanten Bibliotheken haben.Ein dedizierter Angreifer kann dies tun, wenn er den Verdacht hat, dass eine ausnutzbare Sicherheitsanfälligkeit vorliegt. In den meisten Fällen sind die Sicherheitslücken clientseitiger Bibliotheken jedoch nicht erreichbar oder haben nur begrenzte Auswirkungen.Ich denke, nur wenige Angreifer würden sich die Mühe machen.
@Luc Ich würde argumentieren, dass es einfach nutzlos ist. Sie können über `$ .fn.jquery` darauf zugreifen, viel einfacher als die Kommentare zu verschrotten, die in den meisten Quellen aufgrund von SOP ohnehin unlesbar sind.
@Kaiido Schön, ich wusste nichts von `$ .fn.jquery`.Ich bin mir nicht sicher, ob dies ein glücklicher Zufall ist oder ob es für andere Bibliotheken üblich ist, dies auch zu haben.Wenn ich die Bibliothek nachschlage, die ich am zweithäufigsten sehe, Bootstrap, scheint es eine solche Funktion zu geben (https://stackoverflow.com/questions/15335537/how-to-identify-bootstrap-version)Das.
@Luc Wenn Sie über das CSS sprechen, dann nein, es ist nichts von js verfügbar (abgesehen von Kommentaren).Jedes Bootstrap-Plugin verfügt jedoch über eine eigene VERSION, auf die über den Konstruktor zugegriffen werden kann: https://stackoverflow.com/questions/43233588/how-can-i-get-bootstrap-version-via-javascript
@Sjoerd Welche Mailinglisten würden Sie für ein webbasiertes System empfehlen (Apache, Nginx, JQuery, SSH, FTP, Serverpakete im Allgemeinen)?
@echo Es gibt Tools, die speziell für die Überwachung von Schwachstellen in Komponenten von Drittanbietern entwickelt wurden.Zwei der führenden Unternehmen in diesem Bereich sind derzeit Palamida und Black Duck. Wenn Sie jedoch eine Google-Suche durchführen, können Sie eine Liste neuerer Produkte zu unterschiedlichen Preisen (einige kostenlos, aber mit erheblicher manueller Arbeit) erstellen, die Ihren Anforderungen entsprechenbesser.
@Echo Sie haben im Allgemeinen alle ihre eigenen Mailinglisten.Oss-sec ist jedoch eine gute Sammel-Mailingliste.
Kann mich jemand darauf hinweisen, wie eine clientseitige Bibliothek alleine auf jeden Fall eine Sicherheitslücke sein kann?Damit ein Angriff stattfinden kann, muss der Angreifer zuerst Code auf der Clientseite ausführen.Kurz vor "eval (window.location.hash)" sehe ich nicht, wie eine Bibliothek, die HTML manipuliert, anfällig für Angriffe sein kann, ohne dass die Website bereits kompromittiert wird.
#2
+36
schroeder
2019-08-13 14:26:41 UTC
view on stackexchange narkive permalink

Die Kenntnis der Versionsnummer ist keine Sicherheitsfehlkonfiguration. Das Risiko der Offenlegung von Versionsnummern ist eine "Offenlegung von Informationen". Dies kann eine Gefahr darstellen, wenn die Kenntnis dieser Informationen einen Angreifer dazu befähigt, einen Exploit für eine Sicherheitsanfälligkeit in dieser bestimmten Version zu erstellen.

Auch wenn die Bibliothek eine Sicherheitsanfälligkeit enthält, handelt es sich immer noch nicht um ein Sicherheitsfehlerkonfigurationsproblem. Dies wäre "A9-verwendende Komponenten mit bekannten Sicherheitslücken".

Es scheint also, dass der Kunde ein falsches und starres Verständnis der Risiken und der Situation hat.

#3
+11
Tom
2019-08-14 09:38:59 UTC
view on stackexchange narkive permalink

Es ist ein sehr, sehr altes Denkmuster in der Cybersicherheit, dass die Offenlegung der Versionsnummer von etwas ein Sicherheitsrisiko darstellt.

Angeblich erleichtert es Angreifern die Arbeit, denn wenn sie die Version kennen Unabhängig davon, was Sie ausführen, können sie die Schwachstellen nachschlagen, die für diese Version gelten.

Genau das tun Sicherheitsscanner. Nessus et al. Haben eine integrierte Datenbank mit Schwachstellen nach Versionsnummer. Wenn Sie sich also nie selbst scannen und sich diese Informationen verstecken, schießen Sie sich in den Fuß.

Außer , dass sowohl Scanner als auch Angreifer (die Scanner verwenden, wissen Sie?) Andere Mittel haben als ein einfaches strcmp (), um die Versionsnummer von etwas zu bestimmen. Es ist etwas aufwändiger und kann nicht immer eine genaue Zahl bestimmen, aber kein Angreifer, der etwas wert ist, wird jQuery 3.3.0 mit jQuery 2.2.1 verwechseln.

Angreifer ohne Skript-Kiddie-Level haben auch mehrere andere Methoden, um herauszufinden, was Sie ausführen, vom Fingerabdruck bis zum automatischen Testen einiger hundert Exploits und dem Überprüfen der Funktionsweise.

Durch das Ausblenden der Versionsnummer erhalten Sie nur eine sehr geringe zusätzliche Sicherheit. Wenn Sie nichts mehr zu tun haben, können Sie es tun oder nicht. Solange Sie echte Sicherheitsprobleme beheben müssen, verbringen Sie Ihre Zeit damit.

Schließlich ist das Offenlegen der Versionsnummer kein Fall einer Sicherheitsfehlkonfiguration. Wenn Ihr Tool dies als solches meldet, melden Sie diesen Fehler im Upstream, damit Ihr Tool behoben werden kann.

"* Wenn Sie sich nie selbst scannen, schießt sich das Verstecken von [Versionsnummern] in den Fuß. *" Außer es gibt ein Entwicklungsteam, das die Software erstellt hat.Sie wissen, welche Version sie verwendet haben und können sie auf Schwachstellen überprüfen.Dies zu tun ist so ungewöhnlich wie das Ausführen von Schwachstellen-Scans für sich selbst (fast niemand tut dies auch). Wenn Sie jedoch eine auswählen müssen, würde ich die Versionsnummern lieber selbst überprüfen, als sie für alle sichtbar zu machen.Ja, gezielte Angreifer verwenden andere Mittel, um die Informationen zu erhalten, aber das bedeutet nicht, dass Sie es ihnen oder den Skriptkindern einfach machen möchten.
Wenn Sie ein leichtes Ziel für Skriptkinder sind, sind offen gelegte Versionsnummern das geringste Ihrer Probleme.Ich bin damit einverstanden, dass das Entwicklerteam nach Vulns suchen sollte, aber weißt du was?Sie sind keine Sicherheitsexperten und Sie auch.Es macht Sinn, Scans durchzuführen, anstatt dem Entwicklerteam zu vertrauen.Idealerweise würden Sie ** beides ** tun.
#4
  0
jfran3
2019-08-13 14:24:10 UTC
view on stackexchange narkive permalink

Ich bin nicht 100% sicher, ob dies eine doppelte Frage ist oder nicht. Wenn es als solches markiert werden sollte, mache bitte Mods, aber ich denke, dass der Rat in diesem speziellen Beitrag " Gibt es eine Basisversion von jQuery, die keine XSS-Sicherheitslücke aufweist" zur Lösung des Problems nützlich wäre Problem für Ihre Kunden.

Einer der Hauptfaktoren, die Sie bei der Beantwortung der allgemeinen Frage bewerten müssen, ist, ob die vorgeschlagene Sicherheitslösung einen guten ROI für Ihren Kunden darstellt. Lohnt es sich, eine Ausnahme in die Sicherheitsrichtlinie zu schreiben oder Code zu implementieren, um die zurückgegebenen Versionsnummern zu entfernen (oder wie der Kommentator feststellt, dass jQuery möglicherweise nicht mehr funktioniert), um das Risiko einer Offenlegung der Versionsnummer zu verringern? In vielen Fällen wird es nicht sein, in anderen wird es und es wird alles von der individuellen Situation abhängen. Sie sollten jedoch auf jeden Fall sicherstellen, dass die von Ihnen verwendeten Versionen nicht bereits durch die Verwendung von cvedetails oder der NIST National Vulnerability Database kompromittiert wurden.

Warum Bootstrap nicht gemeldet wird, liegt wahrscheinlich am Scanner (den Sie nicht erwähnt haben) und an den Tests, die Sie für die Auswertung verwenden. Nach der Logik der OWASP-Sicherheitsfehlkonfiguration könnte dies ebenfalls als Sicherheitslücke angesehen werden und sollte / sollte aus demselben Grund nicht behoben werden. Unabhängig davon bietet die Offenlegung dieser Informationen jedem potenziellen Angreifer einen weiteren Datenpunkt, von dem aus er Nachforschungen anstellen und potenzielle Schwachstellen identifizieren kann.

#5
  0
rackandboneman
2019-08-16 00:38:37 UTC
view on stackexchange narkive permalink

Am Ende ist das Verstecken Sicherheit durch Dunkelheit.

Was oft als fehlgeleitetes und nutzloses Verhalten missbilligt wird.

Was es ist, wenn es auf seinem eigenen und gegen A verwendet wird GEZIELTER ANGRIFF.

Es kann "angemessene" Sicherheitsmaßnahmen verbessern, indem die Wahrscheinlichkeit verringert wird, dass Sie nicht von Personen anvisiert werden, die noch nach einem Ziel suchen.

Es minimiert das RISIKO

"Richtige" Sicherheit bedeutet, sicherzustellen, dass Ihre Handlungen legal sind. Sicherheit durch Dunkelheit bedeutet, immer noch sicherzustellen, dass Sie keine unbegründete polizeiliche Aufmerksamkeit auf sich ziehen, falls Sie sich über das Gesetz irren.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...