I'm afraid not. The entire point of passing GET and POST variables into the sfWebRequest object is to allow for cleaning of potentially mailicious code. You say hoiw would it know? How would you know? How would you code it remove potentially malicious content? If the sfWebRequest object did nothing more than just hold a carbon copy of parameters passed, we might as well not bother and just directly access $_GET and $_POST!
As for the security fix you mentioned, it is true that was a problem and that was because one small aspect of the existing cleaning mechanisms in symfony was overlooked. If the sfWebRequest object did NOT clean up the GET and/or POST parameters, why did the symfony core team fix it? If it wasn't supposed to clean the parameters there shouldn't have been anything to fix! On Sat, Mar 6, 2010 at 12:45 PM, Daniel Lohse <[email protected]> wrote: > That's incorrect, Gareth. The security fix for symfony 1.4.3 just last week > was on the *exact* same lines of code because you could inject SQL in the > Doctrine admin generator. > > How would symfony guess what you want to remove (clean) or not? :) > > > Daniel > > On 06.03.2010, at 08:10, Gareth McCumskey wrote: > >> Firstly, symfony does that for you ;). Secondly it was just a quick >> example to get him on the right road. I didn't have time to sit and >> show a fully worked, real world example. >> >> Jsut to reiterate, symfony already checks what parameters are passed >> through GET and POST for you for SQL injection and cleans them. Try it >> yourself if you don't believe me. Its one of the great benefits of >> using a framework. >> >> On Fri, Mar 5, 2010 at 8:12 PM, Augusto Flavio <[email protected]> wrote: >>> Hi Gareth, >>> >>> >>> the method that you show us have a security problem: inject sql. You need to >>> check what kind of parameter the user is sending. >>> >>> >>> >>> if (!in_array($parameter, array('asc', 'desc'))) { >>> //do something >>> } else { >>> //execute the query >>> } >>> >>> >>> bye >>> >>> >>> >>> Augusto Morais >>> >>> -- >>> If you want to report a vulnerability issue on symfony, please send it to >>> security at symfony-project.com >>> >>> You received this message because you are subscribed to the Google >>> Groups "symfony users" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/symfony-users?hl=en >>> >> >> >> >> -- >> Gareth McCumskey >> http://garethmccumskey.blogspot.com >> twitter: @garethmcc >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- Gareth McCumskey http://garethmccumskey.blogspot.com twitter: @garethmcc -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
