13 Apr

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

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a 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 *