02-10-2017 09:24 AM
Hi all,
I setup up Alfresco Community edition build 201701 (Platform 5.2.e, Share 5.2.d) on a Ubuntu 16.04 VM. I also have an Apache (2.4) proxy with the SSL and JK modules, configured according to the guide.
I can access the Workflow admin console (https://<my hostname>/alfresco/s/admin/admin-workflowconsole) but when I try to execute a command, i.e., show definitions all, I get the following in catalina.out
2017-02-10 17:48:16,270 INFO [webscripts.servlet.CSRFFilter] [ajp-apr-8009-exec-1] Possible CSRF attack noted when comparing token in session and request parameter. Request: POST /alfresco/s/admin/admin-workflowconsole
Feb 10, 2017 5:48:16 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [apiServlet] in context with path [/alfresco] threw exception [Possible CSRF attack noted when comparing token in session and request parameter. Request: POST /alfresco/s/admin/admin-workflowconsole] with root cause
javax.servlet.ServletException: Possible CSRF attack noted when comparing token in session and request parameter. Request: POST /alfresco/s/admin/admin-workflowconsole
at org.springframework.extensions.webscripts.servlet.CSRFFilter$AssertTokenAction.run(CSRFFilter.java:845)
at org.springframework.extensions.webscripts.servlet.CSRFFilter.doFilter(CSRFFilter.java:312)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.alfresco.web.app.servlet.GlobalLocalizationFilter.doFilter(GlobalLocalizationFilter.java:68)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:188)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2403)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
I tried to look for that, but most of the results refer to a match on the header rather than the token and setting up / modifying filter rules in share-config-custom.xml didn't help.
Does anyone have an advice?
Thanks in advance.
Matteo
02-13-2017 08:40 AM
It appears some configuration is missing for the Community version of the repository admin console. See here for what to add:
[ALF-21809] The Community admin console isn't using the CSRF prevention token - Alfresco JIRA it will be resolved in next Nightly build, you can patch as per the suggested changes or disable the CSRF for now if preferred.
02-10-2017 10:08 AM
02-11-2017 09:28 AM
Hi Jens,
thanks for the answer. I'm quite a newbie with Alfresco. The error is
logged in /alfresco.log too. Is this what you
want to know?
The same error is given no matter which console I try to use (Model
Messages, Tenant, Workflow, Node Browser), while Alfresco share works
flawlessly.
As I mentioned, I'm running Ubuntu 16.04 LTS.
My /etc/hosts contains
127.0.0.1 localhost
127.0.1.1 alfresco alfresco.my.domain
I tried to replace 127.0.1.1 with the IP (it's a private, I'm in a LAN). No
success.
Currently the OS gets the IP from DHCP and there's no DNS record
associated. I added the mapping to the /etc/hosts of my machine.
Best,
Matteo
02-12-2017 08:29 AM
Since it sounds like you are using Alfresco behind a proxy you need to make the CSRF filter aware of that. Unfortunately that kind of documentation is hard to find... The following example reflects what I know needs to be adapted in that case (for CSRF only - proper proxy setup requires configuration for other aspects)
<config evaluator="string-compare" condition="CSRFPolicy">
<properties>
<!-- these can be regex expressions for matching valid referrers / origins if behind a proxy that does not rewrite referrer / origin before forwarding -->
<referer>http://proxyHostName/.*</referer>
<origin>http://proxyHostName/.*</origin>
</properties>
</config>
02-13-2017 03:14 AM
Hi Axel,
I think you're referring to this page. I noticed it last week, I tried to add a new rule to the filter, but it didn't work, so I didn't mention it in my original message. However, since you pointed it out, I went back and tried something more, unfortunately with no success:
Are there any other suggestions?
Thanks,
Matteo
02-13-2017 03:21 AM
02-13-2017 04:18 AM
Hi again,
thanks for pointing this out, what I found on the Internet pointed to the Share tier.
I did as you suggested, copying web-client-security-config.xml into tomcat/shared/classes/alfresco/extension/web-scripts-config-custom.xml, setting the "replace" option and the "referer" plus the "origin", but it didn't help either.
Looking into the cookies of my browser I noticed that there's one named Alfresco-CSRFToken (for /share) but there's none labelled alf-csrftoken. Is it relevant?
02-12-2017 08:01 AM
The CSRF filter has been introduced with version 6.11 of spring-webscripts - the class level JavaDoc states it is basically a copy of the Slingshot CSRF filter taken on Nov 5th 2016. The web-client-security-config.xml has a default configuration for the CSRFPolicy segment and can be overriden via the web-scripts-config-custom.xml file in the alfresco/extension path.
Interestingly, the default configuration only re-generates a token when accessing the Enterprise admin console via the /s and /service endpoints. There is no configuration for the Community admin console or /wcs and /wcservice endpoints. A CSRF token is expected to be provided either via a HTTP header for POST/PUT/DELETE or as a form field in multi-part POST requests.
Interestingly, I have not encountered any problems when working on the OOTBee Support Tools project and testing against Alfresco 5.2. Looking at the base admin-template.ftl for admin console tools I can see that Alfresco transparently added all the CSRF handling necessary to make it work.
Judging from the web.xml file the CSRF filter is only active on the /s/enterprise/admin/*, /service/enterprise/admin/*, /s/admin/* and /service/admin/* URLs.
The CSRF functionality was apparently added by Kevin Roast in relation to ACE-4881 (non-public JIRA issue) as a result of some penetration testing on a 5.2.1 branch.
02-13-2017 08:40 AM
It appears some configuration is missing for the Community version of the repository admin console. See here for what to add:
[ALF-21809] The Community admin console isn't using the CSRF prevention token - Alfresco JIRA it will be resolved in next Nightly build, you can patch as per the suggested changes or disable the CSRF for now if preferred.
02-14-2017 08:47 AM
Hi Kevin,
thanks a lot for the tip, I applied the patch manually (the instance should run in production, I prefer to stick to the stable version) and it worked like a charm.
Best,
Matteo
Explore our Alfresco products with the links below. Use labels to filter content by product module.