13 Apr

Vulnerability Details: Authenticated SQL Injection Vulnerability in Gallery – Video Gallery

This Vulnerability Details post about a vulnerability in the plugin Gallery - Video Gallery provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can access this post for free when signing up today. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

4 thoughts on “Vulnerability Details: Authenticated SQL Injection Vulnerability in Gallery – Video Gallery

  1. I think it is worth noting that the incorrect escaping functions are being used for some of the values. Of course, it would be better to use `$wpdb->prepare()`, but `esc_sql()` is superior to `esc_attr()`, since it uses `mysql_real_escape_string()`, which takes into account the charset of the database connection. Otherwise it is possible that depending on the charset, SQLi might still be possible. (I haven’t tested or looked in depth at `esc_attr()` and `esc_url()` to be sure.) See http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

    • We noticed that as well, but since they are using esc_sql in some places it would seem that they are aware of the function and could have used it instead in other places as well, so we didn’t assume that it is an issue here. If you can find something exploitable you should let the developer know and post a follow up comment here, so that we and others can learn from that.

      • After looking at esc_attr() and esc_url() more closely, it doesn’t appear that they are vulnerable to that kind of attack, because they encode the single quote rather than slashing it (or just reject an invalid character completely). So it *appears* to be safe to use them here, though I’d say its inadvisable.

        • Agreed. As the documentation says (and you mentioned before) using esc_sql() instead of $wpdb->prepare() isn’t recommended in nearly any case:

          In 99% of cases, you can use $wpdb->prepare() instead, and that is the recommended method. This function is only for use in those rare cases where you can’t easily use $wpdb->prepare().

Leave a Reply

Your email address will not be published. Required fields are marked *