WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#11701 closed defect (bug) (worksforme)

Constructing URIs using the slug (post_name) can result in arbitrary characters being passed through to the final HTML

Reported by: jaylett Owned by:
Milestone: Priority: low
Severity: normal Version: 2.9
Component: General Keywords:
Focuses: Cc:

Description

The characters in post_name are assumed to be safe for passing directly into a constructed URI (typically a permalink). The expected behaviour is for anything that is not valid directly in a URI to be suitably escaped, and then for the URI to be HTML entity escaped.

If the post_name contains say "> then the anchor tag emitted is terminated and the rest of the post_name will be displayed.

If the post_name contains say &lt; then the URI that is followed by the web browser will contain < rather than the literal &lt;.

(This is a niche case that I know should never happen because of input validation / construction of post_name.)

Change History (7)

comment:1 @miqrogroove6 years ago

should never happen because of input validation

Right. So you're reporting that this isn't broken? I don't get it.

comment:2 @miqrogroove5 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

Closing due to silliness and lack of feedback.

comment:3 @nacin5 years ago

  • Milestone Unassigned deleted

comment:4 @jaylett5 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

[Hadn't previously set an email address on my account, so didn't get notification of an update to this.]

Re-opening to state my position somewhat more clearly:

  • it's niche because input validation means that Wordpress will not construct such a post_name in the normal course of events
  • however niche doesn't mean irrelevant; by "…should never happen…" I really mean "…should never happen in the vast majority of cases…"
  • in particular I don't believe that the data model is sufficiently protected to be able to state that this is an invariant; it's more of a hope
  • in any case, even if that weren't the case, I'd expect documentation (in wp-admin/includes/schema.php) of this invariant

At the moment, it's too easy for import utils, or plugins doing freaky things, to get this wrong. I'm arguing strongly for ensuring that no matter what going into the database, the output layer doesn't break *and additionally* for suitable input sanitisation (which is already in place here).

comment:5 @miqrogroove5 years ago

jaylett, you haven't identified any bug in WordPress. What is the purpose of this ticket?

comment:6 @jaylett5 years ago

I suspect we have a philosophical difference over what constitutes a bug. Feel free to close this again if you genuinely believe that having a system that can spit out invalid HTML based on a poorly-constructed post_name (such as by an overly-pushy plugin) is fine.

comment:7 @miqrogroove5 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

jaylett, you said in the ticket description that the input validation is working correctly and prevents invalid HTML, you haven't described any way to produce invalid HTML, and thus there is still no bug here. That is not a philosophy. There is simply no useful information in this ticket.

Note: See TracTickets for help on using tickets.