Problem:
HTTP-Requests gegen die DocuWare Platform eines Cloud-Systems liefern den Statuscode 403 - Forbidden mit der Antwortmeldung "Request blocked by DocuWare firewall".
Beispiel:
curl https://{{url}}/docuware/platform/Organisationen -H "Authorization: Bearer {{AccessToken}}" -H "Accept: application/json\r\n"
403 - Request von DocuWare-Firewall blockiert
Ursache:
Dieses Verhalten tritt auf, da die DocuWare-Firewall Requests abweist, die potenzielle Request-Splitting-Angriffe enthalten, und kann durch einen oder mehrere Request-Header verursacht werden, die CRLF verwenden, um mehrzeilige Strings zu senden.
.NET/ApplicationsInsights: Höchstwahrscheinlich fügt Ihre Instrumentierung im Stil von .NET/App Insights einen veralteten Distributed-Tracing-Header hinzu. Ältere .NET/App Insights-Stacks verbreiten Gepäck im nicht standardmäßigen Correlation-Context-Header. Die Schlüssel/Werte in diesem Header sind URL-kodiert. %0D%0A ist der URL-kodierte Wert für CRLF, der von vielen WAFs/Firewalls als Request-Splitting erkannt und blockiert wird.
Der spezifische Schlüssel, den Sie höchstwahrscheinlich sehen, lautet traceStartInfo, das ist der Name eines Kontextdaten-Eintrags. (Es handelt sich um ein Microsoft-seitiges Diagnosekonzept; Sie werden denselben Namen in .NET-Tracing-Codepfaden sehen.)
- Der Legacy-.NET-Propagator (und ältere Application Insights SDKs, die sich darauf stützen) schreibt Anwendungs-Baggage in den Request-Header Correlation-Context, z. B. Correlation-Context: name1=value1,name2=value2... mit URL-kodierten Werten. Enthält ein Wert CR/LF, wird er zu %0D%0A, was die DocuWare-Firewall als verdächtig einstuft.
- Der heutige Industriestandard ist W3C Trace Context + W3C Baggage, d.h. Tracing wird über traceparent/tracestatepropagiert und Baggage in einem separaten Baggage-Header gesendet (nicht Correlation-Context). Neuere .NET-Versionen gehen standardmäßig in diese Richtung.
- Ab .NET 10 ist der Standardpropagator W3C (verwendet Baggage, nicht Correlation-Context). Wenn Sie immer noch Correlation-Context sehen , verwenden Sie wahrscheinlich eine ältere Laufzeitumgebung, eine ältere Instrumentierung oder Sie haben sich explizit für den Legacy-Propagator entschieden.
Weitere Informationen über den Correlation-Context http-Header finden Sie hier: https://github.com/AloisReitbauer/distributed-tracing/blob/master/correlation_context/HTTP_HEADER_FORMAT.md
Allgemeine Lösung:
Verbieten Sie mehrzeilige Zeichenfolgen in allen HTTP-Headern, indem Sie alle CRLF-Werte in HTTP-Headern vermeiden.
.NET-Lösung A: Beenden Sie die Ausgabe von Correlation-Context und wechseln Sie zu W3C
Aktualisieren Sie Ihre Laufzeit/Instrumentierung so, dass standardmäßig der W3C-Propagator verwendet wird, oder setzen Sie ihn explizit beim Start der Anwendung. Dies führt dazu, dass Baggage über den Baggage-Header und Tracing über Traceparent/Tracestatefließt und der alte Correlation-Context-Header entfällt .
Wenn Sie mit OpenTelemetry oder der OTel-Distribution von Azure Monitor instrumentiert sind, behalten Sie nur die W3C-Propagatoren (TraceContext + Baggage). Das vermeidet Correlation-Context vollständig.
Für weitere Informationen, siehe hier.
.NET-Lösung B: Behalten Sie die Legacy-Implementierung bei, aber bereinigen Sie, was Sie in Baggage packen
Wenn Sie Correlation-Context aus Kompatibilitätsgründen beibehalten müssen, sollten Sie sicherstellen, dass Sie niemals CR oder LF zu Baggage-Werten hinzufügen. Suchen Sie in Ihrem Code nach etwas wie Activity.Current?.AddBaggage("traceStartInfo", ...). Entfernen Sie \r/\n und vermeiden Sie mehrzeilige Strings.
.NET Lösung C: Entfernen Sie mehrzeilige Zeichenfolgen aus Kopfzeilenwerten
Stellen Sie sicher, dass Sie alle Header bereinigen, um CR\LF aus allen Werten der HTTP-Header zu entfernen.
Application Insights JS Lösung:
Wenn der Header vom Browser über das Application Insights JS SDK stammt, können Sie Korrelationsheader oder den Bereich, in dem sie hinzugefügt werden, vorübergehend deaktivieren. Das SDK entscheidet, ob es Korrelationsheader hinzufügen darf. Durch die Kontrolle dieser Einstellungen wird verhindert, dass problematische Header an bestimmte Ursprünge gesendet werden.
new ApplicationInsights({
config: {
// ..
disableCorrelationHeaders: true
}
});