13 Apr

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

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to identify additional vulnerabilities in ...

Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

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 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 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 *