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


Note: This vulnerabilility has been fixed.

Problem

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

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) but are concerned that too many things must be changed to implement it, 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

Referer checking should work against known exploits if written correctly. The four downsides i see 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.
  • More of an image then a technical thing: 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:

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.)

Questions:

How to 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?

Research

OWASP Page: Investigate Referrer Method

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Checking_The_Referer_Header

Statement by Statement

  • "For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check"
  • "and some organizations or browser tools remove referrer headers as a form of data protection."
    • That individual or organization would have sacrafice 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 browsing from an HTTPS page to a HTTP page strips the referer header by design (spec).
    • 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, 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

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


New review by Topher 2018-04-09

There are continuing client requests for improved CSRF security:

MAGNOLIA-6865 - Getting issue details... STATUS

Recommendation

I think that we should implement synchronizer-token authentication on Magnolia admincentral, in addition to the existing referer checks, in order to be in compliance with the recommendations by OWASP (See Owasp recommendations.) , and to match the established best-practice in the enterprise CMS space. 

Research of the Referer check

I have researched Referer based security again.

The one problem that appears legit to me is that of a "replay attack" - a request that was intended to only be made once could be triggered multiple times, which could result in unexpected, unwanted changes to content. Our current protection would not stop that.

There are four common objections to relying on referer-check alone - but I don't find the reasons convincing.

  • Incorrect referer check: "There are also common implementation mistakes with referer checks." I think that we have satisfactorally avoided the mistakes. (But hard to convince someone of that - or prove it.)
  • No referer header set: Request may not have a referer header set. We simply do not allow them access, which is acceptable for our use-case.
  • Browser support: Previously, not all browsers protected the referer header properly. Now they do. Its possible that someone has installed a browser extension/plugin that does something strange, but I dont think we need to cover that case. (We could add this to our browser support page)
  • Doesnt always work: There are many quotes like this "Referer checking can detect some attacks but not stop all attacks", but after much searching I find no reference to anything besides the above items - in other words things that are not a problem for us. I have seen no indication that a referer can be spoofed in a CSRF context.

Competitor research

Most of our competitors rely on the synchrnonizer-token approach. 

The following CMS that I checked all support Token based authentication:

(As far as I can tell it is for their admin interface - but could be referring to the public website in some cases.)

For these I could find no clear information.

  • Coremedia
  • Drupal

I also found several indications that the token check was something that they have added relatively recently. For example AEM had referer check before and then added the token check.

Security Software

Also security scanning software is apparently looking for CSRF tokens on forms.

Ive seen these two mentioned.

Conclusion

Based on the above, I think it is most important that Magnolia is percieved well and adheres to the established best practices. While our referal protection is good, it is not generally accepted and therefore will be mistrusted in many secuirty audits. In brief - many customers and potential customers will trust the OWASP page more that they will trust our reassurances that our system is secure.



  • No labels

7 Comments

  1. > I think that we should implement synchronizer-token authentication on Magnolia admincentral

    Christopher Zimmermann, this is unclear to me. The page references initially the issue related to pre-Vaadin UI which might be vulnerable to CSRF without additional care. Vaadin itself provides a token-based protection (see https://vaadin.com/framework/security) and what is more - CSRF filter bypasses admincentral requests whatsoever and generally seems to be obsolete. Why do we need to provide anything on top of it?

    1. OK I had forgotten that Vaadin was immune. My research was just based on the main claims in MAGNOLIA-6865 which are possibly inaccurate or confused.

      So I guess the CSRF filter is now just for any "legacy" style apps running under /.magnolia, is that how you understand it? That would be the only reason for keeping it?

    2. As I look through those tickets, I'm thinking now that people want CSRF protection on their "public" websites. That they have a public website with a login area and maybe some forms there and are getting CSRF alerts from security tools on those.

      1. yeah, think the same (comment below, which I can't delete and move to the correct chain for some reason)

        1. When we implemented it - it was just about admincentral - but in the review I did recently, some of our competitors do provide some level of support for CSRF on the public site. This makes sense, and I think we should do it, as always its a question of priority. Lets get back to the customers and clarify where they need it.

          1. Looks like 'form' is the one which need CSRF token, in Spring Framework, they supported this by adding a simple tag in the form which automatically generated a hidden field that includes the token. Another possibility is to use page header or cookies for token storage and transfer between client and server, they have pros and cons but why not supported both like any other frameworks (wink)

    3. Aleksandr Pchelintcev, CSRF token is not enough if I 'translate' my support ticket correctly. Since the token could be hi-jacked and reused by a man in the middle, so you are encouraged to also verify the 'referer' or the origin of the token who sent it to server. If it is the same origin or 'referer', then it's the one that we sent the token to. Eventhough this is not a 100% secure, it increases the CSRF token protection to a next level of security.