mailing list archives
RE: XSS hiding CSRF (was: Re: [oss-security] Mibew messenger multiple XSS)
From: Carsten Eiram <che () secunia com>
Date: Thu, 2 Feb 2012 07:25:37 +0000
The points made by Steve are why we're spending so much time testing everything we can get our hands on. It's standard
operating procedure - and has been for many years - to particularly pay attention to these "XSS hiding CSRF" cases. For
that reason you'll often see discrepancies in the original report and the released Secunia advisories.
In the case of Mibew, the functionality is restricted to admins and from an administrator's perspective there is no
gain. Therefore, we do not consider it a vulnerability in itself. However, via the CSRF vector it can be exploited by
non-admins. This is why the Secunia advisory is rated as CSRF (like the OSVDB advisory) and just mentions XSS as a
follow-up impact (along with alternatively just changing the administrator's password and gain full access that way).
I would definitely join Steve in encouraging researchers to keep this trend in mind by considering a) if a discovered
issue actually provides a gain compared to legitimately accessible functionality and b) relies on another vulnerability
in order to be an issue. We encounter these "XSS hiding CSRF" cases on a weekly basis.
Med venlig hilsen / Kind regards
Carsten H. Eiram
Chief Security Specialist
Follow us on twitter
Rued Langgaards Vej 8
2300 Copenhagen S
Phone +45 7020 5144
Fax +45 7020 5145
From: Steven M. Christey [mailto:coley () rcf-smtp mitre org]
Sent: 1. februar 2012 23:24
To: oss-security () lists openwall com
Cc: Henri Salo; filippo.cavallarin () codseq it
Subject: [oss-security] XSS hiding CSRF (was: Re: [oss-security] Mibew
messenger multiple XSS)
Funny, the CVE team was discussing this curiosity just today.
In the Mibew case, the PoC code has POST forms that invoke scripts like
"/operator/ban.php" and "/operator/settings.php". These are almost
certainly administrative functions that probably shouldn't be reachable at all.
Thus, these might be better identified as CSRF issues at their core, instead of
It seems that some researchers report XSS in administrator modules, but
they omit when you need to use CSRF in order to get the administrator to
perform the XSS. So, the primary issue is often CSRF, and XSS is only
resultant (since, in many cases, the admin already has privileges to edit
HTML). The vuln DBs are starting to catch up with this "trend" in vuln
reporting, so there is a very slow shift towards identifying CSRF as the core
problem. However, CSRF is in the eye of the beholder, in that you often
need to know the INTENDED functionality of the application before you can
interpret whether things are CSRF versus regular functionality, versus good
Note that this kind of XSS-hiding-CSRF issue is not necessarily tied to admin
functionality, but that's where it's a strong indicator that a researcher might
be ignoring CSRF.
Sometimes, though, it can be difficult to determine whether XSS or CSRF is at
the root, even if you're dealing with admin functionality. For example,
maybe an admin program will check for CSRF and fail, but include the original
form in its error response, possibly enabling XSS. Or, maybe there are TWO
issues at play - maybe a victim can be CSRF'ed to make posts on their behalf,
and also a secondary issue where the victim can become an attacker and XSS
other people (with or without CSRF).
Unfortunately, I strongly suspect that the number of XSS-hiding-CSRF reports
will grow :-(
For people who investigate vuln reports closely, please keep this trend in
mind. If you are a researcher, consider whether XSS or other issues are really
legitimate functionality that is only reachable by targeting the victim with
CSRF; if that's the case, then the CSRF is "primary" and the XSS is "resultant"
and not a separate vulnerability - and if your targeted application has CSRF,
then maybe there's a more powerful impact than just XSS. (For example,
depending on how settings / configuration is implemented, you might be
able to get code execution out of it.)
On Wed, 1 Feb 2012, Kurt Seifried wrote:
On 01/31/2012 08:22 AM, Henri Salo wrote:
This seems to need 2012 CVE-identifier.
Codseq own advisory:
At the moment http://mibew.org/ does not work for me.
- Henri Salo
Please use CVE-2012-0829 for this issue.
P.S. for some reason OSVDB lists this as a CSRF issue (?) which is
mentioned in the advisory but not really shown.
Kurt Seifried Red Hat Security Response Team (SRT)