Denes, I don’t consider it “invalidating” the server-side check, because the server doesn’t actually enforce the CORS check. It evaluates a request (specifically the Origin header) and has a response header telling the _browser_ how it should behave. The browser is the one that applies the CORS policy.
In effect, in a normal deployment, the CORS policy tells your browser “Hey, don’t just make a random POST connection to nifi:8443/upload?template=bad.xml from evilsite.com <http://this-site-is-tricking-you.com/>” (not the actual API endpoint). If I control evilsite.com and have it make that request when you load the page, the origin is “evilsite.com”. If I put a proxy in place “andysnifiproxy.com”, the browser won’t send your stored credentials (client certificate, JWT, etc.) for NiFi when the browser makes a request to that proxy. CORS isn’t a full-fledged security solution in and of itself, it still needs to be combined with client authentication and authorization to ensure the right actions are exposed and the user is intending to do the action. More info available here: https://security.stackexchange.com/questions/191737/how-do-cors-proxy-websites-work Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Feb 26, 2019, at 12:54 AM, Denes Arvay <[email protected]> wrote: > > Hi, > > Thanks Elemir for confirming the workaround. > Andy, overwriting the Origin header in the proxy invalidates the server-side > CORS check, doesn't it? I might be wrong and due to the complexity of the CVE > I haven't tried to reproduce it but my hunch is that with this workaround we > open up NiFi to this vulnerability again. > Let me know what you think. > > Thanks, > Denes > > On Mon, Feb 25, 2019 at 9:15 PM Andy LoPresto <[email protected] > <mailto:[email protected]>> wrote: > Thanks for confirming it works for you now Elemir. We should improve the > documentation of this and have a guide for setting up NiFi in common proxy > environments which clearly shows these steps to help people avoid this issue > in the future. > > > Andy LoPresto > [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> On Feb 24, 2019, at 2:58 PM, Elemir Stevko <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks a lot for your explanation, Andy! I’ve tested Denes’ workaround and >> it fixes the problem. >> >> Best regards, >> Elemir >> >> From: Andy LoPresto <[email protected] <mailto:[email protected]>> >> Reply-To: "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> Date: Saturday, 23 February 2019 at 12:06 pm >> To: "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> Subject: Re: Invalid CORS request error on NiFi v1.8.0 and 1.9.0 behind nginx >> >> The change was made to mitigate CVE-2018-17195 [1], which allowed a >> malicious actor in a specific scenario to upload a template without >> authorization. This could result in RCE. Denes’ suggestion about rewriting >> the Origin header in your proxy should work. >> >> [1] https://nifi.apache.org/security.html#CVE-2018-17195 >> <https://nifi.apache.org/security.html#CVE-2018-17195> >> >> >> Andy LoPresto >> [email protected] <mailto:[email protected]> >> [email protected] <mailto:[email protected]> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >> >> On Feb 22, 2019, at 3:01 AM, Denes Arvay <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Elemir, >> >> As a workaround you can try to overwrite the Origin header in the request to >> the value which is expected by NiFi, in your case it should be >> https://localhost <https://localhost/>. (i.e. add proxy_set_header Origin >> https://localhost <https://localhost/>; to your nginx config). >> >> I hope this helps, >> Denes >> >> On Fri, Feb 22, 2019 at 11:00 AM Denes Arvay <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Elemir, >> >> I was able to reproduce your issue with a simple nginx-NiFi setup, both >> running on localhost. >> My guess is that the cause is that POST is missing from allowed methods list >> from the /process-groups/*/templates/upload path [1]. >> The commit which introduced this change explicitly states that POSTs need to >> come from the same origin but I don't know the reason behind this decision. >> I'll file a Jira ticket to discuss the issue there (or on the dev@ list). >> I'm not sure if there is any workaround for this. >> >> Best, >> Denes >> >> [1] >> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/NiFiWebApiSecurityConfiguration.java#L125 >> >> <https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/NiFiWebApiSecurityConfiguration.java#L125> >> >> On Fri, Feb 22, 2019 at 7:06 AM Elemir Stevko <[email protected] >> <mailto:[email protected]>> wrote: >> Hello, >> >> I have been running a single instance of NiFi server v1.7.1 on AWS behind >> ALB and nginx: >> >> ALB -> nginx -> NiFi >> >> The configuration has been working fine, but since NiFi v1.8.0, I get >> Invalid CORS request error when I try uploading a template file. Is there >> anything I need to change in the proxy configuration as compared to NiFi >> v1.7.1? >> >> Here are more details on the NiFi configuration: >> >> - ALB terminates the HTTPS connection and opens a new HTTPS connection to >> nginx which then proxies the request to NiFi server. >> >> - NiFi server is configured with OIDC authentication. Neither ALB nor nginx >> authenticate the clients, they just proxy the requests to NiFi. >> >> - nginx is configured similarly to Koji's repo >> ijokarumawak/nifi-reverseproxy (nginx/standalone-plain-http/nginx.conf): >> >> server_names_hash_bucket_size 128; >> >> upstream localhost { >> server localhost:9443; >> } >> >> server { >> listen 443 ssl; >> server_name _; >> ssl_certificate /usr/local/etc/ssl/public.pem; >> ssl_certificate_key /usr/local/etc/ssl/private.key; >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2; >> ssl_ciphers HIGH:!aNULL:!MD5; >> >> proxy_ssl_trusted_certificate /opt/nifi/cert/nifi-cert.pem; >> >> access_log /var/log/nginx/nifi.access.log combined; >> >> location / { >> proxy_pass https://localhost <https://localhost/>; >> proxy_set_header X-ProxyScheme https; >> proxy_set_header X-ProxyHost $host; >> proxy_set_header X-ProxyPort 443; >> proxy_set_header X-ProxyContextPath /; >> } >> } >> >> Best regards, >> Elemir >
