Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

magnolia admincentral is vulnerable to CSRF attacks. 

See:  MAGNOLIA-5807 - Getting issue details... STATUS

A good resource about the vulnerability is:


We looked into the token method but are concerned that too many things must be changed to implement it.

And that this could cause problems for existing magnolia installations.

Investigate Referrer Method

Referer header example: Referrer:

But I dont understand all of these statements:

  • For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check 
    • Does this mean someone can take advantage of a browsers broken redirect behaviour to make the referer header set to the wrong value?
  • and some organizations or browser tools remove referrer headers as a form of data protection.
    • This is OK. That organization would have to turn the referrer headers back on.
  • There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change.
    • Can we simply consider all requests with no referrer to be an attack?
    • What is this implying about HTTPS requests? Is the Referrer header not included? Is it not readable on the server?
This we can be sure to cover:
  • For example, if the victim's domain is "" then an attacker have the CSRF exploit originate from "" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
Should it be possible to configure a white list of additional referrers? Perhaps some integrations would like to make direct requests from external servers, or would this be introducing too great of a vulnerabilty?



  • No labels