I just downloaded Alfresco and I’m trying a few things on my own. After so much reading I managed to hide the 8080 URL from the site using Apache as a proxy server for Tomcat.

Today I faced an issue: I am able to see the login page, but I cant pass through the login page.

After seeing the log file I came to know the CSRF filter is causing the issue. I just went to my configuration page and I removed the CSRF filter and it is working.

Is the CSRF filter required for an intranet site?
Is it possible that someone from the internet can perform a XSRF attack on my application?

2 Answers 2


Yes. It's possible that someone in your intranet is performing such an attack. Even though it's not as likely as on the (wild-wild-wild) internet.

On the other hand you have to have something wrong in your configuration. the CSRF filter of alfresco (or alfresco itself, or on the tomcat container level) needs to have some configuration parameter to make CSRF filter work behind a proxy. Check the docs again.. Just a guess: Maybe you don't work correctly with X-Forwarded-For HTTP headers?

  • Yes there is configuration to work behind proxy. Since I am the only user in the lan I wont do an CSRF attack. Is it possible from outside my lan from intranet
    – samnaction
    Feb 27, 2014 at 12:49
  • Do I read "from intranet" as "from internet"? To me LAN and Intranet ist the same.
    – gue
    Feb 27, 2014 at 13:24
  • sorry internet I typed wrongly
    – samnaction
    Feb 27, 2014 at 13:25
  • As long as your webserver is not accessible from outside your LAN (firewall?!) wild stuff happening in the internet is not reaching your webserver. So: you should be safe.
    – gue
    Feb 27, 2014 at 13:25
  • 1
    But maybe you should try to attack your own server to sniff your own password - just because you can ;-)
    – gue
    Feb 27, 2014 at 13:27

Even if you trust every person in your LAN and the server is only reachable from the LAN, you still need to secure it against CSRF.

Consider a user who visits an evil website. That website can now trigger requests with the user's IP and cookies, enabling CSRF attacks against your webserver if it has such vulnerabilities.

But "CSRF filter" sounds a bit weird. The standard CSRF prevention is to send a token (and verify it on the server) with every request that can cause a side-effect. It's important to put the token in a place that doesn't get filled in implicitly by the browser. POST data or custom http headers are fine, cookies and IP are not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.