> Second, if we escape by default, there will be a method for pulling the raw value, so that you can prevent any double escaping (or any > escaping at all). The idea is to have a poka-yoke -- do the right thing by default and protect developers from mistakes, and provide > functionality for knowledgable developers to work around the system on a case-by-case basis.
Just wanted a little clarification. And the ability to set an unescaped value would be a good thing for those times when the escaping is not wanted. I'm totally for the idea of forcing safer programming. > > ..let's not get too worked up. :) > Oh, you're such a comedian. (no really I'm laughing) ;P ~ rant Now, if we could just get people to update their outdated web apps (forums, cms, etc) with the security patches. This might prevent URL Injection (a cousin to SQL Injections) and the installation of php/perl backdoors, php/perl injection scanners, rouge IRC, etc. Then maybe people - like the Canadian idiot I was just talking with - would understand that when I call him (this because he blocks mail to his abuse contact) to tell him his server has active backdoor, is running a hidden IRC bot chat with lots of bot chatter happening and to top it off is hitting my server with URL Injection attempts. He might actually say "Thank you, for taking the time out of your busy day to inform me of my servers bad behavior. We will get someone to check it and get it corrected promptly." and then he could go fix his server. Alias, but no - this arrogant idiot-tech has the nerve to say, "Our servers are not infected... you are mistaken our network is 100% secure.. Blah blah" and then on top of being a really big jerk he hung-up on me... A long distance phone call to Canada... He was even nice enough to confirm he did have a server at the IP address I provided, but of course it was not absolutely no running any thing it shouldn't. Now that I'm thining about it, I bet I did not make it CLEAR that I'm IN his server vie "relay". Oh yes, using that backdoor that his "secure" server isn't running. No, backdoor on your server? Really ... *evil grin* ~ end rant p.s. Install those updates people. -----Original Message----- From: Matthew Weier O'Phinney [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 3:15 PM To: [email protected] Subject: Re: [fw-general] Cross site scriptinginZend_Db_Statement_Exception handling -- Terre Porter <[EMAIL PROTECTED]> wrote (on Wednesday, 30 July 2008, 02:54 PM -0400): > >Matthew wrote: > >The potential failure here is that Zend_View probably should be > >escaping > variables by > >default, and this is an improvement slated for 2.0.0. > > Is this for all fields that are sent to a view? > > Are we talking about something like: > > $this->view->myvar = "blah"; > > And that being automatically escaped ? > > What happens if I pass pre-HTML-escaped value to the view, do I get > those annoying extra \\ in there? > > What if I pass a pre-processed html or another view? Ajax for example. > > However, I could be confused on what is going to be escaped. First off, 2.0.0 is not for another year at the earliest, so let's not get too worked up. :) Second, if we escape by default, there will be a method for pulling the raw value, so that you can prevent any double escaping (or any escaping at all). The idea is to have a poka-yoke -- do the right thing by default and protect developers from mistakes, and provide functionality for knowledgable developers to work around the system on a case-by-case basis. > -----Original Message----- > From: Matthew Weier O'Phinney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 30, 2008 1:50 PM > To: [email protected] > Subject: Re: [fw-general] Cross site scripting > inZend_Db_Statement_Exception handling > > -- Bill Karwin <[EMAIL PROTECTED]> wrote (on Wednesday, 30 July 2008, > 10:14 AM -0700): > > Matthew Weier O'Phinney-3 wrote: > > > > > > However, you're right -- the value should be escaped. I'll > > > escalate the issue. > > > > > > > Really? Message strings in Exceptions should be HTML-escaped? > > > > If this constitutes an XSS vulnerability, then one could equally > > argue that PHP should automatically escape any error or exception > > output if it is being directed to the page. Though it's hard for > > PHP to know when to do this, because of other conditions, e.g. > > output buffering may be in effect, and PHP doesn't know whether you > > plan to escape the > contents of the ob. > > > > My point is that escaping output is the responsibility of the > > application, not the framework (or the language). Only the > > application developer knows when it's the right thing to do. > > When I discovered that the original string is generated by PDO, I came > to the same conclusion. This is not a failure on ZF's part, but a > failure on the developer to (a) prevent exceptions showing in their > output, and (b) not escaping the output when they did allow exceptions to be shown. > > The potential failure here is that Zend_View probably should be > escaping variables by default, and this is an improvement slated for 2.0.0. > > -- > Matthew Weier O'Phinney > Software Architect | [EMAIL PROTECTED] > Zend Framework | http://framework.zend.com/ > -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
