ygirouard

Look at filemanager/model.php, lines 242 and 290. Both call get_var with an unsanitized query using potentially uncleaned variables. The other instances where you are also calling get_var you DO use the prepare method to clean the query.

• This reply was modified 2 years, 4 months ago by ygirouard.

That is not true. Multiple images have single quotes in our libraries created with version 1.2.6 (very old) and we can’t upgrade because of this, and if you look at your model.php file where the function is used, you are passing an uncleaned sql query directly to the $wpdb->get_var method, and this method does NOT do any cleaning as opposed to other ones like insert, update and delete. You need to first prepare the query and use the prepared one in the method. Please revise your code, it’s been in there since somewhere after 1.5.0 and before 1.5.87, I haven’t checked them all …

Not only insert, delete and update methods have to be sanitized by the way, selects also!

• This reply was modified 2 years, 4 months ago by ygirouard.
• This reply was modified 2 years, 4 months ago by ygirouard.
• This reply was modified 2 years, 4 months ago by ygirouard.

After further reading on the subject, it seems that the wpdb::get_var method does NOT do proper escaping by default, as opposed to the insert, delete and update ones, and so, would need to be sanitized using the wpdb::prepare method before they can be used.

As read from a Stackoverflow post:

As I understand – the methods those have placeholders for query parameters ($wpdb->insert(), $wpdb->update(), $wpdb->delete()) don’t need the $wpdb->prepare() method, and they are already safe.

But the others – those don’t have placeholders, need additional sql escaping.

When I check the model.php file of the plugin, I don’t see any escaping being done anywhere where the get_var method is being used! This could lead to SQL Injection and has actually been flagged by Tenable Nessus in a recent security analysis. I have checked several previous versions of the plugin and it has been around for several versions, probably around the time the files_parsing_db() function was added to the model.

@otto42: with over 2 million users of the plugins to block and disable Gutenberg, and the countless posts on this forum about it being garbage, I would say otherwise, but as I said, I guess it’s a question of perspective. I did try it and I don’t like it at all, and certainly don’t agree that it is “needed”.

@otto42: The maintenance of the code is precisely the problem. Being maintained by community members, those plugins are much more at risk of breaking between WordPress releases and having to depend on “some guy” to have the time to update his plugin quick enough is a huge risk for any serious production WordPress site.

As for being a “niche” feature, you could say that about Gutenberg as well, yet, it was added to the core and nobody asked for it or needed it. I guess it’s all a matter of perspective, but that’s another topic… ??

Would like to know this as well!

It only takes a minute or two of browsing this forum and a bit of Google search to see that this new version is clearly not appreciated anywhere by anyone other than maybe new WP users that don’t know any better.

Quite a lot, many thousands in fact. Just look at the count of active installs for all those plugins https://www.ads-software.com/plugins/search/LDAP/.

If anything, it could be an official wordpressdotorg plugin that you can optionally install, but is guaranteed to always work with all releases.

External LDAP authentication (or AD integration) is pretty much basic stuff for an enterprise site.

• This reply was modified 5 years, 11 months ago by ygirouard.