Edit report at https://bugs.php.net/bug.php?id=62745&edit=1

 ID:                 62745
 Updated by:         ahar...@php.net
 Reported by:        kjelkenes at gmail dot com
 Summary:            Extend echo and print possiblity
-Status:             Open
+Status:             Wont fix
 Type:               Feature/Change Request
-Package:            Unknown/Other Function
+Package:            Output Control
 Operating System:   *
 PHP Version:        5.4.5
 Block user comment: N
 Private report:     N

 New Comment:

The commenters are right: output buffering already deals with the feature as 
requested, and as Laruence points out, the taint extension is available for the 
underlying issue if you want to go down that road.

Closing.


Previous Comments:
------------------------------------------------------------------------
[2012-08-05 06:55:18] larue...@php.net

1. if you want taint mode, refer to : http://pecl.php.net/taint
2. if you want escape output: refer to http://www.php.net/manual/en/function.ob-
start.php

thanks

------------------------------------------------------------------------
[2012-08-05 05:43:07] phpmpan at mpan dot pl

>From my point of view, keithm provides a solution that does exactly the thing 
>you have asked for. Output buffering wasn't created for this purpose, but it 
>can be easily used for it without breaking anything. If this is not what you 
>wanted, maybe your description is not clear enough?

However this is a solution for a problem that doesn't exist in reality.
 1. Most of the data output by scripts should never be escaped.
    Yet your idea causes ALL data to be escaped, producing garbage.
 2. In few specific cases there are small portions of data from untrusted
    sources that should be escaped. In such cases a single call is enough.
    What you want to be introduced requires 3 lines of code (enable escaping,
    echo, disable escaping) just to make same thing a single function call
    could do.
 3. Even worse: the concept is perpendicular to echo by design,
    but not perpendicular to echo by behaviour. Hence it's a design error.

------------------------------------------------------------------------
[2012-08-05 01:23:44] kjelkenes at gmail dot com

For the comment above.

Ok, You don't see the need?

Output buffering is something completely different. Yes you can do the same 
with output buffering.. But it still includes the HTML that was not printed by 
the parser.



What about this case, do you really think output ob_start() buffering???

ob_start();
<?php echo $user->getName()?>
<b> This is ALSO cached by output buffer function.....</b>
$content = ob_get_flush();


That script... yes .. ob_start() before everything and ob_get_contents() will 
return the complete parsed content... but it does NOT intercept the ECHO 
statement, meaning if you where about to try parsing:


Meaning Output buffering functions could NEVER intercept the echo statement ( 
RATHER THE WHOLE THING ) . 


What if we wanted to intercept the real echo statement and not the ob_* 
functions..


Seriously your comment does not make sense. You are talking about ob_* 
functions while this is a whole another case, please don't follow this ticket.

------------------------------------------------------------------------
[2012-08-04 19:30:44] keithm at aoeex dot com

You can already accomplish this using output buffering if so desired.  I don't 
see a need to add anything else into the mix.  For example:

------------------------------------------
<?php
$outputHandler = function($data){
        return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
};

ob_start($outputHandler);

echo '<script>alert(\'This will never be executed.\')</script>';

------------------------------------------

outputs:
&lt;script&gt;alert(&#039;This will never be executed.&#039;)&lt;/script&gt;

------------------------------------------------------------------------
[2012-08-04 14:13:55] kjelkenes at gmail dot com

Description:
------------
This is a feature request regarding the "echo" and "print" functions used in 
PHP. The echo/print statement is used for output. As of today there are no way 
of extending these statements, leading to potential security risks.


If we could extend the echo function at a given time with a handler/closure 
this could really improve the security of PHP. 


Say we have the following security risk (XSS injection):

$data = "<h1><script>alert('hi');</script></h1>"; // From db.

echo $data;



Today we need custom functions to escape this such as:

function escape($data){
    return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
}

echo escape($data);



What if we could implement a handler for the echo/print statements such as this:

// Define a handler:
$outputHandler = function escape($data){
    return htmlspecialchars($data, ENT_QUOTES, 'UTF-8');
};


/**
 * Sets a output handler for php, it's used in echo and print statements.
 * @param string $name The identity of this handler ( Unique )
 * @param mixed $outputHandler function name or callback closure to use.
 * @param mixed $flags What type of satements to use this function.
 */

add_output_handler('xss_filter',$outputHandler, OutputHandler::F_ECHO | 
OutputHandler::F_PRINT);


/**
 *  Removes a given output handler by it's name.
 */
remove_output_handler('xss_filter');




Then we could use normal statements:

echo '<script>alert('This will never be exected.')</script>';


And when we don't need it anymore:

remove_output_handler('xss_filter');



This way, one can be sure that the output of ANY kind is actually stripped, 
without implementing a whole new templating system for PHP.

Also this does not break any kind of PHP applications running, it just adds new 
functionality that is (let's face it) really needed for PHP.


This is also great for MVC frameworks, just apply it before executing a view 
file and remove it after!



------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62745&edit=1

Reply via email to