I configured Apache Jackrabbit 2.6.3 to use WebDAV in an anonymous mode (empty credentials are mapped to anonymous:anonymous).
If I click on a direct link to some file (e.g. JPG or DOC) HTTP 403 error is thrown by GlassFish server. If I press F5, 403 is still there.
BUT if I simply press Enter in address bar in my browser on the same URL, everything is OK, and resource is accessible.
I think that only difference is a referrer in the HTTP header.
I searched for any information about a similar problem, but I couldn't find anything.
Does anybody have some idea how to force WebDAV (or Jackrabbit) to serve files in the anonymous mode despite the referrer or any other reason?
I found a solution.
In web.xml file in section WebDAV the following part must be uncommented:
<init-param>
<param-name>csrf-protection</param-name>
<param-value>disabled</param-value>
</init-param>
With disabled as param-value.
As description says:
Defines the behaviour of the referrer based CSRF protection
1) If omitted or left empty the (default) behaviour is to allow only requests with
an empty referrer header or a referrer host equal to the server host
2) May also contain a comma separated list of additional allowed referrer hosts
3) If set to 'disabled' no referrer checking will be performed at all
Related
I recently saw a few malicious domains including my website pages.
I initially suspected of iframe inclusion, but I already had Header always set X-Frame-Options SAMEORIGIN configured in my httpd.conf.
Other ideas were about malware Javascript including remote pages in the DOM, or even external DNS pointing to my server IP (however, I have name-based virtual hosting on). None of them have been proved.
Investigating on remote domain and looking at apache logs showed us the reality: the malicious remote server made http requests to us, for each request it received, then sent back the result to its clients, actually "mirroring" our website!
I lack ideas on how to stop it. So I blocked its User-Agent completely, via apache conf: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Hope I explained myself. Is there a smarter way to stop such a bad behavior from other domains like them, in the future?
I configure my Alfresco instance to be in a sub-URI (www.example.com/prefix/alfresco , www.example.com/prefix/alfresco/share) and all looks to be fine except that I can't log in Shared. The Catalina.out log this error:
ERROR [alfresco.web.site] [http-apr-28080-exec-10]
javax.servlet.ServletException: Possible CSRF attack noted when
asserting referer header
'http://www.example.com/prefix/alfresco/share/page/'. Request: POST
/prefix/alfresco/share/page/dologin, FAILED TEST: Assert referer POST
/prefix/alfresco/share/page/dologin :: referer:
'http://www.example.com/prefix/alfresco/share/page/' vs server &
context: http://10.140.8.144/ (string) or (regexp)
Then the browser show me this page (www.example.com/prefix/alfresco/share/dologin):
Something's wrong with this page...
We may have hit an error or something might have been removed or
deleted, so check that the URL is correct.
Alternatively you might not have permission to view the page (it could
be on a private site) or there could have been an internal error. Try
checking with your Alfresco administrator.
If you're trying to get to your home page and it's no longer available
you should change it by clicking your name on the Alfresco toolbar.
I tried to deactivate the CSRF filter in share-config-custom.xml, but then I can't log and I don't have any message in the log, the login page show:
Your authentication details have not been recognized or Alfresco may
not be available at this time.
My apache conf:
ProxyPass /prefix/alfresco
http://10.140.8.144:28080/prefix/alfresco ProxyPassReverse
/prefix/alfresco http://10.140.8.144:28080/prefix/alfresco
ProxyPass /prefix/alfresco/share
http://10.140.8.144:28080/prefix/share ProxyPassReverse
/prefix/alfresco/share http://10.140.8.144:28080/prefix/share
I could log before configure Alfresco for work in the reverse proxy.
There is no need to deactivate the CSRF filter. If you changed the context path as described in the documentation you need to make sure that the tomcat connector "knows" the outside context (hostname, port, context).
Either
set proxyName and proxyPort
set RemoteIpValve in tomcat server.xml and set required proxy header
variables in apache (x-forwarded-for, x-forwarded-by,
x-forwarded-proto)
use proxy_ajp instead of proxy_http and define a ajp connector in
tomcat
I have an Apache server that I'm attempting to send requests over HTTPS to, but I've been struggling to get past cross origin issues as well as issues using SSL.
I'm not exactly sure where the problem lies, as I seem to be getting different responses back from the web consoles (testing with Firefox + Chrome) concerning the failed request. In Chrome, I simply see that the request that is sent as a POST is changed to OPTIONS and notes that it failed without much else. In Firefox, I see the following two issues:
In the console, the request says it fails due to CORS:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://123.456.789.001. This can be fixed by moving the resource to the same domain or enabling CORS.
However, inspecting the failed request in the network tab shows the following issue about the certificate:
123.456.789.001 uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_unknown_issuer)
After digging, I'm having issues determining what is actually causing the request to fail - is it because my CORS rules are not setup properly? Or is it because I'm attempting to send requests to a server that is using a self signed certificate and therefore not being trusted by my request/browser?
I believe CORS is setup properly on my end, here are the contents of the files I'm using to enable CORS:
Crossdomain.xml
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
.htaccess:
# Always set these headers.
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token, Access-Control-Allow-Origin, X-Frame-Options"
# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Obviously these settings aren't great for production, but after spending hours trying to pinpoint the issue, I went with some examples that were the least restrictive in terms of enabling CORS hoping I'd see the requests go through and then go back and edit them properly. However, I still see the Cross Origin errors in the console with these changes uploaded to the Apache server (and server restarted after files changed).
So is there anyway to tell if CORS or the self-signed certificate is causing the issue? I didn't necessarily want to go ahead and purchase a SSL certificate at this time since I'm still in development, and the site I'm using to host the content is forced to https, so I can't pass the requests over http.
There's probably an answer already on stackoverflow that I'm missing, sorry in advance for that, I just can't find it.
I have a small TCP server running on my localhost that, for security reasons, will not support CORS.
My question is, if CORS is for cross-domain protection, why is it being requested when I have a page on http://localhost/ request a connection to http://localhost:xxxx
I know I can turn off the security in my browser, but Im trying to understand why localhost to localhost connections are being treated as cross-origin.
XMLHttpRequest cannot load http://localhost:8000/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:63342' is therefore not allowed access. The response had HTTP status code 500.
Because localhost (port 80) is a different host than localhost:8000.
See RFC 6454, Section 5:
If the two origins are scheme/host/port triples, the two origins
are the same if, and only if, they have identical schemes, hosts,
and ports.
Same-origin Policy
The same-origin policy permits scripts running in a browser to only make requests to pages on the same domain. This means that requests must have the same URI scheme, hostname, and port number. This post on the Mozilla Developer Network clearly defines the definition of an origin and when requests result in failure. If you send a request from http://www.example.com/, the following types of requests result in failure.
https://www.example.com/ – Different protocol (or URI scheme).
http://www.example.com:8080/myUrl – Different port (since HTTP requests run on port 80 by default).
http://www.myotherexample.com/ – Different domain.
http://example.com/ – Treated as a different domain as it requires the exact match (Notice there is no www.).
For more information refer to this link
In my apache instillation, I keep seeing the following line in my access logs:
"POST http://yourinfo.allrequestsallowed.net/ HTTP/1.1" 200
It's really freaking me out because this site is not being hosted on my server (I checked the IP just to be 100% sure). I added a "Deny all" line since the site is still in development, and now the HTTP 200 response changed to 403, like the domain is being hosted on my server.
I'm incredibly confused and scared. Does anybody know what's going on? Can I Deny all to this domain that's apparently pointing to my server?
You may want to check to make sure you don't have ProxyRequests On set anywhere where it's not supposed to. Typically a request like that is for a forward proxy and the troubling bit is that you returned a 200 response which could indicate that the request was successfully proxied.
Take a look at this wiki page about Proxy abuse.
My server is properly configured not to proxy, so why is Apache returning a 200 (Success) status code?
That status code indicates that Apache successfully sent a response to the client, but not necessarily that the response was retrieved from the foreign website.
RFC2616 section 5.1.2 mandates that Apache must accept requests with absolute URLs in the request-URI, even for non-proxy requests. This means that even when proxying is turned off, Apache will accept requests that look like proxy requests. But instead of retrieving the content from the foreign site, Apache will serve the content at the corresponding location on your website. Since the hostname probably doesn't match a name for your site, Apache will look for the content on your default host.
But it's probably worthwhile to check that you aren't proxying. Otherwise, it's not really that big of a deal.
After Jon Lin pointed me in the right direction, I figured it out.
After disabling mod_proxy and enabling mod_security, I added the following to my virtual host configuration:
SecRuleEngine On
SecRule REQUEST_LINE "://" drop,phase:1
And then restarted apache. It quits the connection and returns any amount of data, which uses less resources and bandwidth during Brute Force and DDOS attacks.
Also, it shows as an HTTP 404 Response in the access logs.
EDIT: I updated the rule to drop all types or proxies (https,https,ftp). I don't know how many protocols can be used this way, but I'd rather be safe than sorry.