JTL-Wawi 2.0.6.0 sendet fehlerhafte multipart/form-data-Requests – ModSecurity blockt Datenabgleich mit 403 (scheinbar hosterabhängig)

[cnc]

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:

• 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?

Für Rückfragen oder Details (Logs, Zeitstempel, weitere technische Angaben) stehe ich jederzeit zur Verfügung.

Vielen Dank für eure Unterstützung und Rückmeldung.

 

[NoOne]

Ich bezweifle das noch groß Dinge am Abgleich geändert werden, weil der insgesamt recht stabil läuft. Eventuell hilft es, wenn du das hier in die .htaccess im Shop-Root einträgst:

<IfModule mod_headers.c>
SetEnvIfNoCase Content-Type "^multipart/form-data$" IS_JTL_BUG
SetEnvIfNoCase Request_URI "/dbes/" IS_JTL_PATH
SetEnvIf IS_JTL_BUG 1 JTL_FIX_REQUIRED
SetEnvIf IS_JTL_PATH !1 !JTL_FIX_REQUIRED

RequestHeader set Content-Type "application/x-www-form-urlencoded" env=JTL_FIX_REQUIRED early
</IfModule>

Das könnte allerdings auch schon zu spät sein, wenn mod_security davor triggert (besser als das early das dahinter hängt gehts glaub ich nicht), oder ein nginx vor dem Apache läuft und das blockt bevor das überhaupt zu Apache durchdringt.

 

[mvh]

Warum nicht die IP whitelisten ?
oder
SetEnvIfNoCase Remote_Addr ^192\.xxx\.xxx\.100$ MODSEC_ENABLE=Off

 

[cnc]

Der Hoster möchte nicht whitelisten.

Genau, .htaccess hilft nicht, weil bereits vorher schon abgelehnt wird.

Stabil läuft es nicht, wenn der HTTP POST nachweislich nicht korrekt ausgeführt wird. Niemand garantiert, dass andere Hoster ihre Sicherheitseinstellungen nicht auch anpassen werden.

 

[NoOne]

Der Hoster möchte nicht whitelisten.

Genau, .htaccess hilft nicht, weil bereits vorher schon abgelehnt wird.

Stabil läuft es nicht, wenn der HTTP POST nachweislich nicht korrekt ausgeführt wird. Niemand garantiert, dass andere Hoster ihre Sicherheitseinstellungen nicht auch anpassen werden.

Das ist aber nunmal rein Hostingseitig. Ohne die mod_security einschränkung gibts da keine Probleme. Ich bin mir relativ sicher das am Abgleich an sich schon seit langem nichts grundlegendes mehr geändert wurde. Nicht mal sowas simples wie einen User-Agent beim Verbindungstest mitzusenden.

Edit: Zum effektiven melden musst du übers Kundencenter ein Support-Ticket aufmachen.

 

[mvh]

Die Aussage zumindest für 2.X stimmt nicht.
Laut den 2.0.6-Code ist es allerdings MultipartFormDataContent und das ist der DbeSClient selbst und das ist der Standard MS HttpClient

Spoiler: s.h.

private HttpContent CreateContent(long zipContainerMemoryStreamLength, string stepName, Stream payloadStream)
        {
            if (zipContainerMemoryStreamLength > 0L)
            {
                this.LogPayLoad(payloadStream, stepName);
            }
            MultipartFormDataContent multipartFormDataContent = new MultipartFormDataContent();
            multipartFormDataContent.Add(new StreamContent(payloadStream)
            {
                Headers =
                {
                    {
                        "Content-Disposition",
                        "form-data; name=\"data\"; filename=\"data.zip\""
                    }
                }
            }, "data", "data.zip");
            multipartFormDataContent.Add(new StringContent(this._username), "userID");
            multipartFormDataContent.Add(new StringContent(this._password), "userPWD");
            DefaultInterpolatedStringHandler defaultInterpolatedStringHandler = new DefaultInterpolatedStringHandler(0, 1);
            defaultInterpolatedStringHandler.AppendFormatted<int>(this._clientVersion, "000000");
            multipartFormDataContent.Add(new StringContent(defaultInterpolatedStringHandler.ToStringAndClear()), "vers");
            return multipartFormDataContent;
        }

 

[NoOne]

Das ist nur eine Funktion. Ich denke mal nicht das du Zugriff auf den Wawi-Quellcode hast. Was davor oder danach passiert, kannst du also nicht wissen. Das ist schließlich nur ein return der da passiert und nicht das senden an sich.

 

[mvh]

Das ist nur eine Funktion. Ich denke mal nicht das du Zugriff auf den Wawi-Quellcode hast. Was davor oder danach passiert, kannst du also nicht wissen. Das ist schließlich nur ein return der da passiert und nicht das senden an sich.

Das ist der Quellcode von JTL.Wawi.Sync.Core.Services.dbeS (JTL.Wawi.Sync.Core.dll)

 

[NoOne]

Aber das ist nur CreateContent. Du weißt alleine damit halt nicht was danach noch passiert. Die schlussendlich gesendeten Header kann man auch danach noch ändern.

 

[mvh]

Aber das ist nur CreateContent. Du weißt alleine damit halt nicht was danach noch passiert. Die schlussendlich gesendeten Header kann man auch danach noch ändern.

Der CreateContent ist der Factory-Aufruf, also der "letzte" in dbeS-HttpClient. Ich könnte später ja noch debuggen, für Moment ist es für mich zu viel Aufwand.

 

[NoOne]

Okay, das würde die Sachlage ändern. Das wäre dann eher ein Problem beim Hoster, das er ggf. den Header umschreibt. Oder ModSecurity liefert einen FalsePositive. Da wäre ein Mitschnitt via Fiddler oder Wireshark interessant, oder die raw http capture vom Hoster. Ich teste das mal mit ModSecurity und OWASP CRS.

 

[mvh]

Wir können ja auch zweigleisig fahren. Ich prüfe es mit Debugger, aber nicht mehr Heute und Du mit WireShark.

 

[mvh]

Nur so eine Frage an @cnc. Sicher, dass es über Https läuft? Und auch kein Zertifikatfehler (veraltet) ist?

 

[cnc]

Nur so eine Frage an @cnc. Sicher, dass es über Https läuft? Und auch kein Zertifikatfehler (veraltet) ist?

Ja läuft über HTTPS und Zertifikat ist aktuell.

Konnte die Fehler mit Curl nachstellen.

 

[cnc]

Domain Factory hat mir gerade bestätigt das die Multipart-Prüfung erst "kürzlich" aktiviert wurde.

 

[NoOne]

Was ich hier kriege ist folgendes:

[Wed Jul 29 18:04:40.896482 2026] [security2:error] [pid 2497583:tid 2497683] [client XXX] ModSecurity: Access denied with code 400 (phase 2). Match of "eq 0" against "MULTIPART_STRICT_ERROR" required. [file "/etc/modsecurity/modsecurity.conf"] [line "93"] [id "200003"] [msg "Multipart request body failed strict validation: PE 0, BQ 1, BW 0, DB 0, DA 0, HF 0, LF 0, SM 0, IQ 0, IP 0, IH 0, FL 0"] [hostname "XXX"] [uri "/Shop/dbeS/mytest.php"] [unique_id "amokmC2UXZ7TlTBmbkSCQAAAAFQ"]

Der einzige Fehlerflag hier ist BQ -> Quoted Boundary. Das ist allerdings laut RFC 2046 nicht falsch und erlaubt.

Bei mir ist mit den Standardeinstellungen der Fehler also, das sowas wie

Content-Type: multipart/form-data; boundary="---------------------123"

Von der Wawi geliefert wird statt:

Content-Type: multipart/form-data; boundary=---------------------123

Und *nicht* das der Content-Type falsch ist.

Edit: Kann DomainFactory da den tatsächlichen Fehler liefern? Ausreichend anonymisiert.

 

[NoOne]

Noch mal was nachgeliefert: Ich hab die MULTIPART_STRICT_ERROR Regel so angepasst, das MULTIPART_BOUNDARY_QUOTED nicht gewertet wird und danach einen Komplettabgleich gestartet (ohne eine Bestellung im Shop zu haben allerdings). Der lief problemlos durch. Außer den Quoted Boundaries scheint die Wawi hier nichts falsch zu machen (und nicht mal das ist wirklich falsch, ModSecurity prüft strikter als nötig gegen die RFC). Wenn du an JTL gemeldet hast, das der Content-Type falsch ist, dann wird JTL da also vermutlich keinen Fehler finden, weil das an den Boundary Quotes liegt.

 

[mvh]

Laut .Net Core 8 Dokumentation wird immer Double-Quote Verhalten verwendet und es kann nur manuell geändert werden. Hier macht JTL nichts falsch.

 

[cnc]

Kurzes Update von meiner Seite – und zunächst eine Entschuldigung für meine ursprüngliche Annahme.

Ich war zunächst davon ausgegangen, dass die Wawi fehlerhafte multipart/form-data-Requests (fehlende bzw. inkonsistente Boundary) sendet. Nach meinen Tests muss ich diese Vermutung korrigieren.

Ich habe das Verhalten mit curl direkt gegen den Shop reproduziert:

• application/x-www-form-urlencoded → HTTP 200 OK
• multipart/form-data mit ungequoteter Boundary (boundary=...) → HTTP 200 OK
• multipart/form-data mit gequoteter Boundary (boundary="...") → HTTP 403 Forbidden

Der Request-Body war dabei identisch. Der einzige Unterschied war, ob die Boundary im Content-Type in Anführungszeichen stand oder nicht.

Damit scheint weder der dreifach vorkommende User-Agent noch Multipart an sich die Ursache zu sein. Die Blockierung tritt ausschließlich bei einer gequoteten Boundary auf.

 

[cnc]

Kurzes Update von meiner Seite, auch als Dank an @NoOne und @mvh für die Unterstützung bei der Eingrenzung.

Domain Factory hat sich gemeldet und bestätigt im Kern genau das, was wir hier rausgearbeitet haben: Die betreffende ModSecurity-Regel wurde Anfang der Woche zu strikt aktiviert und wird jetzt von Security-Team und Fachabteilung angepasst, sodass sie nicht mehr auf die Wawi-Requests (gequotete Boundary) anschlägt. Die Änderung ist aktuell in Prüfung und wird danach plattformweit ausgerollt – laut DF frühestens ab dem späten Vormittag/Mittag, kann sich aber je nach Prüfung noch verschieben.

Wichtig: Keine Aktion auf unserer Seite nötig – weder an der Wawi noch am Shop muss etwas geändert werden. Sobald der Fix verteilt ist, sollte der Datenabgleich wieder normal laufen.

Damit bestätigt sich noch mal: Es war kein Wawi-Bug, sondern eine zu strenge, kürzlich verschärfte WAF-Regel beim Hoster (Flag BQ / Boundary Quoted), die eine laut RFC 2046 gültige Syntax fälschlich blockiert hat.

Ich melde mich hier, sobald der Abgleich bei uns wieder läuft.