2.1 CVE-2012-1629
Cross-Site-Scripting (XSS)-Schwachstelle im Taxotouch-Modul für Drupal erlaubt entfernten, authentifizierten Benutzern mit bestimmten Rechten, beliebiges Web-Script oder HTML über nicht spezifizierte Vektoren einzuschleusen.
https://nvd.nist.gov/vuln/detail/CVE-2012-1629
Kategorien
CWE-79 : Unsachgemäße Neutralisierung von Eingaben bei der Generierung von Webseiten ('Cross-Site Scripting')
Das Produkt neutralisiert die vom Benutzer kontrollierbaren Eingaben nicht oder falsch, bevor sie in eine Ausgabe eingefügt werden, die als Webseite verwendet und anderen Benutzern zur Verfügung gestellt wird. Eine gängige Abkürzung für Cross-Site Scripting. Wird als Synonym für gespeichertes (Typ 2) XSS verwendet. In den ersten Jahren nach der Entdeckung von XSS war "CSS" eine häufig verwendete Abkürzung. Dies führte jedoch zu Verwechslungen mit "Cascading Style Sheets,", so dass die Verwendung dieses Akronyms deutlich zurückgegangen ist. Verwenden Sie automatisierte statische Analysetools, die auf diese Art von Schwachstellen abzielen. Viele moderne Techniken nutzen die Datenflussanalyse, um die Anzahl der Fehlalarme zu minimieren. Dies ist keine perfekte Lösung, da eine 100-prozentige Genauigkeit und Abdeckung nicht machbar ist, insbesondere wenn mehrere Komponenten beteiligt sind. Verwenden Sie das XSS Cheat Sheet [REF-714] oder automatisierte Tools zur Testgenerierung, um eine Vielzahl von Angriffen gegen Ihre Webanwendung zu starten. Das Cheat Sheet enthält viele subtile XSS-Variationen, die speziell gegen schwache XSS-Abwehrmechanismen gerichtet sind. Machen Sie sich mit allen potenziellen Bereichen vertraut, in denen nicht vertrauenswürdige Eingaben in Ihre Software gelangen können: Parameter oder Argumente, Cookies, alles, was aus dem Netzwerk gelesen wird, Umgebungsvariablen, Reverse-DNS-Lookups, Abfrageergebnisse, Anfrage-Header, URL-Komponenten, E-Mail, Dateien, Dateinamen, Datenbanken und alle externen Systeme, die Daten für die Anwendung bereitstellen. Denken Sie daran, dass solche Eingaben auch indirekt über API-Aufrufe erfolgen können. Stellen Sie bei allen Sicherheitsprüfungen, die auf der Client-Seite durchgeführt werden, sicher, dass diese Prüfungen auf der Server-Seite dupliziert werden, um CWE-602 zu vermeiden. Angreifer können die clientseitigen Überprüfungen umgehen, indem sie Werte ändern, nachdem die Überprüfungen durchgeführt wurden, oder indem sie den Client ändern, um die clientseitigen Überprüfungen vollständig zu entfernen. Diese geänderten Werte würden dann an den Server übermittelt. Falls verfügbar, sollten strukturierte Mechanismen verwendet werden, die automatisch die Trennung zwischen Daten und Code durchsetzen. Diese Mechanismen können in der Lage sein, die relevanten Quotierungen, Kodierungen und Validierungen automatisch bereitzustellen, anstatt sich darauf zu verlassen, dass der Entwickler diese Fähigkeit an jedem Punkt der Ausgabegenerierung bereitstellt. Schreiben Sie mit Struts alle Daten aus Formular-Beans mit dem Filter-Attribut der Bean auf true. Um XSS-Angriffe auf das Sitzungscookie des Benutzers abzuschwächen, setzen Sie das Sitzungscookie auf "HttpOnly". In Browsern, die die Funktion "HttpOnly" unterstützen (z. B. neuere Versionen von Internet Explorer und Firefox), kann dieses Attribut verhindern, dass das Sitzungscookie des Benutzers für bösartige clientseitige Skripte, die document.cookie verwenden, zugänglich ist. Dies ist keine vollständige Lösung, da HttpOnly nicht von allen Browsern unterstützt wird. Noch wichtiger ist, dass XMLHTTPRequest und andere leistungsstarke Browsertechnologien Lesezugriff auf HTTP-Header bieten, einschließlich des Set-Cookie-Headers, in dem das HttpOnly-Flag gesetzt ist. Wenn die Menge der akzeptablen Objekte, wie z. B. Dateinamen oder URLs, begrenzt oder bekannt ist, erstellen Sie eine Zuordnung von einer Menge fester Eingabewerte (z. B. numerische IDs) zu den tatsächlichen Dateinamen oder URLs und weisen alle anderen Eingaben zurück. Verwenden Sie eine Anwendungsfirewall, die Angriffe auf diese Schwachstelle erkennen kann. Dies kann in Fällen von Vorteil sein, in denen der Code nicht korrigiert werden kann (weil er von einem Dritten kontrolliert wird), als Notfallpräventionsmaßnahme, während umfassendere Software-Sicherheitsmaßnahmen angewendet werden, oder um eine tiefgehende Verteidigung zu gewährleisten. Wenn Sie PHP verwenden, konfigurieren Sie die Anwendung so, dass sie register_globals nicht verwendet. Entwickeln Sie bei der Implementierung die Anwendung so, dass sie nicht auf diese Funktion angewiesen ist, aber seien Sie vorsichtig bei der Implementierung einer register_globals-Emulation, die Schwachstellen wie CWE-95, CWE-621 und ähnlichen Problemen unterliegt. Python Library Manager hat einen vom Benutzer eingegebenen Suchbegriff nicht ausreichend neutralisiert, was reflektiertes XSS ermöglichte. Python-basierte E-Commerce-Plattform hat zurückgegebene Inhalte auf Fehlerseiten nicht entschlüsselt, was reflektierte Cross-Site-Scripting-Angriffe ermöglichte. Universelles XSS in mobilen Betriebssystemen, wie es in freier Wildbahn per CISA KEV ausgenutzt wurde. Chain: Unsachgemäße Eingabevalidierung (CWE-20) in einem Firewall-Produkt führt zu XSS (CWE-79), wie in freier Wildbahn gemäß CISA KEV ausgenutzt. Admin GUI ermöglicht XSS durch Cookie. Web-Statistikprogramm ermöglicht XSS durch manipulierte HTTP-Header. Web-Log-Analyseprodukt ermöglicht XSS durch manipulierte HTTP-Referer-Header. Kette: Versagen des Schutzmechanismus ermöglicht XSS Kette: unvollständige Denyliste (CWE-184) prüft nur den Tag "javascript:" und ermöglicht XSS (CWE-79) unter Verwendung anderer Tags Kette: unvollständige Denyliste (CWE-184) entfernt nur SCRIPT-Tags und ermöglicht XSS (CWE-79) Reflektiertes XSS unter Verwendung von PATH_INFO in einer URL Reflektiertes XSS, das bei der Erzeugung einer Fehlermeldung nicht ordnungsgemäß behandelt wird Reflektiertes XSS, das über eine E-Mail-Nachricht gesendet wird. Gespeicherte XSS in einem Sicherheitsprodukt. Gespeicherte XSS unter Verwendung einer Wiki-Seite. Gespeicherte XSS in einer Gästebuch-Anwendung. Gespeicherte XSS in einer Gästebuchanwendung unter Verwendung von Javascript: URI in einem bbcode img Tag. Chain: Bibliotheksdatei ist nicht gegen eine direkte Anfrage geschützt (CWE-425), was zu reflektiertem XSS führt (CWE-79).
Referenzen
CPE
| cpe |
start |
ende |
| Configuration 1 |
| cpe:2.3:a:dmitry_loac:taxotouch:-:*:*:*:*:*:*:* |
|
|
| Running on/with |
| cpe:2.3:a:drupal:drupal:-:*:*:*:*:*:*:* |
|
|
REMEDIERUNG
EXPLOITS
Exploit-db.com
| id |
beschreibung |
datum |
|
| Keine bekannten Exploits |
Andere (github, ...)
| Url |
| Keine bekannten Exploits |
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
beschreibung |
schweregrad |
| 209 |
XSS Using MIME Type Mismatch
Ein Angreifer erstellt eine Datei mit Skript-Inhalt, wobei der angegebene MIME-Typ der Datei so beschaffen ist, dass Skripte nicht erwartet werden. Der Angreifer bringt das Opfer dazu, auf eine URL zuzugreifen, die mit der Skriptdatei antwortet. Einige Browser erkennen, dass der angegebene MIME-Typ der Datei nicht mit dem tatsächlichen Typ ihres Inhalts übereinstimmt, und schalten automatisch auf die Verwendung eines Interpreters für den tatsächlichen Inhaltstyp um. Wenn der Browser vorher keine Skriptfilter aufruft, kann das Skript des Angreifers auf dem Ziel unkontrolliert ausgeführt werden und möglicherweise die Cookies des Opfers preisgeben oder ein beliebiges Skript in dessen Browser ausführen. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Bereiche auf, die es einem Benutzer ermöglichen, Inhalte über eine HTTP-POST-Anforderung hochzuladen. Dies ist typischerweise in Blogs oder Foren der Fall. [Der Angreifer verwendet die in der "Explore"-Phase erfassten Einstiegspunkte als Zielliste und lädt Dateien mit Skriptinhalten hoch, deren MIME-Typ jedoch als Dateityp angegeben ist, der keine Skriptinhalte ausführen kann. Wenn die Anwendung nur den MIME-Typ der Datei überprüft, kann sie die Datei durchlassen, so dass das Skript von jedem Benutzer, der auf die Datei zugreift, ausgeführt wird. [Sobald der Angreifer herausgefunden hat, welche Datei-Upload-Speicherorte für MIME-Typ-Fehlanpassungen anfällig sind, lädt er ein bösartiges Skript hoch, das als nicht skriptfähige Datei getarnt ist. Der Angreifer kann viele Ziele verfolgen, vom Diebstahl von Sitzungs-IDs, Cookies, Anmeldedaten und Seiteninhalten eines Opfers. [Damit der Angriff erfolgreich ist, muss das Opfer den gespeicherten bösartigen Inhalt auf der Webseite sehen. |
Mittel |
| 588 |
DOM-Based XSS
Bei dieser Art von Angriff handelt es sich um eine Form von Cross-Site Scripting (XSS), bei der ein bösartiges Skript in das von einem Webbrowser geparste clientseitige HTML eingefügt wird. Der von einer anfälligen Webanwendung bereitgestellte Inhalt enthält Skriptcode, der zur Manipulation des Document Object Model (DOM) verwendet wird. Dieser Skriptcode überprüft entweder die Eingaben nicht ordnungsgemäß oder führt keine ordnungsgemäße Ausgabecodierung durch, so dass ein Angreifer die Möglichkeit hat, ein bösartiges Skript einzufügen und einen XSS-Angriff zu starten. Ein wichtiger Unterschied zwischen anderen XSS-Angriffen und DOM-basierten Angriffen besteht darin, dass bei anderen XSS-Angriffen das bösartige Skript beim ersten Laden der anfälligen Webseite ausgeführt wird, während ein DOM-basierter Angriff irgendwann nach dem Laden der Seite ausgeführt wird. Ein weiteres Unterscheidungsmerkmal von DOM-basierten Angriffen ist, dass in einigen Fällen das bösartige Skript überhaupt nicht an den anfälligen Webserver gesendet wird. Ein solcher Angriff umgeht garantiert alle serverseitigen Filterungsversuche zum Schutz der Benutzer. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, Formulare, aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene gängige Skript-Nutzlasten und Sonderzeichen, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann. Speziell bei DOM-basiertem XSS sucht der Angreifer nach Bereichen, in denen Eingaben verwendet werden, um das DOM direkt zu verändern. [Sobald der Angreifer ermittelt hat, welche Parameter für XSS anfällig sind, erstellt er eine bösartige URL, die den XSS-Exploit enthält. Der Angreifer kann viele Ziele verfolgen, z. B. den Diebstahl von Sitzungs-IDs, Cookies, Anmeldedaten und Seiteninhalten des Opfers. Bei DOM-basiertem XSS wird das bösartige Skript möglicherweise nicht einmal an den Server gesendet, da der Browser des Opfers das DOM selbst manipuliert. Dies kann dazu beitragen, serverseitige Erkennungsmechanismen zu umgehen. [Damit der Angriff erfolgreich ist, muss das Opfer auf die bösartige URL zugreifen. |
Sehr hoch |
| 591 |
Reflected XSS
Bei dieser Art von Angriff handelt es sich um eine Form des Cross-Site Scripting (XSS), bei der ein bösartiges Skript von einer anfälligen Webanwendung "gespiegelt" und dann vom Browser des Opfers ausgeführt wird. Der Prozess beginnt damit, dass ein Angreifer ein bösartiges Skript an ein Opfer sendet und das Opfer dazu bringt, das Skript an die anfällige Webanwendung zu senden. [Mit einem Browser oder einem automatisierten Tool verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, Formulare, aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene gängige Skript-Nutzlasten und Sonderzeichen, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann. [Sobald der Angreifer ermittelt hat, welche Parameter für XSS anfällig sind, erstellt er eine bösartige URL, die den XSS-Exploit enthält. Der Angreifer kann viele Ziele verfolgen, z. B. den Diebstahl von Sitzungs-IDs, Cookies, Anmeldedaten und Seiteninhalten des Opfers. [Damit der Angriff erfolgreich ist, muss das Opfer auf die böswillige URL zugreifen. |
Sehr hoch |
| 592 |
Stored XSS
Ein Angreifer nutzt eine Form des Cross-Site Scripting (XSS), bei der ein bösartiges Skript dauerhaft im Datenspeicher einer anfälligen Webanwendung als gültige Eingabe "gespeichert" wird. [Mit einem Browser oder einem automatisierten Tool verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, Formulare, aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. Der Angreifer sucht nach Bereichen, in denen Benutzereingaben gespeichert sind, z. B. Benutzerprofile, Warenkörbe, Dateimanager, Foren, Blogs und Protokolle. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene gängige Skript-Nutzlasten und Sonderzeichen, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann. [Sobald der Angreifer festgestellt hat, welche Speicherorte für XSS anfällig sind, interagiert er mit der Webanwendung, um den bösartigen Inhalt zu speichern. Der Angreifer kann viele Ziele verfolgen, z. B. den Diebstahl von Sitzungs-IDs, Cookies, Anmeldedaten und Seiteninhalten von einem Opfer. [Damit der Angriff erfolgreich ist, muss das Opfer den gespeicherten bösartigen Inhalt auf der Webseite sehen können. |
Sehr hoch |
| 63 |
Cross-Site Scripting (XSS)
Ein Angreifer bettet bösartige Skripte in Inhalte ein, die den Webbrowsern angezeigt werden sollen. Ziel des Angriffs ist es, dass die Zielsoftware, der clientseitige Browser, das Skript mit der Berechtigungsstufe des Benutzers ausführt. Ein Angriff dieser Art nutzt die Schwachstellen eines Programms aus, die dadurch entstehen, dass Remote-Hosts Code und Skripte ausführen können. Webbrowser verfügen beispielsweise über einige einfache Sicherheitskontrollen, aber wenn ein Angreifer Skripte ausführen kann (indem er sie in benutzergenerierte Inhalte wie Bulletin Boards einschleust), können diese Kontrollen umgangen werden. Außerdem sind diese Angriffe für einen Endbenutzer sehr schwer zu erkennen. [Mit Hilfe eines Browsers oder eines automatisierten Tools verfolgt ein Angreifer alle öffentlichen Links und Aktionen auf einer Website. Er zeichnet alle Links, Formulare, aufgerufenen Ressourcen und alle anderen potenziellen Einstiegspunkte für die Webanwendung auf. [Der Angreifer verwendet die in der "Explore"-Phase gesammelten Einstiegspunkte als Zielliste und injiziert verschiedene gängige Skript-Nutzlasten, um festzustellen, ob ein Einstiegspunkt tatsächlich eine Sicherheitslücke darstellt, und um das Ausmaß zu charakterisieren, in dem die Sicherheitslücke ausgenutzt werden kann. [Stehlen von Sitzungs-IDs, Anmeldedaten, Seiteninhalten usw.] Wenn es dem Angreifer gelingt, die Schwachstelle auszunutzen, kann er die Anmeldedaten des Benutzers stehlen, um sie später wieder zu verwenden oder zu analysieren. [Forceful Browsing] Wenn der Angreifer auf die aktuelle Anwendung oder eine andere Anwendung abzielt (durch CSRF-Schwachstellen), führt der Benutzer die Angriffe aus, ohne sich dessen bewusst zu sein. Diese Angriffe zielen meist auf Fehler in der Anwendungslogik ab, können aber auch dazu verwendet werden, einen weitreichenden Angriff gegen eine bestimmte Website im aktuellen Netzwerk des Benutzers (Internet oder nicht) zu starten. (Content Spoofing) Durch Manipulation des Inhalts zielt der Angreifer auf die Informationen ab, die der Benutzer von der Website erhalten möchte. |
Sehr hoch |
| 85 |
AJAX-Footprinting
Dieser Angriff nutzt die häufigen Client-Server-Roundtrips in Ajax-Konversationen, um ein System zu scannen. Ajax eröffnet zwar nicht per se neue Schwachstellen, optimiert sie aber aus Sicht des Angreifers. Ein üblicher erster Schritt für einen Angreifer ist die Erstellung eines Footprints der Zielumgebung, um zu verstehen, welche Angriffe funktionieren werden. Da das Footprinting auf einer Aufzählung beruht, kann ein Angreifer aufgrund des für Ajax-Anwendungen typischen Konversationsmusters aus schnellen, mehrfachen Anfragen und Antworten nach vielen Schwachstellen, bekannten Ports, Netzwerkstandorten usw. suchen. Das durch Ajax-Fingerprinting gewonnene Wissen kann zur Unterstützung anderer Angriffe wie XSS verwendet werden. [Mit Hilfe eines Browsers oder eines automatisierten Tools sendet ein Angreifer Anfragen an eine Webseite und zeichnet die empfangene HTML-Antwort auf. Die Angreifer analysieren dann den HTML-Code, um alle bekannten zugrunde liegenden JavaScript-Architekturen zu identifizieren. Dies kann dabei helfen, öffentlich bekannte Schwachstellen der Webseite zuzuordnen, und es kann dem Angreifer auch helfen, die Anwendungsarchitektur und die innere Funktionsweise eines Systems zu erraten. |
Niedrig |
MITRE
Sherlock® flash
Machen Sie mit wenigen Klicks ein Foto von Ihrem Computernetzwerk !
Mit der Sherlock® flash Audit-Lösung können Sie ein Audit durchführen, um die Sicherheit Ihres Computerbestands zu erhöhen. Scannen Sie Ihre physischen und virtuellen Geräte auf Schwachstellen. Planung von Patches nach Priorität und verfügbarer Zeit. Detaillierte und intuitive Berichte.
Entdecke dieses Angebot
