0

There is a tutorial on TutsPlus → https://code.tutsplus.com/articles/data-sanitization-and-validation-with-wordpress--wp-25536

Rule No. 4: Making Data Safe Is About Context

They says that this is completely a safe HTML

<textarea name="my-textarea"></textarea> Hello World

This is perfectly valid, and safe, HTML – however when you click save, we find that the text has jumped out of the textarea. The HTML code is not safe as a value for the textarea:

You can see later they contradict. However they have not provide reason why it was safe then how come in wordpress widget text area it becomes Unsafe and why and what the alternative method could be to make it safe.

I think they were trying to prove something that something may be correct in one place, but not in another.

they didn't give any explanation that If the data was safe then why does "hello world" came out of the form/box.

Can some one please help me to understand it thoroughly? Can some one show me How could that example be made safe?

closed as off-topic by Mark Kaplun, jgraup, cjbj, Dave Romsey, bueltge Nov 3 '16 at 7:30

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • yes, they did. It's bad HTML: <tag attribute="this-has-different-content"></tag> Than the stuff that was supposed to go in the "tag" – jgraup Oct 28 '16 at 1:26
  • sorry, but I don't see how this is wordpress specific. . – Mark Kaplun Oct 28 '16 at 5:42
  • .... after looking at the article you linked to, the problem with your question is that questions should be self contained, and you should not assume anyone will bother following the links. People are answering here for free, don't waste their time.... – Mark Kaplun Oct 28 '16 at 5:47
2

I'm the original author of that article, hopefully I can elaborate on my point ("Rule 4").

The 'data' in this case is the value entered by the user:

$raw = '<textarea name="my-textarea"></textarea> Hello World';

There are two contexts in which we display this data in some form:

  1. The front-end view, where we wish to render the HTML entered by the user
  2. The widget admin view, where we wish to allow the user to view and edit the HTML they have entered.

For (1), we might doing something like the following:

class My_Widget extends WP_Widget {
   ...
   public function widget( $args, $instance ) {
    // outputs the content of the widget
    ...
    echo $raw;
    ...
   }
   ...
}

This is 'fine'. Normally we might not want the widget editor to be able insert iframes, script tags or unbalanced HTML - but here, for illustrative purposes, we're being entirely permissive. The point is when we're printing a variable's content to be rendered as HTML in a HTML page we don't need to escape anything.

But, we have to treat the same variable differently when we wish to display it in a different format (i.e. we wish to print the mark-up inside a teaxtarea rather than actually render it as HTML).

class My_Widget extends WP_Widget {
   ...
   public function form( $instance ) {
    // This is wrong!
    ...
    echo '<textarea>' . $raw . '</textarea>';
    ...
   }
   ...
}

In the above we want to display the mark-up not render it, but we not doing anything to prevent $raw being interpreted as HTML. This is dangerous; HTML is not safe as a value for the textarea. While for most HTML, it will display as intended, if it contains </textarea> the form will 'break', and inject HTML into the widget admin page, as demonstrated in the article.

Escaping in this context, means preventing $raw being interpreted as HTML. There's a useful function WordPress provides for this instance:

class My_Widget extends WP_Widget {
   ...
   public function form( $instance ) {
    // This is wrong!
    ...
    echo '<textarea>' . esc_textarea( $raw ) . '</textarea>';
    ...
   }
   ...
}
  • +1 but this has nothing to do explicitly with security. doing unescaped output might be a big bug visually but one that can not be exploited. For example a site with only one owner/content writer, in which case he is unlikely to try to exploit this weakness to take control over his own site, while others will not be able to exploit it without first getting admin acces – Mark Kaplun Oct 28 '16 at 9:24
  • .... or in other words, it is always about the context, an admin can do whatever he wants no matter how crazy it is, while comments should be sanitized to death if it is needed – Mark Kaplun Oct 28 '16 at 9:28
  • Thanks, but whats the Problem in this website. You post questions and people vote it down. – The WP Novice Oct 28 '16 at 9:28
  • @MarkKaplun cannot be exploited? You've made a lot of assumptions about the site or the goal of the attacker. For instance, with a multisite, the blog admin is not necessarily someone who should be allowed to anything they want. – Stephen Harris Oct 28 '16 at 10:31
  • I said in a "one user site" context right there ;). Can't be exploited even if it is a multisite. It depends on who authors the content, blanket statement like X is always bad usually are too broad. – Mark Kaplun Oct 28 '16 at 11:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.