rfc:escaper
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:escaper [2012/09/19 10:25] – Added some additional clarification and rationale based on ML feedback padraic | rfc:escaper [2013/09/27 04:15] – Merge Change Log yohgaki | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Escaping RFC for PHP Core ====== | ====== Escaping RFC for PHP Core ====== | ||
- | * Version: 1.0 | + | * Version: 1.0.1 |
* Date: 2012-09-18 | * Date: 2012-09-18 | ||
- | * Author: Pádraic Brady < | + | * Author: Pádraic Brady < |
* Status: Under Discussion | * Status: Under Discussion | ||
* First Published at: http:// | * First Published at: http:// | ||
+ | |||
+ | ===== Change Log ===== | ||
+ | * 2012-09-18 Initial version edited from https:// | ||
+ | * 2013-09-27 Added ext/filter implementation as an option (Yasuo) | ||
===== Introduction ===== | ===== Introduction ===== | ||
Line 10: | Line 14: | ||
This RFC proposes the addition of an SPL class (and optionally a set of functions) dedicated to the secure escaping of untrusted values against Cross-Site Scripting (XSS) and related vulnerabilities. It recognises that this involves the partial duplication of certain existing functions but raises the argument that the current division of functionality, | This RFC proposes the addition of an SPL class (and optionally a set of functions) dedicated to the secure escaping of untrusted values against Cross-Site Scripting (XSS) and related vulnerabilities. It recognises that this involves the partial duplication of certain existing functions but raises the argument that the current division of functionality, | ||
- | The OWASP Top 10 web application | + | The [[https:// |
The proposed functionality is intended to largely reflect the recommendations of the OWASP' | The proposed functionality is intended to largely reflect the recommendations of the OWASP' | ||
Line 38: | 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. | ||
- | ===== SPL Class or Functions? | + | ===== Escape filter for ext/ |
- | While it may well be very feasible and probably | + | Implementation option as filter. |
+ | |||
+ | ^ ID(Constant) ^ Name ^ Options ^ Description ^ | ||
+ | |FILTER_ESCAPE_HTML |" | ||
+ | |FILTER_ESCAPE_HTML_ATTR |" | ||
+ | |FILTER_ESCAPE_JAVASCRIPT |" | ||
+ | |FILTER_ESCAPE_CSS |" | ||
+ | |FILTER_ESCAPE_URI |" | ||
+ | |FILTER_ESCAPE_XML |" | ||
+ | |FILTER_ESCAPE_XML_ATTR |" | ||
+ | |||
+ | |||
+ | ===== 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 | ||
<code php> | <code php> | ||
- | interface | + | interface |
{ | { | ||
public function __construct($encoding = ' | public function __construct($encoding = ' | ||
Line 71: | 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, | * escape_html($value, | ||
- | |||
* escape_html_attribute($value, | * escape_html_attribute($value, | ||
- | |||
* escape_javascipt($value, | * escape_javascipt($value, | ||
- | |||
* escape_css($value, | * escape_css($value, | ||
- | |||
* escape_url($value, | * escape_url($value, | ||
- | |||
* escape_xml($value, | * escape_xml($value, | ||
- | |||
* escape_xml_attribute($value, | * escape_xml_attribute($value, | ||
- | 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. | + | ===== Implementation Notes ===== |
- | As there is no means of centrally | + | 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. |
+ | |||
+ | As there is no means of globally | ||
I have assumed that the character encodings supported are limited to those presently allowed by htmlspecialchars() and that the internals of each method or function validate this fact or throw an Exception (or an error for function calls) to prevent continued insecure execution as is currently allowed by htmlspecialchars(). See links below. | I have assumed that the character encodings supported are limited to those presently allowed by htmlspecialchars() and that the internals of each method or function validate this fact or throw an Exception (or an error for function calls) to prevent continued insecure execution as is currently allowed by htmlspecialchars(). See links below. | ||
Line 99: | Line 115: | ||
Symfony' | Symfony' | ||
https:// | https:// | ||
- | |||
===== Class Method Dissection ===== | ===== Class Method Dissection ===== | ||
Line 152: | Line 167: | ||
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' | 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' | ||
- | ===== Changelog ===== | ||
- | * 2012-09-18 Initial version edited from https:// |
rfc/escaper.txt · Last modified: 2018/06/18 10:11 by cmb