Evitar sql injection y xss

[Ricardo Mun~oz A.]

Rodrigo Fuentealba wrote:
> El 26/09/07, Ricardo Mun~oz A. <rmunoz en pjud.cl> escribió:
>   
>> Cristian Rodriguez wrote:
>>     

[...]

>>> No es FUD, si esta programado para una version del lenguaje obsoleta,
>>> llena de limitaciones y errores el resultado va a ser malo auqnue
>>> funcione el versiones posterioires.
>>>
>>>       
>> y sigues con tu FUD; estas diciendo que todas las aplicaciones que
>> funcionan con PHP4 estan llenas de limitaciones y errores solo debido a
>> la version del lenguaje. pero, lo que tambien estas diciendo (sin darte
>> cuenta?) es que si PHP5 me acepta el mismo codigo que PHP4
>>     
>
> No todo funciona igual. Hay un registro de cambios en www.php.net para
> poder migrar de php 4 a php 5.2
>
>   
>> automaticamente PHP5 pasa a ser igual de limitado y lleno de errores
>> como PHP4.
>>
>>     

[...]

>> te das cuenta de eso?
>>     
>
> Entiende: PHP 5 es un lenguaje completamente nuevo, con backwards
> compatibility (a medias), hacia PHP 4, pero cuya forma recomendada de
> usar es completamente distinta, cuya manera de declarar las clases
> (públicas, protegidas y privadas, algo que tengo entendido que PHP 4
> no soporta completamente bien, pero no tengo ningún PHP 4 para
> comprobarlo) es distinta, cuya manera de organizar el código para
> terminar con el spaghetti es mucho mejor.
>   

concentrate en lo que estas leyendo, analiza tu respuesta, luego 
responde. te voy a dar un ejemplo totalmente real (nada de "metaforas" 
de radios y TV), y es el siguiente:

PHPLib, hecho en PHP3, funciona a la perfeccion en PHP5, basta con 
habilitar la opcion 'register_long_arrays' en php.ini. que podemos 
entonces concluir:

a. que los desarrolladores de PHPLib hicieron muy bien su pega por lo 
que cualquier script, sitio o app. web (antigua) hecha con PHPLib podra 
seguir funcionando por muchos an~os mas sin tener que gastar recursos en 
re-escribir la misma app.?

b. que PHP5 es malo porque permite ejecutar codigo escrito para PHP3?

c. que PHP5 es bueno porque permite ejecutar codigo escrito para PHP3?

d. que PHPLib es malo porque fue escrito para PHP3?

e. que (ciegamente) se deben re-escribir aplicaciones PHP que llevan 
an~os funcionando solo porque PHP5 trae mejor soporte de OOP?

ojo que PHP no sirve solo para hacer sitios web que luego se montan en 
servidores con acceso publico, tambien puedes tener aplicaciones 
internas, aplicaciones que se ejecutan en modo "autoconsulta" (modo 
kiosko), scripts que se ejecutan por linea de comandos, etc. etc.

es obvio que PHP5 la lleva, y que se debe usar (correctamente) para 
cualquier desarrollo nuevo. pero la realidad es mucho mas compleja... 
las opiniones extremas solo demuestran las ganas de vivir en un mundo 
perfecto.

>> ademas, PHP4 sera soportado hasta el an~o 2012 en RHEL4, CentOS4, etc.
>> (ver [1]) por lo que tu FUD de que "PHP4 no esta soportado" tampoco es
>> cierto.
>>     
>
> El soporte que RHEL 4, CentOS 4 u otra distribución le da a las
> aplicaciones cuyo release ha pasado consiste en hacer "backporting" de
> muchos parches. Si PHP 5 reescribió completamente su esquema de clases
> y objetos, ¿me puedes decir qué clase de marañas tendrán que hacer
> cuando se pille un error en esta parte de PHP 4, y cuánto se demorarán
> en parcharlo?
>   

me da lo mismo. si uso RHEL4 estoy pagando para que lo hagan hasta el 
an~o 2012.

> El soporte que te ofrece RHEL refiere a incluirlo en la distribución,
> mantenerlo funcionando y que no se rompa ante otras bibliotecas, pero
> ellos "no" son totalmente expertos en el funcionamiento de PHP

es tan simple como que Redhat contrate a un experto en el funcionamiento 
de PHP, y listo. si tengo RHEL4 no me interesa  como Redhat resuelve ese 
problema, para eso les estoy pagando. ojo que no uso RHEL4, pero te 
aseguro que hay miles de maquinas en todo el mundo que si lo van a usar 
hasta el 2012 (y tienen sus propias razones para hacerlo)...

[...]

>> por lo mismo CakePHP es una buena opcion (para cierto tipo de
>> aplicaciones web) ya que permite pasar a produccion aplicaciones web en
>> un rango mas amplio de hosts. la version 2.0 de Cake sera
>> PHP5/6-only[2], sin duda esa version sera re-escrita pero sin afectar
>> mayormente su API, que es en el fondo lo unico que importa en cualquier
>> framework.
>>     
>
> ¿Entonces habrá lugares en que debes sanitizar por ti mismo?
>   

para nada. si le doy un buen uso al framework, la "sanitizacion" es 
automatica.

>> en todo caso, la proxima vez que te toque recomendar Symfony vs. CakePHP
>> podrias decir que Cake no soporta PKs compuestas, en cambio Symfony
>> si... IMHO ese podria ser (para algunos) el unico "punto en contra" de
>> Cake. la tontera de PHP4 (malo) vs. PHP5 (bueno) lo veo totalmente
>> irrelevante.
>>     
>
> Claro, por omisión el usuario debería pensar que una versión nueva
> trae más y mejores features, y debe informarse acerca de ellas antes
> de elegir una versión anterior, y no elegir una versión anterior
> "porque la nueva es muy nueva" (muy nuevo serán 2 días; 15 días; pero
> no 3 años).
>   

si uso un framework me da lo mismo la version del lenguaje, basta con 
que sea soportado por el framework y por el servidor donde se estara 
ejecutando la aplicacion final.

-- 
Ricardo Mun~oz A.
Usuario Linux #182825 (counter.li.org)