Hitting CSRF when trying to use the workflow admin console

[matteo_l_sc]

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

[jego]

Matteo,

can you please check if the error message bumps up in the repository? If yes, this might be a bug introduced with the latest releases. 

Can somebody confirm that CSRF is now enabled on repository side, too? Maybe it was introduced with the new REST API...

cc:

‌

thanks

Jens

[matteo_l_sc]

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

[afaust]

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>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[matteo_l_sc]

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:

• in the folder <ALFRESCO INSTALLATION>/tomcat/webapps/share/WEB-INF/classes/alfresco I copied the CSRFPolicy section from share-security-config.xml into share-config-custom.xml and set replace="true"
• according to this post the Alfresco-CSRFToken has no entries for the "referer" and the "origin", hence I set them to "https://my.domain/.*" and "https://my.domain", respectively
• I also added a new rule for <method> POST and <path> /alfresco/s/admin/.*, using the same values as above for the referer and the origin
• I found this request, very similar to my case. A link is suggested, but unfortunately it's broken
• I modified the config of the Apache Proxy rewriting the X-Forwarded-For, X-Forwarded-by and Referer headers to "https://my.domain". Sorry, but I can't find the link to the page where I've read it anymore.

Are there any other suggestions?

Thanks,

Matteo

[afaust]

You should have read my reply to ‌ as well. Since this is CSRF on the Repository-tier the share-config-custom.xml is not used - instead you need to use the web-scripts-config-custom.xml file in /shared/classes/alfresco/extension/ (NEVER edit anything in /webapps/*).

[matteo_l_sc]

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?

[afaust]

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.

[kevinr1 · Accepted solution]

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.

[matteo_l_sc]

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