Kylen Downs
Forum Replies Created
-
The filter does seem like an easy solution for our use-case! I’ll take a look at the repo and see if there’s anything that we might be able to benefit from in our use-case and open up a pull request if so.
I appreciate the support! We’ve been using the plugin since about 2017 in our multisite installations and it’s been a great tool!The subsites in the network intentionally have access to specific modules blocked due to either incompatible requirements for the module (i.e. backups) or other theme/plugin compatibility conflicts. To avoid known conflicts or limitations with certain modules, we block specific ones at the network level to avoid confusion and/or limit the potential “upsells” Jetpack/Automattic tries to offer for certain services that are not supported with our multisite.
Digging into the plugin code a bit, something that might be helpful in our (maybe unique) use-case could be to add an apply_filter for the return array inget_available_modules()as it would allow us to hook into the list and manually add our own ‘known’ modules to avoid the dependency of needing Jetpack active on the primary site or network-active. That way we could maintain it a little more manually without the requirement for you to keep up on the static $know_modules array unnecessarily and without the req of Jetpack being active in the context of a MS network.I think I found the issue. We are on 1.6, correct.
The issue with those missing modules appears to be related to the Jetpack plugin not being network active or active from the primary blog in the network. We provide the Jetpack plugin as an opt-in plugin for subsites in the network and do not use the primary site for anything other than facilitating the actual network management.
I noticed the missing modules were available when either network activating Jetpack or activating the Jetpack plugin on the primary site.
With this information, I think the solution might be to activate the plugin on our other multisite networks in the primary site and the blacklist the modules. But it may be a nice feature to blacklist modules without that requirement if possible.
I appreciate your time!This is the apparent new module but it’s not listed in the “Module Control for Jetpack” blacklist settings.
Module Control for Jetpack is up to date running v1.6 and Jetpack running v14.5.
Object cache is not enabled and we don’t run caching plugins in the network.Thank you! I ran through those steps and discovered the issue appears to be present when the CoSchedule plugin is active. The plugin is running 3.3.9 and does not have any pending updates at the time of this message.
I’ve left CoSchedule deactivated for now but are you aware of any conflicts with that plugin or with specific versions of that plugin? This might stretch outside testing cases but I’m curious if there may be an awareness of any potential issues.@wfpeter Is this something you guys are still looking into?
Hi @wfpeter,
Any updates on this? The diagnostic email was sent over a few days ago.I apologize, I missed the response notification from your first message. The diagnostic email has just been sent.
Forum: Plugins
In reply to: [Secondary Title] Cross Site Scripting (XSS) vulnerability ?I reached out to Kolja directly in email and WordPress slack but have not yet heard back. I made a pretty basic fork of the plugin at https://github.com/kylendowns/secondary-title/tree/antixss which implements an antixss package to protect (only) the html output. It still could use some refinement (which I’m messing with on the side) so I might not recommend this as an official solution, but it might be a decent option in the meantime if wanting to implement some form of XSS protection while continuing to use the plugin.
Forum: Plugins
In reply to: [Secondary Title] Cross Site Scripting (XSS) vulnerability ?Hey @thaikolja, I just wanted to say I appreciate supporting the plugin up to this point. I wanted to attempt to provide some assistance with solving the issue where I can, but you would probably have the most insight into things.
The only details on the vulnerability I could find was from the WordFence article where it mentions:
“with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page”
https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/secondary-title/secondary-title-2091-authenticated-contributor-stored-cross-site-scriptingI pulled the code down from Github and have been looking into it. As far as I’ve been able to determine, there is nothing that sanitizes or filters user input into the
_secondary_titlemeta field. This might be intentional to allow for user input to include raw html for formatting purposes, but it does also allow for user input to include something like<script>alert(‘XSS’)</script>or<iframe src="https://ww.wp.xz.cn/"/>which is the concern for XSS.The
secondary_title_auto_show()function is what renders the subtitle in, what I assume, most cases. Inside that function, the code essentially just appends the raw (html decoded) subtitle into the new title string and is returned as the unfiltered output to the frontend.Both the unfiltered input and the unfiltered output is where the XSS concern appears to be present. That and the fact that a contributor has the capability to inject whatever they want (despite not being able to publish) is probably not ideal.
I think there are two possible solutions to this. But I’m unsure on the original intent for what you want a user to be able to do. The plugin settings page is only accessible to users with manage_options perms so it could be an option to simply restrict any styling/html input to the settings page.
Regarding actual filtering of the input/output the
_secondary_titlemeta, the first option would be to filter the user input. Thesecondary_title_edit_post()function does useesc_attr()on the user input to encode html entities but there is no additional input filtering or validation that prevents users from injecting whatever else they want into the DB. All it does is encode the input. A basic option could be to usestrip_tags()which would prevent html tags specifically but the effectiveness of that option for XSS is limited by itself. A combination ofstrip_tags()andesc_html()can clean up input to an extent.The second option would be to capture and filter the output using similar methods and ensure the
_secondary_titlemeta is not returned as decoded html that could contain XSS routes. Keeping the the data encoded, stripping tags, or implementing some other data filtering on the output should also resolve the issue with XSS.Hope this helps!
Cheers! I appreciate the plugin and support, you guys are awesome!
As better solution than the one I provided, I might suggest actually naming the custom cleantalk column as I can foresee potential conflicts if the logic is left as targeting the int(0) value. By naming the column, it can ensure the if() statement targets the specific cleantalk column to avoid the
echooutputting on a different custom column if that other column also happens to be unnamed.Looking into this locally, the apbct__manage_sites_custom_column_action() function on cleantalk-spam-protect/inc/cleantalk-admin.php:1244 is not passing any sort of validation or check on $_column_name which means the output is occurring on all custom columns.
The cleantalk status column does not have a specific name, but it can be validated against the int(0) with this replacing line 1261:
if ($_column_name == 0){ echo $key_status_caption; }- This reply was modified 3 years, 7 months ago by Kylen Downs.
Complete deactivation and reactivation did not resolve the issue. It did clear out the status message for all sites except the primary site, however the message is still duplicated across multiple columns. The message also returns for subsites as soon as I logged into them.
I also reverted the plugin back to 5.186 and the issue is not present in that version, but as soon as the plugin is updated to 5.187 the issue returns.
Cheers! Looks like that fix is working. Thank you!