rfc:escaper

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:escaper [2013/09/27 04:09] – [Escape filter as ext/filter] Fix table yohgakirfc:escaper [2018/06/18 10:11] (current) – This RFC appears to be inactive cmb
Line 3: Line 3:
   * Date: 2012-09-18   * Date: 2012-09-18
   * Author: Pádraic Brady <padraic.brady.at.gmail.com>, Yasuo Ohgaki <yohgaki@php.net>   * Author: Pádraic Brady <padraic.brady.at.gmail.com>, Yasuo Ohgaki <yohgaki@php.net>
-  * Status: Under Discussion+  * Status: Inactive
   * First Published at: http://wiki.php.net/rfc/escaper   * First Published at: http://wiki.php.net/rfc/escaper
  
 ===== Change Log ===== ===== Change Log =====
 +  * 2012-09-18 Initial version edited from https://gist.github.com/gists/3066656
   * 2013-09-27 Added ext/filter implementation as an option (Yasuo)   * 2013-09-27 Added ext/filter implementation as an option (Yasuo)
  
Line 41: Line 42:
 Including more narrowly defined and specifically targeted functions or SPL class methods into PHP will simplify the whole situation for users, offer a cohesive approach to escaping, rectify PHP's situation as only offering a partial XSS defense and, by its presence in Core, displace function misuse and homegrown escaping functions. Including more narrowly defined and specifically targeted functions or SPL class methods into PHP will simplify the whole situation for users, offer a cohesive approach to escaping, rectify PHP's situation as only offering a partial XSS defense and, by its presence in Core, displace function misuse and homegrown escaping functions.
  
-===== Escape filter as ext/filter =====+===== Escape filter for ext/filter =====
  
 Implementation option as filter. Implementation option as filter.
Line 55: Line 56:
  
  
-===== SPL Class or Functions? =====+===== SPL Class =====
  
 While it may well be advisable to do both, I have a strong preference for classes coming from a framework heavily dependent on them and would suggest a class structure that implements the following interface in addition to any standalone functions: While it may well be advisable to do both, I have a strong preference for classes coming from a framework heavily dependent on them and would suggest a class structure that implements the following interface in addition to any standalone functions:
Line 88: Line 89:
  
 The benefits of the class are to allow the centralised setting of a character encoding once and then being able to pass around the object across an entire application or library allowing it to be configured from a single location. This could be created in userland PHP around a set of functions but it seems silly to skip an obviously beneficial step to users. The benefits of the class are to allow the centralised setting of a character encoding once and then being able to pass around the object across an entire application or library allowing it to be configured from a single location. This could be created in userland PHP around a set of functions but it seems silly to skip an obviously beneficial step to users.
 +
 +===== Functions =====
  
 Functions may then be added along the following lines (names up for discussion): Functions may then be added along the following lines (names up for discussion):
  
   * escape_html($value, $encoding);   * escape_html($value, $encoding);
- 
   * escape_html_attribute($value, $encoding);   * escape_html_attribute($value, $encoding);
- 
   * escape_javascipt($value, $encoding);   * escape_javascipt($value, $encoding);
- 
   * escape_css($value, $encoding);   * escape_css($value, $encoding);
- 
   * escape_url($value, $encoding);   * escape_url($value, $encoding);
- 
   * escape_xml($value, $encoding);   * escape_xml($value, $encoding);
 +  * escape_xml_attribute($value, $encoding);
  
-  * escape_xml_attribute($value, $encoding);+===== Implementation Notes ===== 
 + 
 +IMPORTANT: Since proper escape requires proper character encoding handling, multibyte string feature in core is mandatory for implementation.
  
 I am strongly opposed to allowing these functions accept unpredictable character encoding directives via php.ini. That would require additional work to validate which is precisely what this RFC should seek to avoid. By validation, I mean having programmers determine how dependencies implement escaping, what encoding they enforce (usually the default), and then determining if it can be changed by the depending applications or if the library must be forked, re-edited, etc. Those who are concious of security will review dependencies for such issues rather than blindly trust dependencies. I am strongly opposed to allowing these functions accept unpredictable character encoding directives via php.ini. That would require additional work to validate which is precisely what this RFC should seek to avoid. By validation, I mean having programmers determine how dependencies implement escaping, what encoding they enforce (usually the default), and then determining if it can be changed by the depending applications or if the library must be forked, re-edited, etc. Those who are concious of security will review dependencies for such issues rather than blindly trust dependencies.
Line 116: Line 117:
 Symfony's Twig also recently added similar escaping options: Symfony's Twig also recently added similar escaping options:
 https://github.com/fabpot/Twig/raw/master/lib/Twig/Extension/Core.php https://github.com/fabpot/Twig/raw/master/lib/Twig/Extension/Core.php
- 
 ===== Class Method Dissection ===== ===== Class Method Dissection =====
  
Line 169: Line 169:
 The essence of this RFC is to propose including basic safe escaping functionality within PHP which addresses the need to apply context-specific escaping in web applications. By offering a simple consistent approach, it affords the opportunity to implement these specifically to target XSS and to omit other functionality that some native functions include, and which can be problematic to programmers or doesn't go far enough. Centralising escaping functionality into one consistent package would, I believe, be one more small step to improving the application of escaping in PHP. The essence of this RFC is to propose including basic safe escaping functionality within PHP which addresses the need to apply context-specific escaping in web applications. By offering a simple consistent approach, it affords the opportunity to implement these specifically to target XSS and to omit other functionality that some native functions include, and which can be problematic to programmers or doesn't go far enough. Centralising escaping functionality into one consistent package would, I believe, be one more small step to improving the application of escaping in PHP.
  
-===== Changelog ===== 
  
-  * 2012-09-18 Initial version edited from https://gist.github.com/gists/3066656 
rfc/escaper.1380254979.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools