Neu Shop SQL-Injection Sicherheitslücke - Patch drauf und gut ist? Sonst keine Maßnahmen?

[JohnFrea]

Moin,

wir hattn ja in letzer Zeit ein paar mal Sicherheitslücken dieser Art. Bisher war der Rat "Patch drauf, wird bisher nicht ausgenutzt, alles schöni". Aber ist dem so? Theoretisch genügen doch die paar Stunden zwischen veröffentlichung des Patches und Einspielen aus, um die Lücke auszunutzen.
Und wenn ich das richtig verstehe, bedeutet SQL Injection nichts anderes als Vollzugriff auf den Shop. Neuen Adminuser anlegen, weitere Sicherheitslücken aufmachen, indem z.B. in eine Artikelbeschreibung Code zum Nachladen von Lücken eingebracht wird. Oder sehe ich das falsch?

Was sind denn Eure Methoden um zu prüfen, ob da nicht bereits etwas im Shop gelaufen ist? Ich finde, von JTL kommt da zu wenig Hilfe bzw. gar keine.

Und wieso bekommt JTL die SQL-Injections nicht in den Griff? Gibts da keine Tests für, die mal das ganze PHP durchtesten?!?

John

 

[Verkäuferlein]

Und wieso bekommt JTL die SQL-Injections nicht in den Griff? Gibts da keine Tests für, die mal das ganze PHP durchtesten?!?

Scheinbar laufen ja derartige Tests, sonst würde es die Fixes ja nicht geben, ohne dass es ein Ausnutzen der Sicherheitslücke gab.

Aber grundsätzlich lässt die Häufigkeit natürlich schon gewisse Bauchschmerzen aufkommen, da man natürlich nicht weiß, wieviele derartige Lücken noch (zumindest von JTL) unentdeckt schlummern und vielleicht auch bereits unbemerkt ausgenutzt werden um Daten abzugreifen, etc. pp.

Aber meistens laufen derartige Angriffe ja automatisiert, so dass man vieles schon durch kleine Veränderungen ins Leere laufen lassen kann.

Daher wäre es vielleicht auch ganz gut, wenn man den Link für den Admin-Zugang selber festlegen könnte, dieser also nicht pauschal in allen JTL-Shops identisch ist. Ggf. kann man diesen auch noch zusätzlich per Verzeichnisschutz sichern.

Aber bei einem Vollzugriff auf die DB hilft das ja auch nur gegen einen Teil des Problems.

Ansonsten gibt es ja im Gambio z.B. sowas wie den GProtector, in den JTL- Shop habe ich mich noch nicht soweit eingearbeitet, um zu erkennen, ob es dort ähnliche Funktionalitäten gibt.

 

[elevennerds.de]

Früher hat JTL solche Bugs direkt vor Veröffentlichung im Hosting von JTL gepatcht, jetzt jedoch nicht? Dutzende Shops sind derzeit angreifbar...

 

[mh1]

Der Thread hört sich an, wie wenn JTL hier was vermurkst. Aber ist es nicht so dass SQL-Injections grundsätzlich der Fluch fast jeder datengesteuerten Web-App sind?
Ich kenne den JTL Shop nicht, aber sind die Sicherheitslücken denn nicht eher in den verwendeten Komponenten (Data-Mapper und so), als in dem von JTL geschrieben Code? 🤔

 

[elevennerds.de]

grundsätzlich der Fluch fast jeder datengesteuerten Web-App sind

Falsche Annahme. Seit dem es PDO gibt, kann es auch keine SQL-Injections mehr geben. Nur wenn man sich seinen SQL selbst zusammenpopelt, ist eine solche Lücke möglich. Und genau das macht JTL in der Shop-Software...

 

[mh1]

Falsche Annahme. Seit dem es PDO gibt, kann es auch keine SQL-Injections mehr geben.

So ganz falsch auch wieder nicht. Es wird ja nicht jede datengesteuerte Web-App mit PHP gebastelt

wenn man sich seinen SQL selbst zusammenpopelt, ist eine solche Lücke möglich. Und genau das macht JTL in der Shop-Software...

Okay, das ist natürlich ein Argument. Ich kenne ja die JTL Shop Software nicht.

 

[mvh]

Moin.
Dieser Patch ist eine Vorbeugung, konkret geht es um ein Modul (io.php), eine Funktion getArticleByVariations, und eine Konvertierung, genauer gesagt Casting, zu einer Ganzzahl.
Diesen "Fehler" auszunutzen ist sehr schwer, und ja es gibt spezielle Tests für PHP/MySQL, die solche Fehler finden, und genauer deswegen haben wir jetzt dieses Hotfix.
Das ist kein gravierender Fehler und kann JEDEM passieren.

Seit dem es PDO gibt, kann es auch keine SQL-Injections mehr geben.

PDO ist langsam und angreifbar, z.B. s. https://stackoverflow.com/questions...-with-sql-injection-and-why-i-should-use-this
JTL hat "eigene" Bibliothek (mit-)entwickelt und diese wird ziemlich erfolgreich verwendet. Der Fehler hat aber nichts damit zu tun.

 

[elevennerds.de]

JTL hat "eigene" Bibliothek (mit-)entwickelt und diese wird ziemlich erfolgreich verwendet.

Das macht es ja noch schlimmer. Warum hat JTL dann nicht seine eigene Bibliothek benutzt?

PDO ist langsam und angreifbar,

Du liest nur Überschriften?

To avoid this type of vulnerability, use mysql_real_escape_string(), prepared statements, or any of the major database abstraction libraries.

 

[mvh]

Das macht es ja noch schlimmer. Warum hat JTL dann nicht seine eigene Bibliothek benutzt?

Weil sie eigene Funktionen seit "Ewigkeiten" im Shop nutzen, diese basiert je nach Version/Einstellung/Wunsch auf PDO/mysqli/usw.
PDO ist nichts anderes als ein Meta-Layer zwischen Datenbanken/Datenbank-Versionen/etc.
Wenn ich aber eine eigene Bibliothek schon habe, warum auch nicht nutzen ? Ich kann auch meine Funktionen als PDO-Aufruf "kapseln".

Du liest nur Überschriften?

Nein, ich programmiere auch manchmal . PDO ist einfacher zu benutzen und NiceDB "von" JTL
"basiert" zumindest aktuelle Shop 4 zum Teil auf PDO-Bibliothek (s. class.core.NiceDB.php), was wie dieses Beispiel zeigt, nicht vor SQL Injections schützt.
Aber PDO ist langsamer, weil es einen "zusätzlichen" Layer braucht und manchmal "unflexibel", dafür aber auch einfacher zu erlernen.
Der Fehler hat NICHTS mit magic_quotes, escape_strings, etc. zu tun. Man sollte keine pauschale Aussagen machen, einfach den Code vergleichen.

 

[elevennerds.de]

was wie dieses Beispiel zeigt, nicht vor SQL Injections schützt.

Schau nochmal in den Patch, wenn Du programmieren kannst.

Aber PDO ist langsamer

Ist es nicht. Der Mysql-Treiber besteht aus den Funktionen, die PDO nutzt.

 

[MHillmann]

Hallo,

ein paar Antworten zum ersten Beitrag von John und zum Problem im Hosting:

Im Hosting gab es Probleme beim Einspielen der Patches. Diese wurden aber mittlerweile behoben. Alle Hostingkunden haben dazu einen Newsletter mit genaueren Infos erhalten.

Zur Lücke selbst: Da es sich hier um einen Angriff per POST-Request handelt, ist das leider in üblich konfigurierten Access-Logs nicht prüfbar.
Im Hosting haben wir diverse Monitorings die keinerlei verdächtige Aktivitäten aufzeigen. Wir glauben daher weiterhin, dass hier keine Ausnutzung stattfand. Diesbezüglich eine 100%ige Gewissheit zu bekommen, ist in diesem Fall leider nur sehr schwer.
Zwei Dinge die man dennoch prüfen kann:
- das Systemlog auf verdächtige SQL-Fehler prüfen (ab Shop5)
- prüfen ob unbekannte Admin-Accounts angelegt sind oder waren. Macht z.B. tadminlogin.kAdminlogin einen Sprung, wenn man jetzt einen neuen Account anlegt (vorausgesetzt man hatte nicht zuletzt selbst einen Account angelegt und gelöscht)

Viele Grüße
Michael

 

[Verkäuferlein]

Der Thread hört sich an, wie wenn JTL hier was vermurkst.

Hm, nö, aus meiner Sicht eher konstruktiv, sorgenvoll.

Ich glaube keiner von uns möchte gerne, dass sein Shop gehacked wird oder Daten abgegriffen werden.
Und dann ist es ja ganz gut, wenn man sich Gedanken darüber macht, wie man mit entsprechenden Probleme umgehen kann, sich austauscht und vielleicht auch Lösungen findet.

Eine wirkliche Lösung gibt es ja auch nicht, nur die Möglichkeit Wahrscheinlichkeiten zu senken.
Meistens sind es ja keine gezielten Angriffe und bei standardisierten Systemen ist es natürlich so, dass eine Lücke viele betrifft und ein Angriff wahrscheinlich ist.

Bei individuellen Systemen ist die Wahrscheinlichkeit geringer, dass nach Lücken (mit großem Aufwand) gesucht wird, diese gefunden und ausgenutzt werden.
Das mit dem Finden gilt allerdings auch für die "gute Seite der Macht", also ist gleichzeitig die Wahrscheinlichkeit größer, dass Lücken vorhanden sind.

Hat wie alles immer Vor- und Nachteile.

Das ist kein gravierender Fehler und kann JEDEM passieren.

Klar, das Grundproblem ist ja leider immer, dass der "Angreifer" nur eine Lücke / einen Fehler finden muss und der "Verteidiger" alle.