WordPress.org

Make WordPress Core

Opened 23 months ago

Last modified 13 months ago

#20771 reopened enhancement

esc_url() instead of esc_html() in wp_nonce_url()

Reported by: jkudish Owned by: SergeyBiryukov
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4
Component: Formatting Keywords: has-patch dev-feedback 3.6-early commit
Focuses: Cc:

Description

The wp_nonce_url() function currently uses esc_html() in its output, which doesn't really seem to be the appropriate escaping function since it's generating a URL.

Attached patch changes the output to use esc_url()

Attachments (2)

20771-1.diff (518 bytes) - added by jkudish 23 months ago.
20771-2.diff (19.2 KB) - added by jkudish 23 months ago.
remove all occurrences of esc_url( wp_nonce_url( ... ) )

Download all attachments as: .zip

Change History (13)

jkudish23 months ago

comment:1 follow-up: SergeyBiryukov23 months ago

  • Keywords 3.5-early added
  • Milestone changed from Awaiting Review to Future Release

wp_specialchars() was added in [3974] and changed to esc_html() in [11380].

In come cases, wp_nonce_url() result is already escaped with esc_url() on output:
http://core.trac.wordpress.org/browser/tags/3.3.2/wp-admin/includes/class-wp-ms-sites-list-table.php#L249

We should probably review all the instances.

comment:2 in reply to: ↑ 1 jkudish23 months ago

Replying to SergeyBiryukov:

In come cases, wp_nonce_url() result is already escaped with esc_url() on output:
http://core.trac.wordpress.org/browser/tags/3.3.2/wp-admin/includes/class-wp-ms-sites-list-table.php#L249
We should probably review all the instances.

We could remove all the uses of esc_url( wp_nonce_url( ... ) ), but there isn't anything technically wrong with escaping twice. It's being overly cautious for sure, but not "wrong".

That being said, the revised attached patch removes all such occurrences.

This got me thinking about something though... Is there a good reason why other functions that generate URLs (e.g. admin_url(), includes_url(), etc...) don't use esc_url() in their output?

Last edited 23 months ago by jkudish (previous) (diff)

jkudish23 months ago

remove all occurrences of esc_url( wp_nonce_url( ... ) )

comment:3 SergeyBiryukov23 months ago

  • Keywords dev-feedback added

comment:4 TobiasBg17 months ago

  • Keywords 3.6-early added; 3.5-early removed

This is probably too late for 3.5, due to implications that this may have. This should however be considered for early 3.6.

comment:5 SergeyBiryukov15 months ago

  • Milestone changed from Future Release to 3.6

comment:6 SergeyBiryukov15 months ago

  • Keywords commit added

20771-1.diff seems good.

Related: #23266

comment:7 SergeyBiryukov14 months ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 23411:

Use correct escaping function. props jkudish. fixes #20771.

comment:8 johnbillion14 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

This change has introduced an encoding bug, albeit an indirect one.

esc_html() encodes ampersands as & but esc_url() encodes ampersands as &. Passing a URL through add_query_arg() will mangle the URL if it contains ampersands encoded as &.

My User Switching plugin has broken since this change because the plugin uses add_query_arg() on a URL that's already been passed through wp_nonce_url().

Example:

$url = add_query_arg( 'action', 'foo', wp_login_url() );
$url = wp_nonce_url( $url, 'foo' );
$url = add_query_arg( 'redirect_to', 'bar', $url );

The resulting URL will end up as:

http://example.com/wp-login.php?action=foo&redirect_to=bar#038;_wpnonce=abc123

instead of:

http://example.com/wp-login.php?action=foo&_wpnonce=abc123&redirect_to=bar"

Notice that the _wpnonce parameter is stripped and treated as a URL hash instead of a query arg.

I'd like to recommend for now that r23411 is reverted. However, the core cause of the problem is due to the fact that wp_nonce_url() should be sanitising the URL but not encoding it. This means it should use esc_url_raw() instead of esc_url() or esc_html().

I'm going to open another ticket later today to address the core issue as it's present in several places but generally goes unnoticed.

Last edited 14 months ago by johnbillion (previous) (diff)

comment:9 nacin14 months ago

We should ideally fix add_query_arg() to work for both & and &. At a glance, though, I'm not sure I see where add_query_arg() handles the former even right now.

We should also consider just using & in esc_url(). I can't think of a particular context where esc_url() may be used (and esc_html() isn't) where & is not a recognized entity.

For now, I agree with revert. I have considered this change more than once, and each time, avoided it as something would break.

comment:10 nacin14 months ago

In 23637:

Revert [23411] until encoding differences are worked out. see #20771.

comment:11 ryan13 months ago

  • Milestone changed from 3.6 to Future Release
Note: See TracTickets for help on using tickets.