Neu Ich fühle mich unsicher!

intrinsicforce

Sehr aktives Mitglied
4. Oktober 2015
673
101
Ich denke bei der Wawi und dem Shop würde die Statistik ähnlich aussehen (siehe Bild nachfolgend), aber ich bezweifle stark dass JTL die Kapazitäten hat. Wenn ich mir die täglichen Angriffsversuche auf meine Server ansehe dürfte es nur eine Frage der Zeit sein bis die standard vulnscans für Wordpress u. Co sich in eine spezialisierte Richtung drehen. Die Datensätze von der Wawi DB und Shop sind sehr wertvoll auf dem ein oder anderen Markt im "dunkeln".

32190.png
https://x.com/hlntnr/status/2052479493801975987
https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/

Tick, tock, motherf***er
 

intrinsicforce

Sehr aktives Mitglied
4. Oktober 2015
673
101
Das ist wohl wahr. Nur eine von den besonders tief hängenden Früchten will ich nicht sein.

Man wird sich vermutlich damit abfinden müssen.
Dass jeder ohne tiefgreifende Computerkenntnisse sich irgendwann die Daten eines beliebigen JTL-Shops komplett ziehen kann? Damit werde ich mich garantiert nicht abfinden.
 

NoOne

Sehr aktives Mitglied
16. März 2024
635
218
Dass jeder ohne tiefgreifende Computerkenntnisse sich irgendwann die Daten eines beliebigen JTL-Shops komplett ziehen kann? Damit werde ich mich garantiert nicht abfinden.
Das Problem daran ist: KIs sind nicht "jeder ohne tiefgreifende Computerkenntnisse". Wenn man die entsprechend trainiert, dann sind das im Gegenteil hoch spezialisierte Cybersecurity Tools, die ihre Möglichkeiten auch zum Einbrechen nutzen können. Das wird ein klassisches Katz-und-Maus-Spiel.
 

SebiW

Sehr aktives Mitglied
2. September 2015
3.090
1.615
Es gibt genug Alternativen am Markt. Wenn Du kein Vertrauen in die Softwaresicherheit von JTL, insbesondere dem JTL Shop, hast - dann würde ich über einen Wechsel nachdenken.
Andersrum gilt aber auch: Der JTL Shop ist vergleichsweise einfach aufgebaut. Shopware, Magento etc haben eine deutlich größere Codebasis mit entsprechenden Angriffsmöglichkeiten. Auch die erheblich größere Verbreitung macht sie als Ziel natürlich attraktiver.

Die großen Attacken sind so oder so weniger auf die Shopsoftware selbst als auf den Unterbau, also Apache / Nginx, Linux etc zu erwarten. Linux hat in den letzten Wochen ja schon drei extrem hoch eingestufte CVEs gehabt. Wir haben den Kernel in nemm Jahr sonst nicht so oft updaten müssen wie in den letzten Wochen ;)

Und wie NoOne schreibt, es wird auf ein Katz-und-Maus-Spiel hinauslaufen. Automatisierte Systeme zur Verteidigung, automatisierte Angriffe. Im Endeffekt auch nicht anders als in der Vergangenheit. Für viele kleine Betriebe werden SaaS Lösungen unumgänglich werden, so wenig mir das gefällt. JTL ist hier tatsächlich in einer schwierigen Situation: Zu klein um internationale Toptalente anzuziehen und entsprechend im vorderen Feld der Entwicklung mitzuspielen, zu groß um für die entsprechenden Angreifer kein attraktives Ziel zu sein.
 

hula1499

Sehr aktives Mitglied
22. Juni 2011
5.401
1.325
zu groß um für die entsprechenden Angreifer kein attraktives Ziel zu sein.
Siehst du das wirklich so?

Screenshot 2026-05-11 092647.png
BuiltWith ist gut für technografische Reichweite, aber als „echte aktive Shops“ tendenziell zu breit.


Screenshot 2026-05-11 092818.png

Screenshot 2026-05-11 092906.png
*Wappalyzer gibt nur Prozentanteile aus: Deutschland 89 %, Schweiz 2 %, Österreich 2 %. Daraus ergeben sich nur grobe Näherungen, keine harten Länderzahlen.

EU / Europa im Vergleich​

Für EU-Vergleichszahlen ist BuiltWith brauchbar, aber methodisch breiter als ShopRank/Store Leads. Nach BuiltWith liegt JTL- Shop in der EU bei 11.424 erkannten Live-Websites. Vergleich: Shopify 676.798, WooCommerce Checkout 461.573, Magento 32.055, Shopware 13.908, Gambio 7.991.

Das heißt: In der EU ist JTL-Shop klar eine DACH-Speziallösung, nicht international breit.
Gegen Shopify/WooCommerce ist JTL winzig.

Saubere Schlussfolgerung​


  1. Offizielle exakte Zahl: nicht öffentlich gefunden.
  2. Realistisch aktive JTL-Shops weltweit: ca. 9.000.
  3. Realistisch aktive JTL-Shops in DACH: ca. 8.000.
  4. Deutschland trägt den Markt fast allein: je nach Quelle rund 74–89 % aller JTL-Shops.
  5. JTL ist in Deutschland relevant, aber nicht marktführend: deutlich hinter Shopify, WooCommerce und Shopware; ungefähr im Bereich Magento/ePages/Wix; stärker als Gambio/PrestaShop im deutschen ShopRank-Vergleich.
  6. International/EU außerhalb DACH: sehr schwach. Die nicht-deutschsprachige EU-Präsenz liegt nur im niedrigen dreistelligen bis kleinen vierstelligen Bereich.
Da hier verschiedene Quellenansätze genutzt wurden, sollte dies - eigentlich - schon einen ungefähren Überblick geben (natürlich sind das sicher keine 100% korrekten Daten - keine davon).

Quellen sind bereits in den Screens angegeben.


Die großen Attacken sind so oder so weniger auf die Shopsoftware selbst als auf den Unterbau, also Apache / Nginx, Linux etc zu erwarten. Linux hat in den letzten Wochen ja schon drei extrem hoch eingestufte CVEs gehabt. Wir haben den Kernel in nemm Jahr sonst nicht so oft updaten müssen wie in den letzten Wochen
Gabs überhaupt schon mal gezielte Angriffe auf den JTL Shop? Kann mich nicht daran erinnern. Das liegt aber nicht (nur) an dem tollem JTL Shop, sondern einfach (auch) an der Verbreitung.
Aus dieser Grund können wir froh sein, das JTL internationale keinerlei Bedeutung hat und wir - bis heute - von gezielten Angriffen auf den JTL Shop verschont wurden.

Was jedoch klar sein sollte/müsste:
Sollte es zu gezielten Angriffen auf JTL kommen (nicht linux, apache, php.... sondern wirklich auf JTL Shops) gibts garantiert bei JTL fähige Köpfe, die dieses Problem (Sicherheitsaspekte) relativ flott lösen könnten und auch würden.
Die Chance, das all unsere JTL Shops verseucht für Wochen/Monate im Netz stehen, sehe ich persönlich gegen 0 (sofern erkannt).
 
  • Gefällt mir
Reaktionen: Shopworker.de

intrinsicforce

Sehr aktives Mitglied
4. Oktober 2015
673
101
Das Problem daran ist: KIs sind nicht "jeder ohne tiefgreifende Computerkenntnisse". Wenn man die entsprechend trainiert, dann sind das im Gegenteil hoch spezialisierte Cybersecurity Tools, die ihre Möglichkeiten auch zum Einbrechen nutzen können. Das wird ein klassisches Katz-und-Maus-Spiel.
Ich sehe (noch) kein Hindernis für einen "Geschäftsmann" eine auf Angriff trainierte LLM / KI halbwegs öffentlich zu betreiben und gegen etwas Entgelt in Form von Crypto-Tokens auch dem Laien seine Dienste anzubieten
 

SebiW

Sehr aktives Mitglied
2. September 2015
3.090
1.615
@hula1499 ja Angriffe gab es schon in der Vergangenheit, damals primär auf Shop 4. JTL Shop ist mit 10k Installationen garantiert groß genug um ein attraktives Ziel zu sein. Wir reden hier sicher über dreistellige Millionenbeträge die über das System laufen. Angriffe werden natürlich dadurch attraktiver, dass sie mit AI Unterstützung erheblich vereinfacht werden.

JTL hat anders als Shopware (mit dem Security Plugin) und Shopify (zentral gesteuerte Instanzen), Magento (Security Suite) etc auch das grundlegende Problem, dass viele ältere Versionen im Netz hängen dürften, für die es außer einem Major Upgrade keinen Absicherungsweg gibt. Es laufen ja sogar noch diverse JTL 4 Shops...

Kurz: JTL-Shop ist ganz sicher ein attraktives Ziel. JTL hat, verglichen mit großen Shopsystemen, vergleichsweise wenige Programmierer, die Nutzerkohorte sind primär KMUs mit im Zweifel überschaubarer IT Kompetenz und Deutschland ist nach USA, GB und Israel als Ziel auf Platz vier der weltweiten Cyberangriffe.
 

NoOne

Sehr aktives Mitglied
16. März 2024
635
218
Ich sehe (noch) kein Hindernis für einen "Geschäftsmann" eine auf Angriff trainierte LLM / KI halbwegs öffentlich zu betreiben und gegen etwas Entgelt in Form von Crypto-Tokens auch dem Laien seine Dienste anzubieten
Das wird sich auch nicht ändern, sofern sich die Gesetze nicht ändern. Hat im übrigen auch nichts mit JTL direkt zu tun, das jemand so eine KI anbieten würde. Und selbst wenn die Gesetze sich ändern, dann wird sich das auch nur moderat ändern, weil es irgendwo ein Briefkastenkonstrukt geben wird das die Inhaber solcher Tools verschleiert.

Das betrifft auch nicht nur JTL, sondern alle. Ein Großteil der Malware heutzutage z. B. ist schon aus dem Baukasten. Jedes Skript-Kiddie kann sich da was zusammenbasteln. Selbst wenn sämtliche Software von JTL, utopischer Weise, absolut sicher wäre, kein Einfalltor bietet, und jeder wie durch ein Wunder auf dem aktuellsten Stand wäre, ist da immer noch das ganze drumherum. Im Fall vom Shop: Hosting, PHP, OS vom Hosting (also Linux in den meisten Fällen), Datenbankserver, Backend vom Hosting, sämtliche genutzten Extensions, (S)FTP, und deine eigenen Rechner mit allem, was darauf installiert ist. Und ggf. bedingt auch VPN/WLAN/LAN.

Edit: Du wolltest vermutlich eher darauf hinaus das jeder diese KI verwenden kann. Natürlich. Im Prinzip kann auch jeder eine KI trainieren, sofern er das Wissen dafür irgendwo rauskramt. Ich meinte eher damit, das es das gleiche ist, als würde der entsprechende Täter einen Cybersecurity Experten dafür bezahlen und einsetzen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: intrinsicforce

SebiW

Sehr aktives Mitglied
2. September 2015
3.090
1.615
Man muss hier auch ein wenig die Kirche im Dorf lassen. AI hat sich erheblich weiterentwickelt, aber wir reden hier auch über Expertensysteme, ähnlich wie im Medizinbereich. Ein generisches LLM hat nicht von Haus aus die entsprechenden Fertigkeiten. Und ein generischer User wird auch aus diesen Expertensystemen nicht die gleiche Effizienz herausziehen. Der Prompt ist ja nicht "Chatgpt greif mal folgenden Webshop an - mach keine Fehler".

Die Systeme werden von den bisherigen Schwarzmarktgruppen genutzt werden um ihr Portfolio zu vergrößern. Das typische Skritpkiddie wird weiter deren Kunde bleiben.
 

itratosTeam

Sehr aktives Mitglied
19. April 2007
712
88
Bamberg
Was jedoch klar sein sollte/müsste:
Sollte es zu gezielten Angriffen auf JTL kommen (nicht linux, apache, php.... sondern wirklich auf JTL Shops) gibts garantiert bei JTL fähige Köpfe, die dieses Problem (Sicherheitsaspekte) relativ flott lösen könnten und auch würden.
Die Chance, das all unsere JTL Shops verseucht für Wochen/Monate im Netz stehen, sehe ich persönlich gegen 0 (sofern erkannt).

@hula1499 also das kann ich so nicht bestätigen.
Ich machte seinerzeit diesen Post weil mir die Art wie Hinweise bearbeitet werden etwas komisch vorgekommen ist https://forum.jtl-software.de/threads/sicherheitsluecke-shop-9151-vom-03-11-2025.245623/

Zwischenzeitlich haben wir eine automatisierte Lösung mit über 100 Prüfungen und Auswertungen, die wir, wie ich bereits in dem anderen Post mitteilte, allen JTL-Kunden kostenlos bereitstellen.
Ich hätte mir gewünscht das der eine oder andere Servicepartner mit uns am gleichen Strang zieht, da ein einfaches Security Plugin, was der Shop Betreiber einmal die Woche manuell startet, sofern er daran denkt, nicht im Ansatz ausreicht.

Mit einem JTL Server der im Web erreichbar ist ist es ähnlich. viele denken das die einmalige Einstellung der Firewall ausreichend ist, unsere security2go Lösung bestätigt das Gegenteil.

Wenn jemand Interesse hat und Sicherheit ernst nimmt dann kann er sich gerne melden. Kollegen, die sich beteiligen wollen, sind auch Willkommen.

Für uns ist es wichtig Daten zu sammeln und das geht nur wenn sich viele Shop Betreiber beteiligen, nur so erkennt man Muster von Angriffen und kann JTL helfen Lücken zu schließen.
Aktuell kann JTL nur reagieren, sofern kein Entwickler selbst eine Schwachstelle erkennt - aus dem Grund bitte ich erneut um die Mitwirkung.
 

NoOne

Sehr aktives Mitglied
16. März 2024
635
218
Dann stell das doch mal hier zur Verfügung. War die aktuelle Sicherheitslücke dabei? Statische Codeanalyse durch KI ist relativ wertlos und macht unnötig Arbeit. Shop-9151 war offenbar ein bei Anforderung eines Passworts nicht zurückgesetzter Link, sondern der blieb die vollen 24 Stunden gültig. Das würde ich als low bis medium einstufen und auch nicht nur ansatzweise kritisch. Weil dafür die alte E-Mail-Adresse kompromittiert sein muss *und* der zurücksetzen Link weniger als 24 Stunden vor dem zurücksetzen des Passworts durch den Kunden generiert werden. Darüberhinaus müsste der Angreifer die neue E-Mail zum einloggen kennen. Das sind ganz schön viele Voraussetzungen. Wenn ein Angreifer beide E-Mails kennt und wohlmöglich auch zugang zu beiden Konten hat, dann nutzt auch ein ungültig machen des zurücksetzen links nichts. Ärgerlich und oversight, aber keine wirklich kritische Sicherheitslücke.
 

itratosTeam

Sehr aktives Mitglied
19. April 2007
712
88
Bamberg
Dann stell das doch mal hier zur Verfügung. War die aktuelle Sicherheitslücke dabei? Statische Codeanalyse durch KI ist relativ wertlos und macht unnötig Arbeit. Shop-9151 war offenbar ein bei Anforderung eines Passworts nicht zurückgesetzter Link, sondern der blieb die vollen 24 Stunden gültig. Das würde ich als low bis medium einstufen und auch nicht nur ansatzweise kritisch. Weil dafür die alte E-Mail-Adresse kompromittiert sein muss *und* der zurücksetzen Link weniger als 24 Stunden vor dem zurücksetzen des Passworts durch den Kunden generiert werden. Darüberhinaus müsste der Angreifer die neue E-Mail zum einloggen kennen. Das sind ganz schön viele Voraussetzungen. Wenn ein Angreifer beide E-Mails kennt und wohlmöglich auch zugang zu beiden Konten hat, dann nutzt auch ein ungültig machen des zurücksetzen links nichts. Ärgerlich und oversight, aber keine wirklich kritische Sicherheitslücke.
Hallo @NoOne

ich habe jtl über 10 Hinweise gesendet u.a. auch zu den Plugins die ich in dem Ticket nannte, des weiteren war ich mit weiteren Plugin Herstellern in Kontakt und habe sie direkt über Auffälligkeiten im Code informiert.

NEIN: Unsere Lösung prüft nicht nur einfach via KI den Code, via KI prüfen wir das was unsere Security Lösung erfasst - weil eine manuelle Prüfung zu lange dauert bzw. irgendwann eh keiner mehr macht.

Die meisten Projekte werden nicht wegen einer vermeintlichen Sicherheitslücke gehackt, sondern weil man dem Hacker die Möglichkeit gibt diese zu testen.
Im Anhang ein aktuelles Beispiel: Wenn man einen Versuch erkennt, dann kann man reagieren und auch den Angriff analysieren, um die Sicherheitslücke zu finden. Was wir aber sehen, dass fast alle Shop im Blindflug unterwegs sind und nur sehen ob Bestellungen kommen, oder nicht.

Ich habe mich schon oft mit IT Forensikern unterhalten und stellte fest das wir am Ende der Gespräche immer zum gleichen Ergebnis gekommen sind. Die Früherkennung ist das A+O und nicht erst, wenn der Hersteller ein Security Fix bereitstellt.
Ähnlich ist es wenn man wegen einer scheren Kopf Verletzung im Krankenhaus sitzt und den Arzt fragt, wie ist den das passiert und er sagt, hätten Sie beim Fahrrad fahren einen Helm aufgesetzt dann wären Sie jetzt nicht hier.

Die meisten Shop Betreiber, so stelle ich das zumindest oft fest, denken nicht an Prävention, oder sie denken das es unverhältnismäßig teuer ist und hoffen das nichts passiert. Manche denken auch einfach das es nur große Anbieter erwischt, aber nicht den kleinen Backshop mit 30 Bestellungen im Monat.

Der Aufwand zu reagieren, wenn das Kind in den Brunnen gefallen ist, ist dann oft so hoch das der Händler sein Gewerbe einstellt.
Ich bin der Meinung das etwas Sicherheit angebracht ist und wirklich nicht viel Geld kostet u.a. weil KI vieles einfacher macht, was vorher manuell geprüft werden musste.

Das gleiche Denken sehen wir auch bei den JTL-Servern die öffentlich im Netz gehostet werden.
Wir erfassen hier oft 2000 - 10000 Angriffsversuche in wenigen Minuten von der gleichen IP, oder oft verteilt auf mind. 3 - 10 versch. IP's
Wenn man sich hier nur auf die vor 2 Jahren aktivierte Firewall von Windows verlässt, na dann braucht man sich nicht wundern.
Deshalb haben wir auch hier eine automatische Lösung die den Angriff erkennt und die IP sofort in der Firewall sperrt. Der jeweilig Angreifer wird in dem Fall schon beim ersten Versuch erkannt und gebannt :)

Zurück zu unserer JTL-Shop Lösung:

Wir bereiten gerade alles weitere vor und werden diese Lösung dann über unseren GitHub Account bereitstellen, damit Kollegen eigenes Wissen beisteuern können - da wir uns selbst nicht als die Quelle des Wissens sehen und eine derartige Lösung nur durch das Wissen vieler Köpfe gute Dienste leisten kann.

PS: An der Stelle möchte ich noch auf folgendes Hinweisen, da mir das schon seit Jahren Bauchschmerzen bereitet. Ich verstehe nicht warum Plugins verschlüsselt werden müssen und bitte jeden der Plugins entwickelt u.a. Zahlungsarten Plugins, dies zu überdenken. Ich kann es verstehen das der eine oder andere das eigene Wissen geschützt sehen will, aber ganz ehrlich, wenn ein anderer Programmiere gezwungen ist Code zu kopieren, weil er es selbst nicht hinbekommt, dann soll er das doch machen. Ich habe damit kein Problem, weil es entweder von Vorteil ist die richtigen Funktionen zu nutzen.

Wenn es doch nur um das klauen von Ideen geht, dann soll er oder sie doch klauen, wenn das arme Würstchen das nötig hat.

Mein Hinweis trifft hier vor allem Plugin Entwickler die Plugins für Zahlungsarten entwickeln und diese, aus meiner Sicht unnötigerweise verschlüsseln, was uns bzw. dem Shop Betreiber nur unnötig das Leben schwer macht. Die Verschlüsselung entzieht dem Shop Betreiber jegliche Möglichkeit seine Pflichten gemäß PCI DSS zu befolgen, was zu einem unnötigen Haftungsrisiko führt.
 

Anhänge

  • Bildschirmfoto vom 2026-07-19 08-53-34.png
    Bildschirmfoto vom 2026-07-19 08-53-34.png
    142,1 KB · Aufrufe: 17

NoOne

Sehr aktives Mitglied
16. März 2024
635
218
ich habe jtl über 10 Hinweise gesendet u.a. auch zu den Plugins die ich in dem Ticket nannte, des weiteren war ich mit weiteren Plugin Herstellern in Kontakt und habe sie direkt über Auffälligkeiten im Code informiert.
Ja, das weiß ich wohl noch. Und mehr als die Hälfte davon war sinnlos oder vollkommen überzogen. Die Sache mit den Zip-Dateien z. B. Die Schwachstelle wurde schon mit PHP 7 gefixt. Zumindest die Beispiel-Textdateien die du im Forum geteilt hattest. Unnötige Panikmache.

Ich habe mich schon oft mit IT Forensikern unterhalten und stellte fest das wir am Ende der Gespräche immer zum gleichen Ergebnis gekommen sind. Die Früherkennung ist das A+O und nicht erst, wenn der Hersteller ein Security Fix bereitstellt.
Ähnlich ist es wenn man wegen einer scheren Kopf Verletzung im Krankenhaus sitzt und den Arzt fragt, wie ist den das passiert und er sagt, hätten Sie beim Fahrrad fahren einen Helm aufgesetzt dann wären Sie jetzt nicht hier.

Die meisten Shop Betreiber, so stelle ich das zumindest oft fest, denken nicht an Prävention, oder sie denken das es unverhältnismäßig teuer ist und hoffen das nichts passiert. Manche denken auch einfach das es nur große Anbieter erwischt, aber nicht den kleinen Backshop mit 30 Bestellungen im Monat.

Der Aufwand zu reagieren, wenn das Kind in den Brunnen gefallen ist, ist dann oft so hoch das der Händler sein Gewerbe einstellt.
Ich bin der Meinung das etwas Sicherheit angebracht ist und wirklich nicht viel Geld kostet u.a. weil KI vieles einfacher macht, was vorher manuell geprüft werden musste.

Das gleiche Denken sehen wir auch bei den JTL-Servern die öffentlich im Netz gehostet werden.
Wir erfassen hier oft 2000 - 10000 Angriffsversuche in wenigen Minuten von der gleichen IP, oder oft verteilt auf mind. 3 - 10 versch. IP's
Wenn man sich hier nur auf die vor 2 Jahren aktivierte Firewall von Windows verlässt, na dann braucht man sich nicht wundern.
Deshalb haben wir auch hier eine automatische Lösung die den Angriff erkennt und die IP sofort in der Firewall sperrt. Der jeweilig Angreifer wird in dem Fall schon beim ersten Versuch erkannt und gebannt :)
Das, was da im Screenshot zu erkennen ist, ist ein einfaches Abklopfen von Sicherheitslücken. Am PG_SLEEP erkennt man, dass das ein 08/15 check ist und kein gezielter Angriff, weil PG_SLEEP ein Befehl von PostgreSQL ist. JTL-Shop erfordert MySQL/Mariadb. Diese Art von versuch einer SQL-Injection ist was völlig Normales und alltägliches. Das direkt zu bannen ist praktisch eine Überreaktion und kommt Panikmache gleich. Im Kontext einer JTL-Shop Installation überhaupt die Windows-Firewall zu erwähnen, wo die meisten Webhoster Linux verwenden ist schon ein komischer Zug. Das lässt mich schon skeptisch werden. Außerdem sind das nicht zwingend Angriffe, sondern können auch Vulnerability Scanner sein.

PS: An der Stelle möchte ich noch auf folgendes Hinweisen, da mir das schon seit Jahren Bauchschmerzen bereitet. Ich verstehe nicht warum Plugins verschlüsselt werden müssen und bitte jeden der Plugins entwickelt u.a. Zahlungsarten Plugins, dies zu überdenken. Ich kann es verstehen das der eine oder andere das eigene Wissen geschützt sehen will, aber ganz ehrlich, wenn ein anderer Programmiere gezwungen ist Code zu kopieren, weil er es selbst nicht hinbekommt, dann soll er das doch machen. Ich habe damit kein Problem, weil es entweder von Vorteil ist die richtigen Funktionen zu nutzen.

Wenn es doch nur um das klauen von Ideen geht, dann soll er oder sie doch klauen, wenn das arme Würstchen das nötig hat.

Mein Hinweis trifft hier vor allem Plugin Entwickler die Plugins für Zahlungsarten entwickeln und diese, aus meiner Sicht unnötigerweise verschlüsseln, was uns bzw. dem Shop Betreiber nur unnötig das Leben schwer macht. Die Verschlüsselung entzieht dem Shop Betreiber jegliche Möglichkeit seine Pflichten gemäß PCI DSS zu befolgen, was zu einem unnötigen Haftungsrisiko führt.

PCI DSS verlangt keinen offenen Quellcode. Stimmt zwar das ein unabhängiges Security-Audit erschwert wird, aber da kannst du das halt vom Plugin-Anbieter anfordern, wenn das Plugin verschlüsselt oder obfuskiert ist. Du vergisst hier auch einen ganz wesentlichen Teil von PHP: PHP ist ohne Verschlüsselung oder Obfuskierung reiner Quellcode. Das heißt, ohne Verschlüsselung oder Obfuskierung kannst du deinen Code beinahe unmöglich vor Manipulation schützen, weil alle entsprechenden Schutzvorrichtungen geändert/auskommentiert werden könnten. Das wird erschwert. Immer noch nicht unmöglich, aber aufwändiger.

Das letzte Problem an der Sache: Ein Plugin das von 'innen' heraus überwacht ist schwierig. Das mag zwar sowas wie Sicherheitslücken abklopfen standhalten, aber einem gezielten Angriff höchstwahrscheinlich nicht. Hab ich Backend-Daten? Dann deaktivier ich das Plugin einfach. Hab ich FTP-Daten? Dann bennene ich das Verzeichnis um. Habe ich Datenbankdaten? Dann lösche ich den Eintrag aus der Datenbank. Dass du eine unbekannte bisher nicht entdeckte Sicherheitslücke präventiv abfängst (also tatsächlich Zero-Day) ist unwahrscheinlich. Das klappt nur, wenn das zufällig mit bekannten Mustern einhergeht. Dafür müsstest du die aber ebenfalls abfangen, bevor der Shop das verarbeitet. Die läuft nicht bequem in den Shoplog wie bei deiner beispielhaften SQL-Injection. Wenn die SQL-Injection funktioniert, dann kriegst du das nicht unbedingt mit, weil eine gültige Anweisung abgesetzt wird. Genau wie der erfolgreiche Angriff vermutlich nicht protokolliert wird.

Außerdem könnte ein Plugin zu der gleichen trügerischen Sicherheit wie dein Windows-Firewall Beispiel verleiten. Der Kunde könnte denken: Ich hab das Plugin, das meldet nichts, ich bin sicher.

Generell ist das Abfangen von verdächtigen Aufrufen eigentlich eher was für das Hosting selbst (Cloudflare/Link11 oder eine Web Application Firewall), weil das ggf. Auswirkungen auf das Security-Konzept des Hostings hat. Wenn ein Hostinganbieter beispielsweise automatisierte Sicherheitsprüfungen durchführt und dein Plugin daraufhin interne Scanner blockiert, kann das zu Fehlalarmen oder Konflikten mit bestehenden Sicherheitsprozessen führen.

Ich möchte dir das nicht unbedingt madig reden, aber einen möglichen Vulnerability-Scan sofort als Angriff abzutun (und anscheinend direkt die IP zu bannen), deine Aussage über die Windows-Firewall und deine vorigen Berichte die z. B. das Path Traversal von ZipArchive::extractTo() als hoch zu priorisierendes Sicherheitsproblem dargestellt hat (obwohl das bereits seit PHP 7.3, also seit ~7-8 Jahren gefixt ist, weil die Funktion seitdem absolute Pfade und sowas wie ../ komplett ignoriert) macht mich skeptisch.
 
  • Gefällt mir
Reaktionen: mvh