On 9/26/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> En Postgres, si el problema de seguridad requiere un cambio en el
> codigo que significa perdida de compatibilidad hacia atras, se hace. La
> compatibilidad hacia atras es muy importante y se valora mucho, pero la
> seguridad se valora mucho mas.
Quiero secundar la opinion de Alvaro. No estoy diciendo que la
solucion es algo fuertemente tipado (como Java, que es otro cuento tan
complejo que al final terminas teniendo los mismo problemas de algo
mas "liberal").
El problema del codigo PHP es que sigue siendo igual de malo en el
sentido de los resultados que permite. Basta ver todos los phpnuke
botados en todos estos an~os, ver la cantidad de esfuerzo que se gasto
en tratar de mejorar la situacion y aun asi deben haber miles de hoyos
"por descubrir" hasta el dia de hoy.
Y esto es anti-natura de una de las mejores caracteristicas que ha
seguido todo el software libre: reinventarse botando a la basura (sin
asco) las cosas malas y horribles. Uno de los ultimos ejemplos es
Python3k, y es una de las cosas que mas me agrada y valoro; basta ver
toda la mi*rda que trae windows "para poder correr la aplicacion DOS
de facturas de hace 20 an~os".
El CakePHP es malo porque permite escribir las leseras de ejemplos que
salian en el articulo. Esos ejemplos eran horribles. No por los
problemas que solucionan, sino por la cantidad de resultados
"inesperados" que generan. Esos resultados inesperados pueden ir desde
no poder escribir el apellido compuesto de Horst von Brand hasta
dramas serios de seguridad o integridad de datos.
Eso es lo malo, eso debe botarse a la basura, por favor!!
--
Aldrin Martoq
From [EMAIL PROTECTED] Wed Sep 26 23:55:34 2007
From: [EMAIL PROTECTED] (Marco Bravo)
Date: Wed Sep 26 23:58:00 2007
Subject: Puertos alternativos
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Me imagino que vas a ejecutar varias instancias en el mismo servidor de
Aplicacion Java?..
Cada instancia (ejecucion) se levanta en forma independiente...
Bueno, esa es la razon de pq tuve que cambiar puertos con mi Jboss..
El día 26/09/07, Aldrin Gonzalo Martoq Ahumada <[EMAIL PROTECTED]>
escribió:
>
> On 9/26/07, German Castro Donoso <[EMAIL PROTECTED]> wrote:
> > Me gustaria saber si existe o alguien conoce alguna politica estandar
> para
> > elegir un numero de puerto alternativo.
> > En particular tengo que reemplazar el puerto 4444 (servicio RMI en
> servicor
> > de aplicación j2ee) por otro libre, y me gustaria saber si hay alguna
> regla
> > de "buenas costubres" mejor que elegir cualquier puerto desocupado.
>
> Como dijeron, puedes usar cualquier puerto. No tienes que pedirle
> permiso a la IANA si usas el puerto 25, si quieres.
>
> Ahora, hay ciertas convenciones "de facto" que se siguen. Puede ser
> "por que si" (todo el mundo lo hace) o porque la herramienta o el
> software esta configurado asi.
>
> Ejemplo del primer caso: casi todas las instalaciones tomcat y otras
> Java utilizan el puerto 8080. Hay mucho software que tambien usa
> defacto el puerto 8080 para cosas totalmente distintas (ejs: varios
> proxy's de web); asi que basicamente todos ponen "cualquier cosa
> no-root HTTP en el puerto 8080".
>
> Ejemplo del segundo caso: en WAS cuando creas un servidor nuevo en la
> misma maquina, automaticamente asigna el puerto siguiente (si el RMI
> para el servidor1 es 4444, el servidor2 es 4445; si el HTTP es 8080,
> el siguiente es 8081).
>
>
> Entonces la pregunta es: por que tienes que reemplazar el puerto 4444 ?
>
> --
> Aldrin Martoq
>
>
--
Atentamente.
Marco Bravo
http://marcosbravo.blogspot.com
From [EMAIL PROTECTED] Wed Sep 26 23:29:27 2007
From: [EMAIL PROTECTED] (Leonardo Soto M.)
Date: Wed Sep 26 23:58:28 2007
Subject: Evitar sql injection y xss
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On 9/26/07, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
> Leonardo Soto M. escribió:
> >
> > Seguro?. Ojo, que la solución práctica no es tan simple como
> > "escapemos todo el HTML que aparezca". También debe existir un
> > mecanismo para que se pueda incluir HTML cuando el desarrollador lo
> > necesite.
>
> Si, 100%, absolutamente seguro. todo lo que tu sugieres hacer se puede
> hacer con esas librerias o con el interprete ( con PHP 5.2 o superior) ,
Cierto. La verdad pasé por alto tu segundo mail, al principio de la
discusión. Es lejos la mejor recomendación anti-XSS (y
anti-SQLInjection) de todo este thread.
--
Leo Soto M.
