XNAT 1.8.2: 403 error after redirection
Ignace Van Spilbeeck
Hi all,
After deploying XNAT 1.8.2 on a (virtual) CentOS 7 machine, I run into some issues with "403" errors.
In security.log I see multiple similar lines to this one: "[http-nio-8080-exec-6] ERROR org.nrg.xnat.security.XnatInitCheckFilter - A possible security violation has occurred. An attempt to access http://localhost:8080/favicon.ico specifying https://bil.uantwerpen.be/app/template/Login.vm as the referer was made by user guest."
I believe this has something to do with Apache HTTPD, but I can't find a solution anywhere.
This is the vhosts.conf file:
# Ansible managed
DirectoryIndex index.php index.html
<VirtualHost *:80>
ServerName xnat01.uantwerpen.be
ServerAlias bil.uantwerpen.be
Redirect / https://bil.uantwerpen.be/
</VirtualHost>
<VirtualHost *:443>
ServerName xnat01.uantwerpen.be
ServerAlias bil.uantwerpen.be
SSLEngine on
SSLCipherSuite AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression off
SSLCertificateFile /etc/pki/tls/certs/xnat01_uantwerpen_be.cer
SSLCertificateKeyFile /etc/pki/tls/private/xnat01_uantwerpen_be.key
SSLCertificateChainFile /etc/pki/tls/certs/xnat01_uantwerpen_be_interm.cer
ErrorLog logs/ssl_error_log
CustomLog logs/ssl_access_log combined
LogLevel warn
SSLProxyEngine On
ProxyPass "/" "http://localhost:8080/"
ProxyPassReverse "/" "http://localhost:8080/"
ProxyPass "/" "ajp://localhost:8009/"
ProxyPassReverse "/" "ajp://localhost:8009/"
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
<Location "/">
Order deny,allow
Allow from all
</Location>
</VirtualHost>
Does anyone have any useful insights regarding this?
Thanks in advance,
Ignace Van Spilbeeck
Herrick, Rick
The security error is correct, because, from XNAT’s perspective, this looks like an attempt at cross-site request forgery, where code embedded in one server (the referrer) is requesting code from another possibly malicious or compromised server.
The rather weird thing here is that favicon.ico is not something XNAT itself requests. It’s automatically requested by the browser, which means that the browser is requesting http://localhost:8080/favicon.ico, even though the page URL is through your FQDN. I’m guessing that something in the response headers is telling the browser to use localhost:8080 instead of the FQDN.
Given all that, the issue is almost certainly the proxy configuration, as you say. I haven’t worked with Apache HTTPD in quite a while, but I think the configuration I have for nginx for my dev VM translates pretty well:
location / {
proxy_pass http://localhost:8080;
proxy_redirect http://localhost:8080 $scheme://$server_name;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 1200;
proxy_send_timeout 1200;
proxy_read_timeout 1200;
send_timeout 1200;
proxy_buffers 4 32k;
client_max_body_size 0;
client_body_buffer_size 128k;
}
Notice that proxy_pass and proxy_redirect both use localhost:8080. These are the direct equivalent of ProxyPass and ProxyPassReverse in your configuration. So nginx is doing the same thing your Apache proxy is doing. The big difference is that, on the Tomcat side in my configuration, everything still appears to use the same FQDN of the original request (the only difference is that the URL is http instead of https). This is due to the various X-Forwarded-* headers added to the request, which tells Tomcat that it’s being treated as that URL instead of localhost:8080. Essentially it reduces localhost:8080 to a mailing address or coordinate, but everything else continues along with the same server address.
The request received by Tomcat includes those headers. Here’s a sample of the headers received by XNAT itself (I set a breakpoint in the code then just dumped these off the request object):
host = xnatdev.xnat.org
x-real-ip = 10.1.1.1
x-forwarded-host = xnatdev.xnat.org
x-forwarded-server = xnatdev.xnat.org
x-forwarded-for = 10.1.1.1
referer = https://xnatdev.xnat.org/
The interesting thing is that Apache’s mod_proxy claims that it automatically adds these headers unless turned off explicitly by setting ProxyAddHeaders Off. It’s worth checking whether those headers are actually being added and set to the appropriate values. I’m guessing no, because this is exactly what I’d expect to see without them. I just don’t know why they’re not getting set (this sort of thing is at least in part why we ended up using nginx over Apache HTTPD in a number of tools, including XNAT Vagrant).
The other thing that jumps out at me is that there are two entries each for ProxyPass and ProxyPassReverse, one for http access and one for AJP access. That doesn’t seem right to me. If the proxy header configuration is handled by mod_proxy but HTTPD ends up using AJP, I could see that messing up the headers as well. It’s certainly forwarding over http, because that’s where the http://localhost:8080 request is coming from, but the AJP configuration could be breaking that. I’d consider trying with the AJP lines commented out or removed.
--
Rick Herrick
XNAT Architect/Developer
Computational Imaging Laboratory
Washington University School of Medicine
From:
xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Ignace Van Spilbeeck <ignace.va...@uantwerpen.be>
Date: Wednesday, July 14, 2021 at 9:26 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] XNAT 1.8.2: 403 error after redirection
|
* External Email - Caution * |
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/xnat_discussion/9ba6f880-aa15-4409-9987-a6faa8d7f2b0n%40googlegroups.com.
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
Tashrif
Tashrif