Its not a danger if you don't use it. Additionally I think FormHelper escapes attributes so unless you stupidly echo it out without escaping things should be fine. So like most security issues, they are easy to solve by using your brain and escaping user supplied data.
-Mark On Nov 5, 8:41 am, euromark <[email protected]> wrote: > I searched for answers to this topic at > stackoverflowhttp://stackoverflow.com/questions/7985366/additional-this-here-secur... > > /** > * Don't you EVER remove this line else you will make the whole > * application a swiss cheese for XSS! > * We often call echo $this->here in our form actions and this would > * be exactly where the injection would take place. > */ > $this->here = preg_replace('/("|\')/', 'â€', > addslashes(strip_tags($this->here))); > > Maybe a core member could shed some light on the subject on how big a > vulnerability it was to use $this->here (In 2.0 $this->here is now > $this->request->here) inside the application. > You could probably always use h() on echoing it. But lets assume we > don't (it would probably mess up part of the url). > Do we still need to apply such a patch manually before using it? Or is > the url already cleaned in some way? > Same probably goes for $this->request->url and the referer and > possibly other request parts. > > Looking at CakeRequest, Router, etc I couldn't find any such xss > cleaning approaches used. but maybe I just missed sth. > If not the case it would be good to know if the above approach is > sufficing and to what parts of the request data it should be applied. > probably the ones that are echoed out at some point since xss can only > work if in the source code. > thank you! -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php
