It is quite simple; for uninformed users the three might be seen as different, but today they are the same. To explain it a bit: it is a persistent XSS. The attacker can enter it with a normal user account; however, it renders in the administration backend. Followed me so far? Great :)
So, to ward against CSRF, most web scripts employ tokens, which are required parts of requests that alter the software state. With a XSS, like the one detailed in my advisory, it is trivial to include a script that parses the html of the admin page and finds the token. So, our XSS leads to an universal CSRF. With that token in turn, it is easy to trigger a different administrative change (via AJAX), for instance one that introduces PHP into a template. RCE. So, with a persistent XSS that renders in an admin backend, you have RCE. Use XSS to bypass CSRF protection; use that to introduce code. XSS->CSRF->RCE. I would have stuck with one term, but security is not so simple today. A pleasure to be of service ~JC On Sun, May 3, 2009 at 11:19 PM, Andrew Farmer <[email protected]> wrote: > On 03 May 09, at 05:01, Jacques Copeau wrote: >> >> Advisory : “Cross-Site Scripting” vulnerability in MyBB > > <snip> >> >> The XSS renders in all browsers and on various pages inside the myBB >> software. >> We consider it to be particularly grave, as it renders on the ACP user >> overview >> page; this can be easily exploited to construct a universal CSRF >> vulnerability >> that introduces malicious php code into the script. > > So, er, is this vulnerability XSS, CSRF, or RCE? Pick one and stick with it. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
