Make WordPress Core

Opened 12 years ago

Closed 5 months ago

#24907 closed defect (bug) (fixed)

Escape admin_url() when used for ajax_url in admin header

Reported by: jeremyfelt's profile jeremyfelt Owned by:
Milestone: 5.5 Priority: normal
Severity: normal Version: 2.7
Component: Security Keywords: has-patch needs-testing
Focuses: Cc:

Description

As admin_url() is filtered right before returning, it should be escaped when output for use as the ajax_url in the admin.

Attachments (3)

24907.diff (780 bytes) - added by jeremyfelt 12 years ago.
24907.2.patch (1.4 KB) - added by c3mdigital 11 years ago.
json encode javascript variables output in admin header
24907.3.patch (1.4 KB) - added by aliso 11 years ago.
Adding esc_js to variable values to use in place of json_encode

Download all attachments as: .zip

Change History (11)

@jeremyfelt
12 years ago

#1 @c3mdigital
11 years ago

I think we should be json encoding PHP string variables when outputting to javascript. This eliminates the need for escaping and surrounding with quotes.

Version 0, edited 11 years ago by c3mdigital (next)

@c3mdigital
11 years ago

json encode javascript variables output in admin header

#2 @nacin
11 years ago

esc_url() isn't right, as it encodes ampersands for display. At most you'd want esc_url_raw() — but really, we're just looking to avoid issues with escaping data for a JS string.

@aliso
11 years ago

Adding esc_js to variable values to use in place of json_encode

#3 @helen
11 years ago

esc_js() seems sensible.

#4 @azaozz
11 years ago

esc_js() would work but is intended for escaping of inline JS. The _wp_specialchars() used there could break it. Don't think we have a suitable esc_* function when we echo arbitrary PHP strings inside a <script> tag.

#5 @chriscct7
9 years ago

  • Keywords needs-testing added

#7 @iandunn
6 years ago

  • Status changed from new to reopened

Reopening being this still seems like useful hardening.

#8 @SergeyBiryukov
6 years ago

  • Milestone set to Awaiting Review

#9 @jeremyfelt
5 months ago

  • Milestone changed from Awaiting Review to 5.5
  • Resolution set to fixed
  • Status changed from reopened to closed

This specific instance was resolved in [49375].

Note: See TracTickets for help on using tickets.