Closed benred42 closed 3 years ago
Looking into this some more, I'm not convinced that the Nginx config is to blame (although it could be), so I have updated the ticket to describe the issue in more general terms.
Hi. I'm not convinced it's something coming from Concerto, maybe something specific to your hosting environment? Like a proxy in front? I would need to know some details about your setup, i.e. how it's installed (container or bare metal) in order to advise anything, what it is served through, maybe you can provide the actual URL to check what is making a redirection.
Also, say we have https://demo.concertotest.com/, could you reproduce it there?
Best, b.
Thanks for your response! I can indeed reproduce the issue on your demo site: https://demo.concertotest.com//google.com/ As for some of your other questions, we are running Concerto containerized on both RHEL and Ubuntu host servers behind an nginx reverse proxy. We have used the same reverse proxy for almost all of our other containers and they do not have the same issue, so between that and the fact that the issue also exists on your demo site I'm fairly convinced the proxy isn't the issue.
Ok thanks. I see the redirect returns a header: location: /google.com
. So partially this is up to the browser to interpret that as redirection to the external website rather than a relative link to file hosted on demo.concertotest.com, which would return 404.
Anyway, good find, interesting, I'll do some digging and we'll prevent that.
This should no longer be possible starting form a1ed783. This commit will be included in 5.0.26.
Concerto Platform version
5.0.10
Expected behavior
The application should only allow users to access pages and resources hosted on the server running Concerto.
Actual behavior
In it’s current state, the application appears to redirect to any site as long as you include it at the end of the URL as you might a file resource. While this is not necessarily a security issue for the platform itself, it does allow the domain you are hosting Concerto on to be used in phishing attacks by appending a malicious site to the end of the otherwise valid domain.
I think this results because of the try_files directive and the rewriteapp rewrite rule location in the nginx configuration, which appear to be the same in the latest version as well.Steps to reproduce the issue
Assuming you are hosting Concerto on the domain https://concerto-host.example.edu/, going to https://concerto-host.example.edu//google.com/ should redirect you to google.com (or any site put after the double slash)