Hallo zusammen, hallo liebes JTL-Team, falls hier jemand offiziell mitliest,
wir haben aktuell einen produktiven Ausfall des Datenabgleichs zwischen JTL-Shop (5.7.2) und JTL-Wawi (aktuellste Version, 2.0.6.0) über die Schnittstelle /dbeS/. Das Problem besteht seit ca. 2–3 Tagen und führt dazu, dass wir aktuell keine Bestellungen aus unserem Onlineshop in die Wawi laden können – ein direkter Geschäftsausfall.
Symptom:
POST /dbeS/mytest.php liefert HTTP 403 statt 200. Der PHP-Errorlog zeigt zu den betroffenen Zeitpunkten keine Einträge – die Blockierung erfolgt also vor der eigentlichen PHP-Verarbeitung durch ein WAF-/Sicherheitsmodul (bei uns ModSecurity beim Hoster).
Ursache (durch Hoster-Support bestätigt):
JTL-Wawi 2.0.6.0 sendet Requests, die im Content-Type-Header multipart/form-data ankündigen, den Body aber tatsächlich als urlencoded-Datenstrom (key=value) übertragen – ohne die für multipart zwingend erforderliche Boundary. ModSecurity wertet das als fehlerhaft aufgebauten Multipart-Request (Regel MULTIPART_STRICT_ERROR, Schutz vor Request-Smuggling) und blockt ihn zurecht.
Das ist aus meiner Sicht klar ein fehlerhaft aufgebauter Request seitens der Wawi, unabhängig davon, ob der jeweilige Hoster diese Prüfung streng oder weniger streng konfiguriert hat. Ein Client, der einen Header ankündigt, den der Body nicht einhält, ist schlicht nicht spezifikationskonform – das kann durch keine Server-Konfiguration "geheilt" werden, sondern muss auf Client-Seite (also in der Wawi) korrigiert werden.
Warum das dringend ist:
Ich setze bereits die neueste Wawi-Version ein, ein Update auf unserer Seite ist also keine Option. Individuelle WAF-Ausnahmen lehnt unser Hoster grundsätzlich ab. Das bedeutet: Ohne einen Patch seitens JTL ist der Datenabgleich für uns aktuell schlicht nicht nutzbar. Da diese Sicherheitsprüfung (Boundary-Validierung bei multipart) ein Standardverhalten vieler WAF-Systeme ist, dürfte das Problem perspektivisch auch andere Nutzer treffen, sobald deren Hoster ähnliche Regeln einführt oder verschärft.
Bitte an JTL:
Könnte sich bitte jemand vom JTL-Entwicklerteam dieses Themas annehmen? Konkret wäre wichtig zu klären:
Vielen Dank für eure Unterstützung und Rückmeldung.
wir haben aktuell einen produktiven Ausfall des Datenabgleichs zwischen JTL-Shop (5.7.2) und JTL-Wawi (aktuellste Version, 2.0.6.0) über die Schnittstelle /dbeS/. Das Problem besteht seit ca. 2–3 Tagen und führt dazu, dass wir aktuell keine Bestellungen aus unserem Onlineshop in die Wawi laden können – ein direkter Geschäftsausfall.
Symptom:
POST /dbeS/mytest.php liefert HTTP 403 statt 200. Der PHP-Errorlog zeigt zu den betroffenen Zeitpunkten keine Einträge – die Blockierung erfolgt also vor der eigentlichen PHP-Verarbeitung durch ein WAF-/Sicherheitsmodul (bei uns ModSecurity beim Hoster).
Ursache (durch Hoster-Support bestätigt):
JTL-Wawi 2.0.6.0 sendet Requests, die im Content-Type-Header multipart/form-data ankündigen, den Body aber tatsächlich als urlencoded-Datenstrom (key=value) übertragen – ohne die für multipart zwingend erforderliche Boundary. ModSecurity wertet das als fehlerhaft aufgebauten Multipart-Request (Regel MULTIPART_STRICT_ERROR, Schutz vor Request-Smuggling) und blockt ihn zurecht.
Das ist aus meiner Sicht klar ein fehlerhaft aufgebauter Request seitens der Wawi, unabhängig davon, ob der jeweilige Hoster diese Prüfung streng oder weniger streng konfiguriert hat. Ein Client, der einen Header ankündigt, den der Body nicht einhält, ist schlicht nicht spezifikationskonform – das kann durch keine Server-Konfiguration "geheilt" werden, sondern muss auf Client-Seite (also in der Wawi) korrigiert werden.
Warum das dringend ist:
Ich setze bereits die neueste Wawi-Version ein, ein Update auf unserer Seite ist also keine Option. Individuelle WAF-Ausnahmen lehnt unser Hoster grundsätzlich ab. Das bedeutet: Ohne einen Patch seitens JTL ist der Datenabgleich für uns aktuell schlicht nicht nutzbar. Da diese Sicherheitsprüfung (Boundary-Validierung bei multipart) ein Standardverhalten vieler WAF-Systeme ist, dürfte das Problem perspektivisch auch andere Nutzer treffen, sobald deren Hoster ähnliche Regeln einführt oder verschärft.
Bitte an JTL:
Könnte sich bitte jemand vom JTL-Entwicklerteam dieses Themas annehmen? Konkret wäre wichtig zu klären:
- Ist der beschriebene Header/Body-Mismatch bei multipart/form-data-Requests der Schnittstelle /dbeS/ bereits bekannt?
- Gibt es dazu bereits ein internes Ticket bzw. einen Fix in Planung?
- Falls nicht: Wie kann ich das offiziell als Bug melden, damit es priorisiert bearbeitet wird?
Vielen Dank für eure Unterstützung und Rückmeldung.