Changes between Version 5 and Version 6 of Ticket #39941, comment 28
- Timestamp:
- 03/21/2019 05:00:06 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #39941, comment 28
v5 v6 10 10 Hypothetical: 11 11 12 >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).12 >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). 13 13 > 14 14 >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. … … 18 18 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? 19 19 20 It doesn't matter if the ''exploitable code'' 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.20 It doesn't matter if the ''exploitable code'' 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 exploit. If inline JS is disallowed entirely then any inline JS is ''obviously'' not supposed to be there. The use of nonces to mark inline JS as safe is intended for use with carefully vetted, _''static''_ JavaScript. 21 21 22 22 But with your patch ''all'' inline JS templated via PHP 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. If the PHP turns out to be exploitable then malicious JS can be marked as trusted. 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. 23 23 24 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.24 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. 25 25 26 26 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.