This is a spacer post for a website comment topic. The content this topic relates to: #2072 - Cross-site Request Forgery (CSRF) Vulnerability in Composr 9.0.21

You are posting issues *PUBLICLY* on the issue tracker, you mustn't do this -- it is not responsible disclosure to do so.

When you post an issue there is a field to say whether it is public or private.

That said, I don't believe there is a security hole here. Composr does referer checks. Where are you executing the malicious HTML from? If you uploaded it to the server to run (localhost in your case), then the hacker would not normally have access to do this.

Additionally, the target would have had to authorise a new session, a stale cookie login would not be enough.

I will do some checks to confirm that the referer check is working from a non-HTTP[S] context.

Ok, I can confirm local HTML files (not localhost, but file system access) are not producing any referer, in Chrome at least.

I will run more tests for a possible fix.

I can also see "View status" is not an option for guest posting of issues, so I now see why you didn't use the private posting. I will look at this also.

So just to clarify:
1) Yes, actually this is a legitimate issue
2) We have an issue with our tracker process for private issues, likely we need to configure to allow anonymous users to post such issues

Thanks for your report.

Further research shows HTTPS to HTTP links don't pass referers, so this is a bigger issue than thought. A hacker could just host on an HTTPS link.

Locally it was not thought such an issue because JS execution is blocked for local HTML (needed for automatic form submission). However testing shows this is not actually the case, only IE prevents this.

A fix is about to be posted.

This fix adds checks for blank referers if it has found that particular browser has had referers before.

It is important to note when re-testing that one native click within the system is needed for the "has_referers" cookie to get set. In any realistic attack scenario this would already have happened.

The fix cannot protect if some kind of firewall is always stripping out referrer headers. However we already advise against allowing such scenarios in our documentation.

The fix cannot protect if cookies are being blocked.

In any case the attack only works if targeted against an actively logged in browser session (not just having login cookies saved).

Our v10 is adding optional post tokens. We haven't done these in earlier versions as they make customisation much harder for people, while referer checks are stabler in a broaden set of customisation scenarios. But for v10 they will be there and optional.

Fix posted at:
http://compo.sr/site/news/view/chris_grahams_blog/security-fix-for-csrf.htm