Re: [PHP-DEV] request data filter
Rasmus Lerdorf [EMAIL PROTECTED] wrote... : this would likely have different security policies, but I do think a general hook is something that would be useful to all of PHP. A huge number of web apps today are extremely vulnerable to cross-site-scripting attacks. Occasionally developers remember to clean their data before displaying it, but for the most part they don't. Take half and hour and find yourself a collection of sites where you can enter data that is somehow displayed back to you. Shopping carts that ask for your name and phone number, or half of php.net's own stuff. Stick a bit of javascript in your phone number and watch. Just a little note here. The government project I am working on was attacked on New Year's night with XSS. Therefore, after we fixed it we decided to see what else is vulnerable oiut there. During the last two weeks I have played with a variaty of sites/portals/apps trying to hack them to see how far I can go. I ended up stealing the sessions of any installations, changing the passwords on main website and could see the list of passwords in pain user:pass format assigned as a cookie to anyone who sees my message on ***. Now, every *** was notified by me and, till they all will fix these, I will try not to reveal their names. What I think PHP should have is a function of a whole extension which parses the output in various ways cleaning XSS in it. Also, having such functionality in PHP would help it looking more secure as XSS affects any programming language and not namy have such protections. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
It looks like a mess indeed, and there seems a thought that encoding conversion and variable registration should be separated into two phases. However doing so doesn't make sense because some of multibyte characters contains [, ], or = and they cannot be handled properly in the ordinary query parser. Therefore Rasmus's sugestion sounds quite logical to me. Moriyoshi On Wed, Jan 15, 2003 at 04:52:58PM -0800, Rasmus Lerdorf wrote: In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw mbstring into the mix as that extension also uses those hooks. The cleanest way I can think of doing this is to add a function pointer to SAPI for the filtering function that will be run right before the php_register_variable_safe() call. Currently we are always calling php_url_decode() on the data before registering the variable, so I propose that we make php_url_decode() the default that an extension can then override. Anybody see any reason not to make this simple change? Without that I will need to somehow detect whether mbstring is present and then filter the data after it has already been registered by mbstring's treat_data/post_handler hooks. That's a big mess! -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
At 02:52 16/01/2003, Rasmus Lerdorf wrote: In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw mbstring into the mix as that extension also uses those hooks. The cleanest way I can think of doing this is to add a function pointer to SAPI for the filtering function that will be run right before the php_register_variable_safe() call. Currently we are always calling php_url_decode() on the data before registering the variable, so I propose that we make php_url_decode() the default that an extension can then override. Anybody see any reason not to make this simple change? Without that I will need to somehow detect whether mbstring is present and then filter the data after it has already been registered by mbstring's treat_data/post_handler hooks. That's a big mess! Sounds good to me. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
I cannot agree more. There is only so much you can do outside the PHP (as I do in mod_security). I've finished the code. I'll run it through its paces here and commit it soon. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] request data filter
In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw mbstring into the mix as that extension also uses those hooks. The cleanest way I can think of doing this is to add a function pointer to SAPI for the filtering function that will be run right before the php_register_variable_safe() call. Currently we are always calling php_url_decode() on the data before registering the variable, so I propose that we make php_url_decode() the default that an extension can then override. Anybody see any reason not to make this simple change? Without that I will need to somehow detect whether mbstring is present and then filter the data after it has already been registered by mbstring's treat_data/post_handler hooks. That's a big mess! -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
You consider running the apache_hooks code? This should be simple there. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
On Wed, 15 Jan 2003, George Schlossnagle wrote: You consider running the apache_hooks code? This should be simple there. You mean do the filtering straight from a PHP script that gets called from a hook? That's a lot of looping through a bunch of arrays. This has to happen on every request on the busiest site in the world; it needs to be written in C. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
You could have your custom C extension be called as one of the hooks. On Wednesday, January 15, 2003, at 09:42 PM, Rasmus Lerdorf wrote: On Wed, 15 Jan 2003, George Schlossnagle wrote: You consider running the apache_hooks code? This should be simple there. You mean do the filtering straight from a PHP script that gets called from a hook? That's a lot of looping through a bunch of arrays. This has to happen on every request on the busiest site in the world; it needs to be written in C. You could have your custom C extension be called as one of the hooks. Shouldn't be any slower than what you proposed. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
