Page History
Problem
Magnolia magnolia admincentral is vulnerable to CSRF attacks. Ouch.
See:
Jira | ||||
---|---|---|---|---|
|
A good resource about the vulnerability is: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Status
Referer header example: Referer: http://demoauthor45.magnolia-cms.com/.magnolia/trees/website.html?mgnlCK=1404726339576
Status
We started work on and have a basic implementation of the token method (see above ticket) We looked into the token method but are concerned that too many things must be changed to implement it.And , and that this could cause problems for existing magnolia installations. . So we decided to spend some more time researching the "referer-check" approach to see if this is feasible.
Conclusion after 4 hours research
Referrer technique Referer checking should work against known exploits 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)The three major downsides are:
- It requires that the browser sends the referer header. Some users and companies consider this to be a privacy issue - (and potentially security issue) as the referer header contains information about the browsers history - and could have sensitive information in the form of querystring. So they may currently have browser or company proxy to strip header. Of course we could say its a requirement, but customers could take affront at that (see https://bugs.launchpad.net/launchpad/+bug/560246) Privacy is a hot topic.
- There is a new html5 meta tag to configure if the referer is sent or not.
- I think we can cover the known problems with request checking, but new browser vulnerabilities could come out (flash or other plugins) that create a hole.
- We do have to be careful to implement the referer checking properly.
- Additionally: On the interwebs everyone always recommends using the token approach. Its the accepted, transparent approach. People may be confused or doubtful if you implement a different approach. (See https://www.google.com/webhp?ie=UTF-8#q=csrf+referer+)
Implementation:
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.
Note: There is a vulnerability with a 301 redirect, it forwards its request headers. But this would only be a vulnerability via "xss" - ie if a user of the system somehow put the link on a webpage served by the same magnolia server url. (explicitly: see 301 Redirect Attack: in Notes below.)
How to support existing installation: WhiteList? Special Code? Tokens??!?
OWASP Page: 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:
Statement by Statement
- "For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check 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 individual or organization would have to turn the referrer headers back onsacrafice their privacy in this case.
- "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??!?
- , ie last part of the host.
Notes
Privacy
Quote from the HTTP spec:
"
Because the source of a link might be private information or might reveal an otherwise
private information source, it is strongly recommended that the user be able to
select whether or not the Referer field is sent. For example, a browser client could
have a toggle switch for browsing openly/anonymously, which would respectively
enable/disable the sending of Referer and From information.
"
...
"And in addition to that we also have the fact that referring websites can remove the Referer header with tricks like META refresh"
Django uses a referer check:
https://code.djangoproject.com/ticket/16870
Vitriol of the privacy concious / support requests from hell / this could be us:
https://bugs.launchpad.net/launchpad/+bug/560246
301 Redirect Attack:
4. The victim's browser requests https://attacker.com/badstuff from the attacker's server, and sends Referer: https://launchpad.net/foo in the headers.
5. The attacker's server responds with a 301 Redirect, which redirects the victim's browser to https://bugs.launchpad.net/csrfurl
6. The victim's browser receives the redirect, requests https://bugs.launchpad.net/csrfurl from the launchpad server, and sends Referer:https://launchpad.net/foo with the request.
http://en.wikipedia.org/wiki/HTTP_referer
...