Make WordPress Core

Opened 12 years ago

Closed 15 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 12 years ago.
json encode javascript variables output in admin header
24907.3.patch (1.4 KB) - added by aliso 12 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
12 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 12 years ago by c3mdigital (next)

@c3mdigital
12 years ago

json encode javascript variables output in admin header

#2 @nacin
12 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
12 years ago

Adding esc_js to variable values to use in place of json_encode

#3 @helen
12 years ago

esc_js() seems sensible.

#4 @azaozz
12 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
10 years ago

  • Keywords needs-testing added

#7 @iandunn
7 years ago

  • Status changed from new to reopened

Reopening being this still seems like useful hardening.

#8 @SergeyBiryukov
7 years ago

  • Milestone set to Awaiting Review

#9 @jeremyfelt
15 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.