[wp-trac] [WordPress Trac] #39941: Allow using Content-Security-Policy without unsafe-inline

[WordPress Trac]

#39941: Allow using Content-Security-Policy without unsafe-inline
-------------------------------------+--------------------------
 Reporter:  tomdxw                   |       Owner:  johnbillion
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  5.3
Component:  Security                 |     Version:  4.8
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:  javascript
-------------------------------------+--------------------------

Comment (by jadeddragoon):

 Replying to [comment:27 mallorydxw]:
 > @jadeddragoon
 >
 > > It will not make WP sites more secure
 >
 > Explain how.

 Because it simultaneously provides a mechanism for evading the CSP
 entirely.

 Hypothetical:

 >Plugin Developer A writes a plugin that templates javascript. To do this
 he uses the proposed function to generate nonces. However, the way the
 javascript in question is templated by the PHP of his plugin changes
 depending on user input and the developer fails to properly sanitize that
 input (this is a bog standard XSS scenario).
 >
 >Without this patch the site operator would have to configure a CSP with
 unsafe-inline. The user and the user's client could therefore be warned of
 the risk of XSS when using said plugin. As CSP is adopted more and more
 eventually Google, Mozilla, Microsoft, Apple and the rest of the browser
 developers could add unsafe-inline to the warnings shown in the address
 bar specifically to let them know when they are at risk of having their
 personally identifiable information exposed.
 >
 >With this patch, however, a malicious user could input specially
 formatted code intended to perform XSS into the poorly sanitized inputs,
 and your proposed patch would ensure that the user and the user's browser
 was told that this XSS code is trustworthy. And, as CSP is adopted more
 and more... when browser developers make the switch to warning users
 WordPress sites will be lying to the user about their level of risk.

 All this patch does, is move the risk of XSS exploits from javascript to
 PHP (on top of whatever risk the PHP already presented) and **additionally
 makes it impossible for CSP to do its job** because PHP is a server-side
 scripting language. CSP is designed specifically to reduce the risk to end
 users from poorly sanitized inputs and unintended connections between user
 input and html/css/js output. But if you go marking all of that output as
 trusted without knowing ''exactly'' what that output will be... then CSP
 can't work. How is that not obvious?

 It doesn't matter if the ''exploit'' is in the JS itself or the PHP behind
 it. The reason inline JS is unsafe is exactly because there's no way to
 tell what inline JS is intended to be there and what inline JS is the
 ''result'' of an XSS exploit. If inline JS is disallowed entirely then any
 inline JS is ''obviously'' not supposed to be there. The use of nonces to
 mark JS as safe is intended for use with carefully vetted, _''static''_
 javascript.

 But with your patch ''all'' inline JS will get marked as "supposed to be
 there" before being sent to the user... meaning that there is still no way
 to tell what inline JS is actually supposed to be there and what isn't.
 This is functionally identical to using unsafe-inline in the CSP to begin
 with... except, again, the user isn't made aware of the issue.

 I'm aware of just what a gargantuan task it would be to convert WordPress
 to use static javascript separated from the html. ::shrug:: That's what
 happens when you find yourself managing an application or system that
 defies best practices. Maybe it wasn't best practice five years ago... cry
 me a river. As a site operator my responsibility is to my users. Not
 WordPress. And one of the objectives of CSP adoption is to force software
 developers to stop using unsafe practices. Refactor WordPress... leave the
 plugin developers to justify doing otherwise to their users.

 Or don't. Go ahead and make it official that WordPress requires running
 with unsafe-inline and the totally-not-a-problem isn't going to be solved.
 Hell, I'll even update the documentation myself. But this patch, well
 intentioned or not, is categorically The Wrong Way from a security
 standpoint.

 Bottom line is bottom line: this patch is identical in security risk to
 running with unsafe-inline **except that it hides the problem**. And no
 one in this thread can say they weren't warned.

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