Persistent XSS - GetSimpleCMS 3.3.5

[joelvadodil]

Hi team,

It was observed that GetSimpleCMS 3.3.5 is vulnerable to persistent XSS. If you add any new page and in the edit page header & body if you pass the payload and save, it gets executed for all the users.

URL - http://localhost/Getsimplecms-3.3.5/admin/edit.php?id=temp&upd=edit-success&type=edit
Payload - ">img src="blah.jpg" onerror="alert('XSS')"/

Add < before img and > at the end.
Please assign a CVE-ID for the same.

Thanks,
Joel

[tablatronix]

assuming payload is
><img src="blah.jpg" onerror="alert('XSS')"/>

Where are you injecting this ?
content ?

[joelvadodil]

Parameters - post-content and post-title

On Wed, May 20, 2015 at 6:37 PM, Shawn A notifications@github.com wrote:

assuming payload is

Where are you injecting this ?

—
Reply to this email directly or view it on GitHub
#1046 (comment)
.

Regards,

Joel V

[tablatronix]

Thanks

[tablatronix]

All inputs are susceptible to this, our filtering functions do attempt to safe slash escape stuff, but our output functions just revert this mostly due to some old output functions used for cleaning up xml stored html

menu title for example is also persistent on all pages , as well as probably all settings inputs.

function strip_decode($text) {
    $text = stripslashes(htmlspecialchars_decode($text, ENT_QUOTES));
    return $text;
}

#1047

Dealing with js in content is another issue, real purifiers are needed to filter that, perhaps hooks for plugin secfilters is preferred here.

Sanitizing the title fields is somewhat problematic also, in that traditionally we allowed html in these inputs, and this might break backwards compatibility. sooo.....

[joelvadodil]

So how r u planning to resolve this issue?

On Wed, May 20, 2015 at 9:13 PM, Shawn A notifications@github.com wrote:

All inputs are susceptible to this, our filtering functions do attempt to
safe slash escape stuff, but our output functions just revert this mostly
due to some old output functions used for cleaning up xml stored html

function strip_decode($text) { $text = stripslashes(htmlspecialchars_decode($text, ENT_QUOTES)); return $text;}

—
Reply to this email directly or view it on GitHub
#1046 (comment)
.

Regards,

Joel V

[tablatronix]

not sure yet

In 3.4 probably remove all invalid chars using a string filter and no longer allow html in non content inputs. Mitigate 3.3.x somehow, escaping for output function get_title etc.

And add better basic xss filtering, and hooks for advanced xss filtering or html purification using external libraries such as htmlpurifier.

[joelvadodil]

ya..that should work out..will you be applying for a CVE-ID for this issue?