Hi Andy, I'm aware that the CORS check is the client side's responsibility. What I meant is that if the origin is always set to the expected value then the check in Spring's CORS processor [1] won't have any effect regardless of the real origin. TBH I don't know what the reason is behind this check in Spring and I don't know either how much of a concern this is in our case, if any. But I suppose it's not an issue then.
Best, Denes [1] https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/java/org/springframework/web/cors/DefaultCorsProcessor.java#L128 On Thu, Feb 28, 2019 at 12:00 AM Andy LoPresto <[email protected]> wrote: > 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] <[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]> > 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] >> *[email protected] <[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]> >> 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]> >> *Reply-To: *"[email protected]" <[email protected]> >> *Date: *Saturday, 23 February 2019 at 12:06 pm >> *To: *"[email protected]" <[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 >> >> >> Andy LoPresto >> [email protected] >> *[email protected] <[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]> 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. (i.e. add proxy_set_header Origin https://localhost; >> to your nginx config). >> >> I hope this helps, >> Denes >> >> On Fri, Feb 22, 2019 at 11:00 AM Denes Arvay <[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 >> >> On Fri, Feb 22, 2019 at 7:06 AM Elemir Stevko < >> [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; >> 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 >> >> >> >
