Support

Account

Forum Replies Created

  • @nickfmc – thanks for raising this again. It’s certainly a valid and topical point. In essence, EVERYTHING should be escaped on output – as per earlier links in this post.


    @elliot
    as per previous comments, I think it’s really crucial that the documentation is updated to make users aware that data is not escaped automatically (& indeed, couldn’t be, as it will depend on context).

    Thanks,
    Sarah

  • Trying to add some custom .js validation (as per the above) on a front end form, but can’t get it to work. Where should this code go?

    I’ve tried adding inline on the form page, and also as a separate script via wp_enqueue_scripts action, but no joy?

    Thanks!

  • Thanks. I have done some initial testing.

    If one has a front end form with text field, a malicious user could potentially input <script>alert('You've been hacked');</script> and if echo get_field or the_field is used to output that field, the script will then run.

    As far as I understand it, one would therefore use echo esc_html (get_field(..)); to escape the data on output (or esc_attr, esc_url, etc as appropriate)

    I think this needs highlighting right at the top of your Front End form ‘how-to’!

    What I have yet to establish is whether any additional sanitization needs to be done before the data is input to the database. According to http://codex.wordpress.org/Class_Reference/wpdb#UPDATE_rows, $wpdb->update takes raw input values (they should not be SQL escaped) – so perhaps that’s enough?

    The only thing that bothers me is that potentially one could then still end up with malicious js script in the db – maybe the answer is to use esc_html on input to db as well as output.

    Any further thoughts welcome…

  • Ok, done some more digging/reading.

    The sanitize_meta function I mentioned above simply adds a filter that you can then hook to do custom sanitization. As per the codex function – it doesn’t do any sanitization itself. So that’s kind of irrelevant.

    However, further down, the actual DB update is done using $wpdb->update, which does escape the data.

    What I’m not entirely sure yet is whether one then needs to do any additional sanitization. Also whether I’m ok to use the_field, get_field etc as-is when outputting data, or whether these need escaping?

    This post was helpful: http://wordpress.stackexchange.com/questions/44807/sanitize-vimeo-embed-code

  • Hi Elliot,
    Many thanks for the quick response.
    I’ve had a look at update_postmeta in post.php, which in turn calls update_metadata in meta.php.

    update_metadata calls a sanitize_meta function (also in meta.php), but what I’m not sure is what this does exactly – this is the function:

    function sanitize_meta( $meta_key, $meta_value, $meta_type ) {	        return apply_filters( "sanitize_{$meta_type}_meta_{$meta_key}", $meta_value, $meta_key, $meta_type );
    }

    According to Codex:

    ‘Applies filters that can be hooked to perform specific sanitization procedures for the particular metadata type and key. Does not sanitize anything on it’s own. Custom filters must be hooked in to do the work. The filter hook tag has the form “sanitize_{$meta_type}_meta_{$meta_key}”. ‘

    But this is where I get a bit lost… does this mean data is being sanatized or not?!

    Also – do you know whether it’s just update_postmeta I need to worry about, or are there any other methods used too?

    Many thanks for your help.
    Sarah

Viewing 6 posts - 1 through 6 (of 6 total)