Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persistent XSS - GetSimpleCMS 3.3.5 #1046

Closed
joelvadodil opened this issue May 20, 2015 · 7 comments
Closed

Persistent XSS - GetSimpleCMS 3.3.5 #1046

joelvadodil opened this issue May 20, 2015 · 7 comments
Labels
Milestone

Comments

@joelvadodil
Copy link

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

@joelvadodil joelvadodil changed the title Persistent XSS Persistent XSS - GetSimpleCMS 3.3.5 May 20, 2015
@tablatronix
Copy link
Member

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

Where are you injecting this ?
content ?

@joelvadodil
Copy link
Author

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
Copy link
Member

Thanks

@tablatronix
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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

@tablatronix tablatronix added this to the 3.3.6 milestone Jun 18, 2015
tablatronix added a commit that referenced this issue Jun 18, 2015
adds new xss_clean filter for testing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants