[wp-trac] [WordPress Trac] #18322: The Road to Magic Quotes Sanity

[WordPress Trac]

#18322: The Road to Magic Quotes Sanity
--------------------------------------+-----------------------------
 Reporter:  ryan                      |       Owner:  jorbin
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  Future Release
Component:  Bootstrap/Load            |     Version:  3.2.1
 Severity:  normal                    |  Resolution:
 Keywords:  needs-patch dev-feedback  |     Focuses:
--------------------------------------+-----------------------------

Comment (by lev0):

 The most bizarre thing about this issue is not that it hasn't changed,
 since it's a real backwards-compatibility nightmare, it's that there's
 barely any documentation of it. You've had a huge footgun loaded and aimed
 at third-party developers, in every WP install, since forever, but
 [https://developer.wordpress.org/reference/functions/stripslashes_deep
 /#user-contributed-notes it's a footnote in the solution]. If you don't
 already know about the problem, you probably won't find out until your
 users' data are already contaminated with extra `\` characters, or worse.

 No mention in [https://developer.wordpress.org/apis/global-variables/
 global variables]. Nothing in
 [https://developer.wordpress.org/apis/security/common-vulnerabilities/
 common vulnerabilities] though SQL-injection is explicitly mentioned and
 is the original reason for enforcing `addslashes()`. Nothing in
 [https://developer.wordpress.org/apis/security/sanitizing/ sanitising],
 which instead recommends `sanitize_text_field()`. That function quite
 destructively sanitises content for safe ''output'' in HTML, but is
 demonstrated being used on ''input'', even though plenty of inputs are
 never destined for use in HTML. If you use that on the way in, the only
 way it doesn't get double-escaped on the way out is because `esc_html()` &
 co. are written to expect this mistake. Data like usernames, passwords,
 etc. should absolutely **not** be passed through it. It only promotes
 further misunderstanding about what escaping should be performed at what
 stage of data handling.

 There are also many solutions on Q&A sites that instruct others to naively
 modify the GPCS superglobals, sometimes on every request. There's no
 realisation that doing so enables SQL injection in bad coding styles, and
 drops legitimate backslashes from input everywhere else that rightly
 expects this data will be slashed. I come across recent sites that have
 random extra `\`'s or are missing them (Windows file paths are a common
 victim, e.g. `C:UsersJoe.git`). Invariably, they're running on WordPress.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/18322#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform