CORS Fehler bei VPN

  • Ich habe eine Frage,


    ich nutze ein Webhostingpaket bei netcup, http://www.example.com, das also Frontend dient, dort läuft eine Angular-Anwendung.

    Zusätzlich hab ich einen VServer v123456.powerserv.de auf dem Spring Boot läuft. Meine Restcalls aus dem Frontend werden an den vServer gepostet und das funktioniert auch so weit.


    Probleme gibt es, wenn der Anwender eine VPN nutzt, dort kommt es zu einem CORS Fehler.

    Wie es aussieht, werden die HTTP-Header durch den VPM Provider entfernt, vermutlich weil die Adresse v12345.powerserv.de nicht akzeptiert wird. (my guess)


    Jetzt ist meine Idee meine Restcalls auf einer SUBDOMAIN auf backend.example.com abzufeuern, das dann ja die gleiche Domain ist und diese dann serverseitig weiterzuleiten, quasi als Proxy,

    aber ich weiss nicht wie das geht? Geht das überhaupt mit einem Webhostingpaket oder brauch ich da für was anderes?

    In den NGINX Einstellungen des Webhostungpakets kann man irgendwie nicht wirklich viel einstellen.


    Oder lässt sich das über einen NodeJS Server lösen?


    Oder ist mein Vorhaben ohnehin totaler NONSENSE? :P

    Danke

    Michael

  • Wie es aussieht, werden die HTTP-Header durch den VPM Provider entfernt, vermutlich weil die Adresse v12345.powerserv.de nicht akzeptiert wird. (my guess)

    Die Frage ist eher - warum zur Hölle ist das möglich?


    Das ganze sollte verschlüsselt (TLS/HTTPS) kommen, daher kann da keiner etwas entfernen oder modifizieren. Wenn es nicht verschlüsselt ist, weißt du ja erstmal, wo du nachschärfen musst. Oder der VPN Provider ist kein echter VPN Provider, sondern arbeitet als MITM Proxy und bricht das TLS auf. Aber selbst da fasse ich mich an den Kopf, dass man sowas freiwillig benutzt.

    Ein Webhostingpaket kann nicht als Reverse Proxy arbeiten. Deine Idee da irgendwas zusammenzuziehen klingt auch stark nach Pfusch, das ist nicht das, was du willst.


    An sich ist es nicht abwegig, dass die API irgendwo anders steht - der Webserver der API muss nur die richtigen CORS Header setzen und die Content-Security-Policy der Seite im Webhostingpaket muss deine API zulassen. Dafür ist CORS ja da, man muss es nur richtig nutzen.


    Wie schauen denn die CORS Header aus, die deine API (Springboot) setzt?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Danke für die schnelle Antwort :)

    Klingt alles plausibel! Schon mal gut zu wissen, dass ich mich auf dem Holzweg befinde.

    Für mich ist das Thema Security leider ein Buch mit 7 Siegeln aber bemühe mich da besser zu werden.

    Grundsätzlich ist sowohl auf Frontend als auch Backend SSL aktiviert, sprich die Webseite ist nur über https aufrufbar und auch der backend-call findet über https statt. Beide von LetsEncrypt.



    Der betroffene User verbindet sich über eine VPN der company mit dem Internet, wenn er die Seite aufruft kommt der Cors-Fehler.

    "response to preflight request doesn't pass access control check: "No 'Access-Control-Allow-Origin' header is present on the requested resource"
    Die Verbindung ohne VPN klappt aber wunderbar. Daher war das mein Verdacht, dass da irgendwas in die Richtung wie geschildert passiert.


    Die Seite die ich aufrufe heisst quasi https://workshop.example.com

    Die Response Header die ich zurückbekomme, bei meinem Aufruf der klappt sehen so aus:


    1. Access-Control-Allow-Headers: content-type
    2. Access-Control-Allow-Methods: GET
    3. Access-Control-Allow-Origin: https://workshop.example.com
    4. Access-Control-Max-Age: 1800
    5. Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
    6. Cache-Control: no-cache, no-store, max-age=0, must-revalidate
    7. Connection: keep-alive
    8. Content-Length: 0
    9. Date: Wed, 05 May 2021 09:32:47 GMT
    10. Expires: 0
    11. Pragma: no-cache
    12. Server: nginx/1.19.10
    13. Strict-Transport-Security: max-age=31536000 ; includeSubDomains
    14. Vary: Origin
    15. Vary: Access-Control-Request-Method
    16. Vary: Access-Control-Request-Headers
    17. X-Content-Type-Options: nosniff
    18. X-Frame-Options: DENY
    19. X-XSS-Protection: 1; mode=block
  • Muss da nicht https://example.com rein - also die Adresse des Frontends?

    Das sehe ich auch so. In dem Header sagst du ja quasi: Die Ressource darf auf der Website XYZ eingebunden werden.



    Wo würde ich denn die Content-Security-Policy setzen?

    Die CSP setzt du grundsätzlich in unterschiedlicher Ausführung in beiden Webservern als Header - sowohl der API, als auch deinem Frontend. Siehe https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP und https://report-uri.com/home/generate

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber