Evitar sql injection y xss

[Rodrigo Fuentealba]

El 26/09/07, Ricardo Mun~oz A. <rmunoz en pjud.cl> escribió:
> Cristian Rodriguez wrote:
> > Ricardo Mun~oz A. escribió:
> >
> >
> >> shuata... entonces no tienes idea que CakePHP lo puedo ejecutar sin
> >> problemas en PHP5? cual es la idea de de tanto FUD con respecto a Cake?
> >>
> >
> > 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.

Ejejejeje, pongámoslo fácil:

Compré un equipo de radio marca PHP modelo 4.3 que sólo me soporta
escuchar bandas AM y escuchar vinilos.

Luego compré un equipo de radio marca PHP modelo 5.2 que soporta
bandas AM, FM, TV y escuchar CD-ROM's, pero como puedo escuchar AM,
¿es igual de limitado?

No sé en qué parte del Universo vives tú, pero acá en el planeta
Tierra, el segundo equipo de radio no es tan limitado como el primero.

> (si PHP4 me permite escribir codigo malo, entonces tambien me
> lo va permitir PHP5).

Si tú usas PHP 5 como si fuera PHP 4, y no lees los cambios, los hints
de seguridad y todas esas cosas; es lo mismo que usar Python 3.0 si
sigues usándolo como si fuera Python 1.2, o Visual Basic .NET 2005 con
los objetos DCOM de Visual Basic 6: no es problema del lenguaje, sino
de "tu" forma de utilizarlo. Considera seriamente volver a estudiar
PHP.

> 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.

> 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?

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 y aún
si picaran código, el duplicado de esfuerzos conllevaría, en este
caso, a inconsistencias. Slackware ya retiró de sus filas a PHP 4 y no
lo recomienda para nada, ya pasaron sus años de fama; Slackware 11 lo
mantendrá sólo hasta que sea viable, y eso no será por mucho. Cristian
que te cuente sobre SuSE.

Eso ocurre cuando el cambio es drástico en una distribución, cosa que
en el caso de MySQL, no importa, porque reimplementan sobre lo mismo y
no hay mucha diferencia entre el código que comparten 5.0.41 y 4.1.11
(pero sí la hay en el código que se agregó).

> ahora, antes de que R.Fuentealba diga que estoy defendiendo
> PHP4, aclaro altiro que es obvio que PHP5 es mucho mejor, pero hay que
> ser suficientemente inteligente para darse cuenta que en la realidad
> existen (muchos) miles de hosts con PHP4 que no van a migrar a PHP5 en
> el corto/mediano plazo.

¿Por ejemplo?

Esos hosts son aquellos a los que les interesa ganar plata y DEBEN ser
tildados de irresponsables; podrían adquirir demandas (aunque en la
práctica, nadie lo hace y todos se resisten por un tema de "comodidad"
y "no entregar un buen servicio"). Todos los informáticos sabemos que
un sistema que está en línea, expuesto a personas cuyos orígenes no
conocemos más que por su dirección IP (y si es que...)

> 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?

> 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).

-- 
Rodrigo Fuentealba