Sichere JTL-Shop-Plugins: Welche Risiken individuelle Erweiterungen vermeiden müssen

Warum Plugin-Sicherheit für den gesamten JTL-Shop relevant ist

Ein Plugin arbeitet innerhalb derselben technischen Umgebung wie der JTL-Shop und kann auf zentrale Daten und Prozesse zugreifen.

Abhängig von seiner Funktion kann ein Plugin Zugriff besitzen auf:

• Produktdaten
• Preise und Rabatte
• Kundenkonten
• Bestellungen
• Warenkorb und Checkout
• Formulardaten
• Dateien und Uploads
• externe API-Zugangsdaten
• administrative Einstellungen
• eigene Datenbanktabellen

Eine Schwachstelle kann dadurch Auswirkungen besitzen, die weit über die sichtbare Pluginfunktion hinausgehen. Besonders Erweiterungen in Warenkorb, Checkout, Kundenkonto und Backend müssen deshalb nach denselben Sicherheitsgrundsätzen entwickelt werden wie andere geschäftskritische Software.

Die wichtigsten Sicherheitsbereiche eines JTL-Shop-Plugins

Sicherheit entsteht nicht durch eine einzelne Maßnahme, sondern durch mehrere aufeinander abgestimmte Schutzebenen.

Sicherheit beginnt mit einer klaren Anforderungsanalyse

Vor der Entwicklung muss bekannt sein, welche Daten, Benutzer und Prozesse das Plugin berührt.

Zu klären sind:

• Wer darf die Funktion verwenden?
• Welche Daten werden gelesen?
• Welche Daten werden gespeichert oder verändert?
• Welche Aktionen sind geschäftskritisch?
• Welche externen Systeme werden angebunden?
• Welche personenbezogenen Daten werden verarbeitet?
• Welche Fehler oder Missbrauchsfälle sind denkbar?
• Welche Folgen hätte eine manipulierte Anfrage?

Erst wenn diese Punkte bekannt sind, lassen sich Berechtigungen, Validierungen und Protokolle passend planen.

Alle Benutzereingaben grundsätzlich als unsicher behandeln

Werte aus Formularen, URLs, Cookies, Dateien und Schnittstellen dürfen nicht ungeprüft verwendet werden.

Auch scheinbar harmlose Eingaben können manipuliert werden:

• Artikelnummern
• Mengen
• Preise
• Kundennummern
• Dateinamen
• E-Mail-Adressen
• Weiterleitungsziele
• Filterparameter
• API-Rückgaben

Die Prüfung muss serverseitig erfolgen. Eine Validierung im Browser verbessert die Bedienung, stellt aber keine ausreichende Sicherheitskontrolle dar.

Validierung und Bereinigung unterscheiden

Nicht jede unerwartete Eingabe sollte automatisch in einen vermeintlich gültigen Wert umgewandelt werden.

Eine Validierung prüft, ob ein Wert fachlich und technisch zulässig ist. Eine Bereinigung entfernt oder verändert unerwünschte Bestandteile.

Beispiele:

• Eine Mengenangabe muss eine zulässige positive Zahl sein.
• Eine E-Mail-Adresse muss ein gültiges Format besitzen.
• Eine Artikel-ID muss zu einem tatsächlich verfügbaren Artikel gehören.
• Eine Auswahl darf nur Werte aus einer vorgegebenen Liste enthalten.
• Ein Freitext muss vor der späteren Ausgabe sicher behandelt werden.

Ungültige Werte sollten abgelehnt und verständlich erklärt werden, wenn ihre automatische Änderung das fachliche Ergebnis verfälschen könnte.

Preise und Berechnungen serverseitig absichern

Dynamische Preisberechnungen gehören zu den besonders kritischen Pluginfunktionen.

Ein Plugin darf sich nicht darauf verlassen, dass ein im Browser berechneter Preis unverändert zurückgesendet wird.

Serverseitig erneut geprüft werden müssen:

• Produkt und Variante
• Menge
• Kundengruppe
• Preisregeln
• Rabatte
• Zuschläge
• Mindest- und Höchstwerte
• Steuerlogik
• Rundung

Der verbindliche Preis darf erst nach dieser Prüfung in den Warenkorb und die Bestellung übernommen werden.

Warenkorbwerte nicht ungeprüft übernehmen

Artikel, Mengen und individuelle Konfigurationen können zwischen Produktseite und Checkout verändert werden.

Das Plugin sollte bei relevanten Schritten erneut kontrollieren:

• Ist der Artikel noch verfügbar?
• Ist die gewählte Kombination weiterhin zulässig?
• Hat sich der Preis verändert?
• Ist der Benutzer weiterhin berechtigt?
• Gelten Mengen- oder Warenkorbgrenzen?
• Sind notwendige Zusatzangaben vollständig?

Eine einmalige Prüfung beim Öffnen der Produktseite reicht für einen späteren Bestellabschluss nicht aus.

Berechtigungen serverseitig kontrollieren

Das Ausblenden einer Funktion im Frontend ist keine ausreichende Zugriffskontrolle.

Ein Benutzer kann versuchen, eine URL oder Anfrage direkt aufzurufen. Deshalb muss jede geschützte Aktion serverseitig prüfen:

• Ist der Benutzer angemeldet?
• Besitzt er die richtige Kundengruppe oder Rolle?
• Darf er den betroffenen Datensatz sehen?
• Darf er die konkrete Aktion ausführen?
• Gehört der Auftrag oder Vorgang tatsächlich zu diesem Benutzer?

Diese Prüfung muss bei jedem relevanten Aufruf erneut erfolgen.

Backendrechte begrenzen

Nicht jeder Shopmitarbeiter benötigt Zugriff auf alle Pluginfunktionen.

Besonders geschützt werden sollten:

• API-Zugangsdaten
• Preis- und Berechnungsregeln
• Datenexporte
• Löschfunktionen
• Massenzuordnungen
• Sicherheits- und Protokolleinstellungen
• automatische Hintergrundprozesse

Rollen und Zuständigkeiten sollten so eng wie sinnvoll vergeben werden. Administratorrechte dürfen nicht zur Standardvoraussetzung für jede alltägliche Pluginbedienung werden.

Schutz vor ungewollten Fremdanfragen

Kritische Aktionen müssen sicherstellen, dass sie tatsächlich aus einer berechtigten Sitzung stammen.

Das betrifft beispielsweise:

• Änderung von Einstellungen
• Löschen von Daten
• Start von Importen
• Auslösen von E-Mails
• Ändern von Warenkorbwerten
• Ausführen administrativer Aktionen

Neben der Benutzerberechtigung sollte geprüft werden, ob die Anfrage zur aktuellen Sitzung gehört und über den vorgesehenen Weg ausgelöst wurde.

Datenbankabfragen sicher aufbauen

Benutzereingaben dürfen nicht direkt in SQL-Abfragen zusammengesetzt werden.

Sichere Datenbankverarbeitung umfasst:

• parametrisierte Abfragen
• klar definierte Datentypen
• Validierung von IDs und Grenzwerten
• begrenzte Ergebnismengen
• kontrollierte Transaktionen
• Fehlerbehandlung ohne Ausgabe interner Details

Besonders dynamische Sortierungen, Filter und Suchfelder dürfen nur auf ausdrücklich zugelassene Spalten und Werte zugreifen.

Eigene Plugin-Daten klar von Standarddaten trennen

Eigene Tabellen reduzieren Konflikte und erleichtern spätere Wartung.

Direkte Änderungen an JTL-Shop-Standardtabellen können:

• Updates erschweren
• andere Funktionen beeinflussen
• Datenintegrität gefährden
• Deinstallation und Sicherung komplizieren

Eigene Daten sollten über klar definierte Beziehungen mit Shopobjekten verknüpft werden. Dabei muss berücksichtigt werden, was geschieht, wenn ein Artikel, Kunde oder anderer Bezugsdatensatz gelöscht wird.

Transaktionen bei zusammenhängenden Änderungen verwenden

Mehrere Datenbankänderungen können gemeinsam einen fachlichen Vorgang bilden.

Wird beispielsweise eine Konfiguration gespeichert, ein Warenkorbwert erzeugt und ein Protokolleintrag angelegt, darf ein Fehler nicht zu einem nur teilweise gespeicherten Zustand führen.

Eine kontrollierte Transaktion kann sicherstellen, dass:

• alle notwendigen Schritte erfolgreich ausgeführt werden
• oder der gesamte Vorgang zurückgesetzt wird

Sichere Ausgabe im Frontend

Gespeicherte oder externe Inhalte dürfen nicht ungeprüft als HTML oder JavaScript ausgegeben werden.

Relevant sind unter anderem:

• Kundenkommentare
• Formulareingaben
• Produktattribute
• Dateinamen
• API-Antworten
• administrativ gepflegte Texte

Die Ausgabe muss zum jeweiligen Kontext passend behandelt werden. Text innerhalb von HTML benötigt eine andere Absicherung als ein Wert in einem Attribut, einer URL oder einem JavaScript-Kontext.

HTML-Inhalte nur gezielt zulassen

Manche Pluginfunktionen benötigen formatierbare Inhalte. Freies HTML erhöht jedoch das Risiko unerwünschten Codes.

Sinnvoll kann sein:

• nur definierte HTML-Elemente zuzulassen
• gefährliche Attribute zu entfernen
• aktive Skripte grundsätzlich zu blockieren
• Editorrechte auf vertrauenswürdige Benutzer zu begrenzen
• die Ausgabe erneut kontextabhängig zu prüfen

Datei-Uploads besonders streng prüfen

Uploadfunktionen gehören zu den sensibelsten Pluginbereichen.

Kontrolliert werden müssen:

• Dateigröße
• zulässige Dateitypen
• tatsächlicher Dateiinhalt
• Dateiname
• Speicherort
• Zugriffsrechte
• Anzahl der Uploads
• Verknüpfung zum richtigen Benutzer oder Vorgang

Die reine Prüfung der Dateiendung reicht nicht aus. Eine Datei kann anders benannt sein als ihr tatsächlicher Inhalt.

Uploadverzeichnis absichern

Hochgeladene Dateien sollten nicht unkontrolliert als ausführbare Inhalte erreichbar sein.

Je nach Zweck kann sinnvoll sein:

• Speicherung außerhalb öffentlich ausführbarer Verzeichnisse
• Vergabe zufälliger interner Dateinamen
• kontrollierte Auslieferung über eine berechtigte Anwendung
• Begrenzung der Dateigröße
• automatische Löschung nach definierten Fristen

Originaldateinamen können als Metadaten gespeichert werden, sollten aber nicht ungeprüft als tatsächlicher Serverdateiname verwendet werden.

Formulare gegen automatisierten Missbrauch schützen

Öffentliche Formulare können für Spam, Massenanfragen oder unnötige Serverlast missbraucht werden.

Je nach Risiko können eingesetzt werden:

• Rate-Limits
• zeitliche Begrenzungen
• Honeypot-Felder
• geeignete Captcha- oder Turnstile-Lösungen
• Bestätigungsverfahren
• Blockierung auffälliger Muster
• Protokollierung ohne unnötige personenbezogene Daten

Die Schutzmaßnahme sollte zum tatsächlichen Risiko passen und darf die Bedienung für echte Kunden nicht unnötig erschweren.

E-Mail-Versand begrenzen

Pluginformulare oder Benachrichtigungen dürfen nicht als offene Versandfunktion missbraucht werden können.

Zu prüfen sind:

• fest definierte oder kontrollierte Empfänger
• Begrenzung von Anhängen
• sichere Betreff- und Headerverarbeitung
• Rate-Limits
• Protokollierung wiederholter Fehler
• keine Ausgabe sensibler Inhalte in Fehlermeldungen

API-Schlüssel und Zugangsdaten schützen

Schnittstellen benötigen häufig Zugangsdaten, Tokens oder Zertifikate.

Diese Informationen dürfen nicht:

• im Frontend ausgegeben werden
• in JavaScript-Dateien stehen
• vollständig in Protokollen erscheinen
• unverschlüsselt exportiert werden
• für alle Backendbenutzer sichtbar sein
• direkt im öffentlichen Quellcode hinterlegt werden

Zugriff und Speicherung sollten sich nach der Sensibilität des jeweiligen Dienstes richten.

Zugangsdaten austauschbar halten

Ein API-Schlüssel kann ablaufen, kompromittiert werden oder durch einen neuen Zugang ersetzt werden müssen.

Das Plugin sollte deshalb:

• einen kontrollierten Austausch ermöglichen
• ungültige Zugangsdaten verständlich melden
• keine alten Schlüssel unnötig weiterverwenden
• kritische Fehler administrativ protokollieren
• nach einem Wechsel einen Verbindungstest erlauben

Externe API-Antworten ebenfalls prüfen

Daten eines angebundenen Systems dürfen nicht automatisch als korrekt und sicher gelten.

Geprüft werden sollten:

• HTTP-Status
• Datenformat
• Pflichtfelder
• Datentypen
• zulässige Werte
• unerwartet große Antworten
• Fehler- und Wartungsmeldungen

Eine API kann fehlerhafte, unvollständige oder veränderte Daten liefern. Das Plugin muss darauf vorbereitet sein, ohne den gesamten Shopprozess unkontrolliert zu beschädigen.

Webhooks sicher verifizieren

Manche Systeme senden Ereignisse aktiv an den Shop.

Dabei muss geprüft werden:

• Stammt die Anfrage tatsächlich vom erwarteten System?
• Ist die Signatur gültig?
• Wurde das Ereignis bereits verarbeitet?
• Ist der Zeitstempel plausibel?
• Ist die Nutzlast vollständig?
• Darf der Vorgang den betroffenen Datensatz verändern?

Ohne diese Kontrollen könnten fremde oder mehrfach gesendete Anfragen Bestellungen, Status oder Daten verändern.

Doppelte Übertragungen verhindern

Netzwerkfehler und Wiederholungsversuche können dazu führen, dass derselbe Vorgang mehrfach gesendet wird.

Kritisch ist dies beispielsweise bei:

• Bestellungen
• Zahlungen
• Gutschriften
• Versandmeldungen
• Bestandsänderungen
• E-Mail-Benachrichtigungen

Das Plugin sollte Vorgänge eindeutig kennzeichnen und bereits verarbeitete Übertragungen erkennen können.

Zeitüberschreitungen und Ausfälle begrenzen

Ein externer Dienst darf den gesamten Seitenaufbau nicht unbegrenzt blockieren.

Sinnvolle Maßnahmen sind abhängig von der Funktion:

• kurze und definierte Zeitüberschreitungen
• begrenzte Wiederholungsversuche
• Zwischenspeicherung
• asynchrone Verarbeitung
• Warteschlangen
• manuelle Wiederholung im Backend
• verständliche Ersatzmeldungen

Besonders externe API-Aufrufe auf Produkt- und Checkoutseiten benötigen eine kontrollierte Fehlerstrategie.

Personenbezogene Daten minimieren

Ein Plugin sollte nur Daten speichern, die für seine konkrete Funktion notwendig sind.

Vor jeder Speicherung sollte geklärt werden:

• Wofür wird der Wert benötigt?
• Wie lange muss er gespeichert bleiben?
• Wer darf ihn sehen?
• Kann er anonymisiert oder pseudonymisiert werden?
• Wie wird er gelöscht oder exportiert?
• Muss er in Protokollen erscheinen?

Zusätzliche Daten erhöhen nicht automatisch den Nutzen, aber immer Schutz-, Lösch- und Dokumentationsaufwand.

Datenschutz bereits im Datenmodell berücksichtigen

Löschfristen und Zugriffsrechte lassen sich nicht sinnvoll nachträglich ergänzen, wenn das Datenmodell keine eindeutigen Zuordnungen besitzt.

Von Beginn an sollte feststehen:

• welche Datensätze personenbezogen sind
• wie sie einem Kunden oder Vorgang zugeordnet werden
• welche Aufbewahrungsfristen gelten
• wie Daten anonymisiert oder gelöscht werden
• welche Informationen bei einer Deinstallation erhalten bleiben müssen

Protokolle ohne unnötige sensible Daten führen

Protokolle sind für Fehleranalyse und Sicherheit wichtig, können aber selbst schützenswerte Informationen enthalten.

Nicht unnötig protokolliert werden sollten:

• Passwörter
• vollständige API-Schlüssel
• Zahlungsinformationen
• vollständige Sitzungsdaten
• komplette personenbezogene Datensätze
• unnötige Inhalte von Formularen

Häufig reichen technische IDs, verkürzte Referenzen und klar definierte Fehlercodes für eine spätere Analyse aus.

Protokolldaten begrenzen

Auch sicher aufgebaute Logs dürfen nicht unbegrenzt wachsen.

Festgelegt werden sollten:

• welche Ereignisse gespeichert werden
• welche Detailstufe notwendig ist
• wie lange Daten erhalten bleiben
• wie Bereinigung erfolgt
• wer auf Protokolle zugreifen darf
• wie Supportexporte geschützt werden

Fehlermeldungen für Kunden und Administratoren trennen

Kunden benötigen eine verständliche Handlungsempfehlung, Administratoren dagegen technische Details.

Eine sichtbare Fehlermeldung sollte erklären:

• welcher Vorgang nicht abgeschlossen werden konnte
• ob Eingaben erhalten bleiben
• ob der Vorgang wiederholt werden kann
• wie der Kunde Unterstützung erhält

Interne Dateipfade, Datenbankfehler, Zugangsdaten oder technische Stapelmeldungen gehören ausschließlich in geschützte Protokolle.

Keine sensiblen Daten in URLs übertragen

URLs können in Browserhistorien, Serverprotokollen, Analysewerkzeugen und externen Referrern erscheinen.

Deshalb sollten nicht in URLs stehen:

• Passwörter
• API-Schlüssel
• vollständige personenbezogene Daten
• dauerhafte Zugriffstokens
• vertrauliche Bestellinformationen

Sitzungen und temporäre Daten kontrollieren

Plugins speichern häufig Zwischenschritte in der Sitzung oder in temporären Tabellen.

Zu klären sind:

• Wie lange bleiben temporäre Daten gültig?
• Was geschieht bei einer abgelaufenen Sitzung?
• Können Daten eines anderen Benutzers zugeordnet werden?
• Wie werden abgebrochene Vorgänge bereinigt?
• Welche Werte müssen im Warenkorb dauerhaft erhalten bleiben?

Temporäre Daten benötigen ebenso Berechtigungs- und Löschregeln wie dauerhaft gespeicherte Informationen.

Mehrmandanten- und Multishop-Szenarien absichern

Wird eine Erweiterung in mehreren Shops oder Kontexten eingesetzt, müssen Daten und Einstellungen sauber getrennt bleiben.

Das Plugin sollte verhindern, dass:

• Einstellungen eines Shops in einem anderen verwendet werden
• API-Zugangsdaten verwechselt werden
• Kundendaten shopübergreifend sichtbar sind
• Protokolle falschen Instanzen zugeordnet werden
• automatische Prozesse den falschen Datenbestand bearbeiten

Externe Bibliotheken regelmäßig prüfen

Plugins verwenden häufig zusätzliche Pakete für Schnittstellen, PDF-Erstellung oder Datenverarbeitung.

Bei jeder Abhängigkeit sollte bekannt sein:

• welche Version verwendet wird
• ob sie noch gepflegt wird
• welche Sicherheitsmeldungen existieren
• welche PHP-Versionen unterstützt werden
• ob Versionskonflikte mit anderen Plugins entstehen können

Nicht mehr gepflegte Bibliotheken sollten nicht unbegrenzt weiterverwendet werden, wenn bekannte Sicherheitsprobleme oder fehlende Kompatibilität bestehen.

Nur notwendige Bibliotheken einbinden

Jede zusätzliche Abhängigkeit vergrößert Wartungs- und Prüfaufwand.

Vor der Einbindung sollte geprüft werden:

• Wird wirklich der gesamte Umfang benötigt?
• Gibt es bereits eine passende Shopfunktion?
• Wie groß ist die zusätzliche Angriffsfläche?
• Wie regelmäßig erscheinen Updates?
• Wer übernimmt die spätere Pflege?

Updates und Sicherheitskorrekturen planbar machen

Ein sicheres Plugin benötigt einen nachvollziehbaren Updateprozess.

Dazu gehören:

• eindeutige Versionsnummern
• Änderungsprotokoll
• versionierte Datenbankmigrationen
• unterstützte JTL-Shop- und PHP-Versionen
• Testfälle
• Backup- und Rückfallplan
• Dokumentation notwendiger Schritte

Sicherheitsupdates sollten nicht durch undokumentierte Produktivänderungen ersetzt werden.

Hotfixes vollständig in den Entwicklungsstand übernehmen

In kritischen Fällen kann eine schnelle Korrektur notwendig sein.

Anschließend muss der Hotfix:

1. im eigentlichen Quellcode umgesetzt werden
2. eine neue Versionsnummer erhalten
3. getestet werden
4. im Changelog dokumentiert werden
5. kontrolliert verteilt werden

Andernfalls unterscheiden sich Produktivsystem und gepflegter Quellcode dauerhaft voneinander.

Sicherheitsupdates nach Risiko priorisieren

Nicht jede technische Abweichung besitzt dieselbe Dringlichkeit.

Besonders kritisch sind:

• Umgehung von Berechtigungen
• Manipulation von Preisen oder Bestellungen
• Auslesen personenbezogener Daten
• unsichere Datei-Uploads
• offengelegte Zugangsdaten
• manipulierbare Datenbankabfragen
• ungeprüfte administrative Aktionen

Kosmetische oder rein redaktionelle Fehler können dagegen regulär geplant werden.

Testumgebung für Sicherheitsänderungen verwenden

Auch dringende Korrekturen können Nebenwirkungen auf Geschäftsprozesse verursachen.

Geprüft werden sollten je nach Funktion:

• Backend
• Produktseite
• Warenkorb
• Checkout
• Bestellübernahme
• unterschiedliche Kundengruppen
• Schnittstellen
• Datenmigrationen

Die Testumgebung muss ausreichend nah an der produktiven Konfiguration liegen.

Automatisierte Sicherheitstests sinnvoll ergänzen

Wiederholbare Prüfungen können zentrale Regeln bei jeder neuen Version kontrollieren.

Testbar sind beispielsweise:

• ungültige Eingaben
• fehlende Berechtigungen
• Grenzwerte
• fehlerhafte API-Antworten
• doppelte Übertragungen
• Datenbankmigrationen
• Manipulationsversuche bei Preisen

Automatisierte Tests ersetzen keine vollständige Prüfung, helfen aber dabei, bereits bekannte Schwachstellen nicht erneut einzubauen.

Manuelle Sicherheitstests dokumentieren

Besonders Frontend, Rollen und Geschäftsprozesse benötigen häufig realistische manuelle Testfälle.

Ein Testfall sollte enthalten:

• Benutzerrolle
• Ausgangsdaten
• ausgeführte Schritte
• erwartete Ablehnung oder Verarbeitung
• tatsächliches Ergebnis
• verwendete Plugin- und Shopversion

Plugin-Sicherheit und Performance gemeinsam betrachten

Schutzmaßnahmen dürfen den Shop nicht unnötig blockieren, Performanceoptimierung darf aber keine Sicherheitskontrollen entfernen.

Kritisch sind beispielsweise:

• aufwendige Prüfungen bei jedem Seitenaufruf
• externe Sicherheitsabfragen im Checkout
• unbegrenzte Protokollierung
• zu hohe Rate-Limits
• fehlende Zwischenspeicherung unkritischer Ergebnisse

Kontrollen sollten dort stattfinden, wo sie fachlich notwendig sind, und mit geeigneten Datenstrukturen effizient umgesetzt werden.

Schutz vor automatisierter Überlastung

Öffentliche Pluginfunktionen können gezielt oder versehentlich sehr häufig aufgerufen werden.

Sinnvolle Schutzmaßnahmen können sein:

• begrenzte Anfragen pro Zeitraum
• Zwischenspeicherung
• asynchrone Verarbeitung
• Begrenzung von Such- und Exportmengen
• Abbruch sehr aufwendiger Vorgänge
• Überwachung ungewöhnlicher Zugriffsmuster

Ein einzelner öffentlicher Endpunkt darf nicht unkontrolliert umfangreiche Datenbankabfragen oder externe API-Aufrufe auslösen.

Administrative Massenaktionen absichern

Im Backend können Plugins umfangreiche Änderungen an vielen Datensätzen ausführen.

Vor einer Massenaktion sollten vorgesehen sein:

• klare Beschreibung der Auswirkung
• Vorschau oder Testlauf
• Bestätigung kritischer Aktionen
• Begrenzung der Datensätze
• Protokollierung
• Abbruch- oder Wiederaufnahmemöglichkeit
• Backup bei irreversiblen Änderungen

Eine einzelne falsch konfigurierte Aktion darf nicht unbemerkt tausende Produkt- oder Kundendatensätze verändern.

Exporte schützen

Datenexporte können umfangreiche geschäftliche und personenbezogene Informationen enthalten.

Deshalb sollten:

• nur berechtigte Benutzer exportieren dürfen
• Exportumfang begrenzt werden
• sensible Spalten nur bei Bedarf enthalten sein
• Dateien nicht dauerhaft öffentlich gespeichert werden
• Downloads zeitlich oder sitzungsbezogen begrenzt sein
• kritische Exporte protokolliert werden

Sichere Standardwerte verwenden

Neue oder noch nicht konfigurierte Pluginfunktionen sollten nicht automatisch kritische Prozesse aktivieren.

Nach Installation oder Update sollten standardmäßig deaktiviert bleiben:

• automatische Datenübertragungen
• Massendatenänderungen
• E-Mail-Versand
• Preis- und Warenkorbregeln ohne vollständige Konfiguration
• öffentliche Formulare ohne Spam-Schutz

Erst nach Prüfung der Einstellungen wird die jeweilige Funktion bewusst aktiviert.

Fehlende Konfiguration klar erkennen

Ein Plugin darf nicht stillschweigend mit unvollständigen Einstellungen weiterarbeiten.

Es sollte:

• fehlende Pflichtwerte anzeigen
• Verbindungstests anbieten
• kritische Funktionen deaktivieren
• verständliche Administratorhinweise ausgeben
• keine sensiblen Details im Frontend anzeigen

Deaktivierung und Deinstallation sicher gestalten

Auch das Abschalten einer Erweiterung kann geschäftliche und technische Auswirkungen besitzen.

Bei der Deaktivierung sollten:

• automatische Prozesse beendet werden
• Schnittstellenübertragungen stoppen
• offene Vorgänge sichtbar bleiben
• Daten nicht automatisch gelöscht werden
• Administratoren über Folgen informiert werden

Bei der Deinstallation muss zusätzlich geregelt sein, welche Daten gelöscht, anonymisiert, exportiert oder erhalten werden.

Bestehende Bestellungen nachvollziehbar halten

Hat ein Plugin individuelle Konfigurationen oder Berechnungen in Bestellungen eingebracht, dürfen diese Informationen nicht unlesbar werden.

Vor einer Deinstallation muss geklärt werden:

• Wo liegen die historischen Angaben?
• Werden sie für Reklamationen benötigt?
• Können sie exportiert werden?
• Welche gesetzlichen Aufbewahrungspflichten bestehen?
• Welche Darstellung bleibt nach der Deinstallation erhalten?

Typische Sicherheitsfehler bei JTL-Shop-Plugins

Viele Schwachstellen entstehen durch technische Abkürzungen oder eine unvollständige Risikobetrachtung.

Sicherheitscheckliste für ein individuelles JTL-Shop-Plugin

Die folgenden Fragen helfen bei einer ersten technischen Bewertung.

1. Werden alle Eingaben serverseitig validiert?
2. Werden Ausgaben kontextabhängig abgesichert?
3. Existieren serverseitige Berechtigungsprüfungen?
4. Werden Datenbankabfragen parametrisiert ausgeführt?
5. Sind Preis- und Warenkorbregeln gegen Manipulation geschützt?
6. Werden Datei-Uploads nach Inhalt, Größe und Typ geprüft?
7. Sind API-Schlüssel und Zugangsdaten geschützt?
8. Werden externe Antworten und Webhooks verifiziert?
9. Speichert das Plugin nur notwendige personenbezogene Daten?
10. Existiert ein kontrollierter Update- und Sicherheitsprozess?

Wann ein bestehendes Plugin sicherheitstechnisch geprüft werden sollte

Eine Prüfung ist nicht nur nach einem sichtbaren Sicherheitsvorfall sinnvoll.

Typische Anlässe sind:

• unbekannter oder nicht mehr erreichbarer Entwickler
• fehlende Dokumentation
• sehr alte Plugin- oder PHP-Version
• direkte Änderungen am Shopkern
• Verarbeitung personenbezogener Daten
• Datei-Uploads
• individuelle Preis- und Warenkorbregeln
• externe Schnittstellen
• geplantes größeres JTL-Shop-Update
• ungewöhnliche Fehler oder Zugriffe

Was bei einer technischen Pluginprüfung untersucht wird

Der genaue Umfang hängt von Funktion, Risiko und verfügbarem Quellcode ab.

Eine Prüfung kann umfassen:

• Architektur und Pluginstruktur
• Eingabevalidierung
• Berechtigungsprüfungen
• Datenbankzugriffe
• Datei- und Uploadfunktionen
• API-Anbindungen
• Umgang mit Zugangsdaten
• Protokollierung
• verwendete Bibliotheken
• Update- und Migrationsprozesse
• relevante Testfälle

Abhängig vom Ergebnis werden Risiken priorisiert und geeignete Korrekturen geplant.

Sicherheitslücken nach Risiko priorisieren

Nicht jede Abweichung kann gleichzeitig behoben werden.

Ein sinnvoller Sicherheitsprozess für JTL-Shop-Plugins

Sicherheit sollte über den vollständigen Lebenszyklus der Erweiterung betrachtet werden.

Wie Faymax Consulting sichere JTL-Shop-Plugins entwickelt

Faymax Consulting berücksichtigt Sicherheit bereits bei Prozessanalyse, Datenmodell und technischer Architektur.

Die Umsetzung kann umfassen:

• Analyse der verwendeten Daten und Benutzerrollen
• serverseitige Eingabevalidierung
• kontrollierte Berechtigungsprüfungen
• sichere Datenbankzugriffe
• geschützte API- und Zugangsdaten
• kontrollierte Datei-Uploads
• datensparsame Protokollierung
• Fehler- und Ausfallbehandlung
• versionierte Updates und Migrationen
• Tests für zentrale Geschäftsprozesse
• Dokumentation und spätere Wartung

Die passende technische Lösung wird anhand der tatsächlichen Funktion gewählt. Einen Überblick über bestehende und individuelle Erweiterungen bietet die Seite Plugins und Erweiterungen.

Für geschäftskritische Umgebungen kann die technische Betreuung zusätzlich über JTL-Support und Betreuung abgesichert werden.

Häufige Fragen zur Sicherheit von JTL-Shop-Plugins