it-swarm.com.de

Zu den Ergebnissen der Stifttests für Webanwendungen gehört eine Datei aus einem verbotenen Verzeichnis, die nicht einmal verwendet oder referenziert wird

Bei einem kürzlich durchgeführten Pen-Test einer Webanwendung wurde unter anderem eine "Sicherungsdatei" gefunden. Dies war eine Javascript-Datei, die beim Hochladen einer aktualisierten Version von filename.js1 In filename.js Umbenannt wurde.

Die 'Sicherungsdatei' befindet sich in einem Verzeichnis mit verbotener Auflistung und wird an keiner Stelle in der Anwendung referenziert oder verwendet.

Wie haben sie diese Datei gefunden?

39
Alfie

Brute-Force-Scanner

Viele automatisierte Scanner umgehen gesperrte Verzeichnislisten, indem sie "bruteforce" nach Dateien suchen. Dies bedeutet, dass sie nach zusätzlichen Dateien mit Namen suchen, die den vorhandenen Dateien ähnlich sind (d. H. filename.js1 sowie Dateien, auf die überhaupt nicht verwiesen wird (aka secret.txt). Wenn Sie zufällig eine Datei haben, deren Name in der Bruteforced-Liste enthalten ist und die sich in einem zugänglichen Verzeichnis befindet, wird sie unabhängig davon gefunden, ob "Verzeichnisliste" aktiviert ist oder nicht

Es ist erwähnenswert, dass Hacker dasselbe tun, also ist dies ein echtes Problem. Wenn sich etwas in einem öffentlich zugänglichen Verzeichnis befindet, sollten Sie im Allgemeinen davon ausgehen, dass es gefunden wird. Wenn Sie also nicht möchten, dass es öffentlich ist, müssen Sie es aus öffentlichen Verzeichnissen heraushalten. Das Deaktivieren der Verzeichnisliste bietet nur sehr wenig Sicherheit.

Echte Schwachstellen

Schließlich scheint dies kein großes Problem zu sein (und ist es wahrscheinlich auch nicht), aber das Speichern von Javascript-Dateien in öffentlichen Verzeichnissen ist im Allgemeinen eine schlechte Idee. Wenn es um XSS geht, hat ein Angreifer im Allgemeinen den größten Erfolg, wenn er eine in derselben Domäne gehostete Javascript-Datei ausnutzen kann. Dies liegt daran, dass dies die Möglichkeit bietet, einen CSP oder andere Sicherheits- "Firewalls" zu umgehen. Wenn eine ältere Javascript-Datei eine Sicherheitslücke aufweist, die in einer späteren Version behoben wurde, und ein Angreifer eine Möglichkeit gefunden hat, den Browser des Benutzers zum Laden der älteren Javascript-Datei zu zwingen, kann er sich an eine verketten schädlichere Verwundbarkeit. Dies mag weit hergeholt erscheinen, aber die Verkettung vieler kleiner Schwachstellen zu einer größeren ist die Anzahl der schlimmsten Sicherheitslücken.

tl/dr: Wenn etwas von Ihrer Website gehostet wird, aber keinen Grund hat, dort zu sein, ist dies eine Haftung. Töte es mit Vorurteilen.

75
Conor Mancone

Es gibt viele Tools, die Brute-Force-Dateinamen verwenden. Einige davon sind intelligenter als andere.

Zum Beispiel kann ein "dummes" Werkzeug nur eine Word-Liste haben, die wahrscheinliche Namen für Dateien und Verzeichnisse enthält, wie z

  • /admin/
  • wp-admin.php
  • login.php

Ein intelligenteres Tool kann sich die bereits bekannten Dateien ansehen (z. B. durch Crawlen der Anwendung) und versuchen, Dateien mit ähnlichen Namen zu finden. In Ihrem Fall gab es eine Datei mit dem Namen filename.js, also hat die Anwendung wahrscheinlich versucht, den Namen zu entstellen, wie TripeHound in einem Kommentar hervorhob:

  • filename.js1
  • filename.js.bak
  • filename.bak.js
  • .filename.js

Warum sind diese Dateien ein Problem?

Man könnte versucht sein zu glauben, dass eine nicht referenzierte Datei "sicher" ist, da sie nicht Teil der Anwendung ist. Auf die Datei kann jedoch weiterhin zugegriffen werden. Abhängig vom Inhalt der Datei kann ein Angreifer dadurch verschiedene Aktionen ausführen:

  • Ein Angreifer kann möglicherweise einen URL-Filter umgehen und eine JavaScript-Datei einschließen, die noch Schwachstellen einer älteren Version enthält.
  • Nicht referenzierte Dateien können Archive sein, die von der Bereitstellung übrig geblieben sind und dennoch Quellcode enthalten, sodass ein Angreifer darauf zugreifen kann
  • Nicht referenzierte Dateien können Anmeldeinformationen oder andere relevante Konfigurationsdaten enthalten

Im Allgemeinen ist es am besten, nicht referenzierte Dateien in Ihrer Webroot zu vermeiden. Wie der Name schon sagt, werden sie von der Anwendung nicht verwendet und sind daher nur eine Quelle von Problemen.

12
MechMK1

Das eigentliche Problem hierbei ist, dass Sie über eine Bereitstellungs-/Produktionsumgebung verfügen, die nicht über ein automatisiertes Versionsverwaltungs- und Bereitstellungssystem gesteuert (und somit replizierbar) ist.

Wenn Sie also eine neue Datei in Ihrem System finden, wissen Sie nicht, ob es sich um eine Art Hintertür handelt, die von einem Root-Kit gelöscht wurde, oder um eine harmlose umbenannte Datei, die Ihr Kollege zurückgelassen hat.

Im Allgemeinen besteht eine bewährte Sicherheitspraxis darin, immer nur Dateien auf einem Server zu haben, die von einem automatisierten Skript dort abgelegt werden, das eine Art von Build-Artefakten klont, und diesen automatisierten Prozess auch Dateien löschen zu lassen, die nicht mehr vorhanden sein sollten. Anschließend können Sie Audits ausführen für "Sind die Dateien in der Produktion so, wie es das Build-System vorschreibt?"

Und wenn Sie der Meinung sind, dass "schlechte Bereitstellungspraktiken möglicherweise kein lebensbedrohliches Problem für mein Unternehmen sein können", lade ich Sie ein, "Knight Capital Group" zu googeln.

4
Jon Watte

Genauso wie ein Angreifer: durch Raten.

Deshalb haben Sie Pen-Tester: um Dinge zu testen, an die Sie vielleicht nicht gedacht haben.

Entfernen Sie die Sicherungsdatei aus Ihrer Anwendung, damit Sie nicht darauf zugreifen können.

Wie haben sie diese Datei gefunden?

Durch sehr einfaches "Brute Force" -Raten, wie andere bereits erwähnt haben.

Sie können dies sehen, wie es passiert ist, die Anforderung für diese Datei zusammen mit den anderen Vermutungen, die gemacht wurden, in den Protokollen Ihres Webservers. Es sei denn, die Tester haben es natürlich geschafft, einen Halt zu finden, der es ihnen ermöglichte, Ihre Protokolle zurückzusetzen (die in Ihrem Testbericht aufgeführt sind), oder Sie hatten nicht genügend Protokollierung aktiviert.

aber ein weniger vorhersehbarer Renamer zu sein, ist wahrscheinlich auch keine schlechte Idee

Es wird empfohlen, zu vermeiden, dass sich alte Dateien in Ihrem Anwendungsverzeichnis befinden überhaupt. Auch in Ihren Quellverzeichnissen, insbesondere wenn Ihr Bereitstellungsmodell "Von der Quelle kopieren" ist.

Verwenden Sie die Funktionen Ihrer Versionskontrollanordnung, anstatt alte Versionen von Dateien als Referenz oder aus anderen Gründen aufzubewahren. Mit allen VCS können Sie ältere Versionen von Dateien abrufen, mit einigen können Sie Zwischenversionen zurückstellen, ohne sie ordnungsgemäß einzuchecken. Sie können die Verzweigung verwenden, um experimentelle Arbeiten zu trennen usw.

0
David Spillett