magnolia admincentral is vulnerable to CSRF attacks.
See: MAGNOLIA-5807 - Getting issue details... STATUS
A good resource about the vulnerability is: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Status
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.
Conclusion after 4 hours research
Referrer technique should work if it is written correctly. - major downside is that there are a various situations where Referer header is removed, and these must be treated as an attack - probably with a message to the user that a Referer header is required. (The future may bring us even less referers - sites can add a meta tag to remove them now http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html)
On the interwebs everyone always recommends using the token approach. Its the accepted, transparent approach.
Correct Referer check:
- Strictly check the "end" of the hostname. Protect against:
- Open Redirect: http://hackersite.io/?http://demoauthor45.magnolia-cms.com/.magnolia/etc,
- Tricky Subdomain: http://demoauthor45.magnolia-cms.com.hackersite.io
- Empty Referer.
Investigate Referrer Method
Referer header example: Referer: http://demoauthor45.magnolia-cms.com/.magnolia/trees/website.html?mgnlCK=1404726339576
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
- This refers to sites with a redirect destination as a parameter like http://www.vulnerable.com/redirect.asp?=http://www.links.com
- See https://www.owasp.org/index.php/Open_redirect
- So an attacker could use something like http://hackersite.io/?http://demoauthor45.magnolia-cms.com/.magnolia/etc, and a poorly written referer check might let the request through since the referer will include the domain name.
- 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.
- True HTTPS to HTTP strips the header.
- We simply consider all requests with no referrer to be an attack.
- For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
- OK. we just need a good check.
Support existing installation: WhiteList? Special Code? Tokens??!?
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?
Notes
"And in addition to that we also have the fact that referring websites can remove the Referer header with tricks like META refresh"
http://en.wikipedia.org/wiki/HTTP_referer
Most web browsers do not send the referer field when they are instructed to redirect using the "Refresh" field.
If a website is accessed from a HTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referer field is not sent.[9] "Clients SHOULD NOT include a Referer[sic] header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol"
FYI: Meta tag referrer
http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
Overview
Content Tools