I didnt see your answer until now. well, right. but some people might think an url couldn't actually be harmful. just a few months ago, even the core templates still didn't use h() to print out content, for example. and no one cared for decades^^ (except for a few maybe including me) and I see tons of new code like this every day out there. so there is a lot of information not reaching the user / programmer. one is, how important escaping is - even for urls printed out somwhere in the view. they are not dumb but simply unaware of the risks.
even worse: they seem to get the wrong idea that they should sanitize on input, and nothing on output. but that's another topic. to sum it up: the "hack" in the linked script then seems to be unnecessary if the Form Helper does that (which I couldn't confirm from looking at the helper. i might have to run some tests to confirm). And printing out $this->here would require h(), as well. although (!) I have to remark that it might change the url in undesired ways (special chars etc getting escaped). thx mark! On 7 Nov., 18:46, mark_story <mark.st...@gmail.com> wrote: > 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<dereurom...@googlemail.com> 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 cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
