Bitdefender Encrypted Web Scan blockiert Same-Site-API-Aufrufe

Bitdefender Encrypted Web Scan blockiert Same-Site-API-Aufrufe

Ich habe ein einfaches, sicheres Same-Site-, Cross-Origin-Setup wie:

Frontend:https://www.example.com API:https://api.example.com

Auf beiden Domänen verwenden wir von Amazon ausgestellte SSL-Zertifikate (AWS ACM).

Einige unserer Kunden haben Bit Defender Total Security installiert, das API-Aufrufe an unsere eigene API blockiert, selbst einfache GETAufrufe, die keinen aufwändigen Austausch von Anmeldeinformationen/Cookies erfordern.

Ich habe herausgefunden, dass Bitdefender den access-control-allow-originHeader in der eigentlichen XHR-Anfrage entfernt; der OPTIONSAufruf der API enthält den Header jedoch immer noch korrekt.

Wenn ich die Funktion deaktiviere „Online Threat Prevention Web-Schutz > Verschlüsselter Web-Scan" in Bitdefender und starten Sie Chrome neu. Es funktioniert wie erwartet und der GETAufruf der API wird korrekt zurückgegeben.access-controll-allow-origin=https://www.example.com

Das Problem tritt auch nicht auf, wenn sich die API in derselben Domäne befindet, wie z. B. https://www.example.com/api, was darauf schließen lässt, dass es sich auch hierbei um ein CORS-bezogenes Verhalten von Bitdefender handelt.

Als ich die Beschreibung dieser Funktion las, dachte ich, dass Bitdefender unsere Zertifikate vielleicht nicht mag, und ich habe unsere AWS-Zertifikate durch LetsEncrypt-Zertifikate ersetzt; nicht einmal ein Wildcard-Zertifikat; immer noch dasselbe Problem.

Mir ist auch aufgefallen, dass Bitdefender unser Zertifikat durch sein eigenes lokales Zertifikat ersetzt, um als Man-in-the-Middle zu fungieren, wahrscheinlich um die Anfragen zu scannen, nehme ich an.

Was ich nicht verstehe ist, dass zum Beispielwww.imdb.comhat ein ähnliches Setup mit ihrenapi.graphql.imdb.comund sie verwenden auch AWS-Zertifikate.

Aber aus irgendeinem Grund werden ihre Zertifikate nicht ersetzt und ihr Access-Control-Allow-Origin-Header in ihren API-Anfragen nicht entfernt.

Die einzigen Unterschiede, die ich bisher zwischen uns und IMDB feststellen konnte, sind, dass sieTLS 1.3in ihren Anfragen und wir verwendenTLS 1.2(über AWS API Gateway)

Die Online-Hilfe, die ich bisher gefunden habe, schlägt lediglich vor, den Kunden zu bitten, diese Funktion in Bitdefender auf seiner Website auszuschalten, was ich nur schwer akzeptieren kann, wenn diese Art der Einrichtung für IMDB funktioniert (na ja, vielleicht stehen sie auf der Whitelist von Bitdefender).

Ich habe es auch an Bitdefender als „Falsch-Positiv“-Thread-Identifizierung gemeldet, aber es kam keine Antwort.

Irgendwelche anderen Ideen, wonach ich suchen könnte?

Antwort1

Das Bitdefender-Team war sehr hilfreich. Es stellte sich heraus, dass Bitdefender, wenn es aktiv ist, aufhttp/1.1Protokoll. Unser Server hat den Header "Access-Control-Allow-Origin" nicht für http/1 zurückgegeben, sondern nur für http/2. Ich konnte dies auch ohne Bitdefender problemlos debuggen, indem ich curl mit --http1.1aktivem Flag verwendete oder Chrome mit startete --disable-http2. Wir verwendenAWS API Gatewayin unserem Setup und nach einigem weiteren Googeln fand ich heraus, dass AWS die Anforderungsheader für http/1 etwas anders analysiert.

Kopfzeilen.ÖRigin vs. Header.ÖUrsprung

Wir verwenden den Ursprungswert, um die richtigen Antwortheader zu erstellen, und da wir Kleinbuchstaben erwarteten, konnten wir den Wert im Grunde nicht finden. Ja, nur ein Buchstabe, was mich Tage gekostet hat. Durch einfaches Hinzufügen dieses Fallbacks hat es funktioniert:

const origin = headers["origin"] || headers ["Origin"]

Danke, Bitdefender, für den Hinweis!

verwandte Informationen