#2072 - Cross-site Request Forgery (CSRF) Vulnerability in Composr 9.0.21
| Identifier | #2072 |
|---|---|
| Issue type | Major issue (breaks an entire feature) |
| Title | Cross-site Request Forgery (CSRF) Vulnerability in Composr 9.0.21 |
| Status | Completed |
| Handling member | Chris Graham |
| Addon | news |
| 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. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
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.
I will run more tests for a possible fix.
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.
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.
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.
http://compo.sr/site/news/view/chris_grahams_blog/security-fix-for-csrf.htm