View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 2072 | Composr | news | private | 2015-11-12 12:42 | 2015-11-12 18:03 |
| Reporter | Guest | Assigned To | Chris Graham | ||
| Priority | high | Severity | major | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 2072: Cross-site Request Forgery (CSRF) Vulnerability in Composr 9.0.21 | ||||
| Description | CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. Attacker creates forged HTTP requests and tricks a victim into submit. If the user is authenticated, the attack succeeds. | ||||
| Steps To Reproduce | 1) Logon into Composr application (localhost or public host) 2) Go to Content management->News->Add news fill up the form and capture the request in intercepted proxy (Burp suite) 3) Now, Generate a CSRF Request with logged in user account 4) Modify the request with the payload that the malicious user wanted to execute on victim user account and send the page to the victim. 5) Now, once the victim opens the page generated by an attacker in his/her browser then the added payload will get executed and the required changes will be made to the victim’s account. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Attached Files | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
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 |
