WordPress.org

Make WordPress Core

Changes between Version 8 and Version 9 of Ticket #39941, comment 28


Ignore:
Timestamp:
03/21/2019 05:10:00 PM (5 months ago)
Author:
jadeddragoon
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #39941, comment 28

    v8 v9  
    1414>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 users know when they are at risk of having their personally identifiable information exposed.
    1515>
    16 >With this patch, however, a malicious user could input specially formatted PHP code intended to inject XSS JavaScript into the poorly sanitized inputs, and your proposed patch would ensure that the user and the user's browser was told that this XSS JS 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.
     16>With this patch, however, a malicious user could input specially formatted PHP code into the poorly sanitized inputs with the intent of injecting XSS JavaScript in the associated output, and your proposed patch would ensure that the user and the user's browser was told that this XSS JS 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.
    1717
    1818CSP 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?