There is a stored xss security vulnerability on version 2.4.1

[nibiwodong]

If the source feed include malicious script code, these code can be introduced into users webite。 for example, the source feed include html encode code like this:

<pre>&lt;pre&gt;&lt;code&gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;&lt;/code&gt;&lt;/pre&gt;</pre>

It can display correctly in source website. But the content of this feed extracted by wpematico is wrong. wpematico decode html content which lead to stored xss vul.

I only test on version 2.4.1, this vul may exists in previous versions.

[etruel]

Hello @nibiwodong,

Really thanks for this report.

There are some things to consider before thinking about a vulnerability. First the feeds are external to the plugin and those that are used must be "Trusted" and with the consent of the user. Then if you still want to use these types of feeds, you have different options that you can use to filter or not the obtained content.

The plugin analyzes the content using the current Wordpress filters for the "Visual" tab of the post editor. If you use strip tags you remove all the malicious code. Also using Strip links->scripts you remove all the malicious code.

If you want the unfiltered code as you get it there is an advanced option in Settings "Allow option on campaign to skip the content filters". This option will enable another option in the campaign called "Post Content Unfiltered. This option allows you to skip the Wordpress post content filters and will save the content exactly as the plugin get it from the feed item.

This was no tested for your feed as we don't have it. You should try the options.

regards

[nibiwodong]

Hi, @etruel

Thanks for the clarification. I think we have different assumptions on the “trusted” feeds. Sometimes, the feeds source is trusted, for example, we normally trust some recognized security blogs. However, bloggers may post articles on xss which contains malicious code in the article as examples to demonstrate how xss works.

Under the default setting of wpematico, Strip links from content->scripts and Strip All HTML Tags are not selected. In such case, the malicious code will be extracted to a new article and run as well.

Let’s reply the process of my test case.

First, I posted an article on wordpress using standard editor with the content as follows: <script>alert(document.cookie)</script> And the feed content is: <p> &lt;script>alert(document.cookie)&lt;/script> </p> As wordpress editor has encoded the script into html, xss won’t work.

As instructed by your method, I configured Strip links from content->scripts. All the xss script code is filtered and doesn’t show up in the new article. If I configured Strip All HTML Tags, the filtered content was alert(document.cookie)

I checked the source code and found that line 335 in campaign_fetch.php seemed lead to xss attack. $this->current_item['content'] = html_entity_decode($this->current_item['content'], ENT_COMPAT | ENT_HTML401, 'UTF-8'); This code decoded the content from html to plaintext, and caused xss attack.

I tried to rewrite the code as follows: $this->current_item['content'] = $this->current_item['content']; The new article contains the full content without xss attack. Please verify whether it’s necessary for html decode.

When I select Post Content Unfiltered option, the xss script can worked as well. At line 585 in campaign_fetch.php，set unfiltered content $truecontent to current_item[‘content’], $this->current_item['content'] = $truecontent; but the param $truecontent has been decoded from html to plaintext at line 335.

Above all, there are two security problems with wpematico: 1.The defaulted setting may cause xss attack if there’re malicious codes in the original article; 2.When Html_entity_decode function decodes the content, it can cause xss attack. Please verify whether it’s necessary for html decode.

[etruel]

Hi @nibiwodong, I think you're right. Although there are some users who receive the entities encoded in the contents in their trusted feeds and must make decode to get the proper content.
But it should not be activated by default and to solve both cases we have added an option in Settings that users who need (and want), can activate from there. I've just pushed a new alpha version with this option. If you update you should get it working as you said without touch anything more. We hope release the official version in wp repo in few days. Thanks! Esteban