MULTIMEDIA, Video digital, Grabación, Diseño gráfico, Diseño web, Programación > Webmasters - Diseño Web - Programación - Diseño gráfico

Vulnerabilidad en wordpress 2.0 y 2.01

<< < (6/7) > >>

halo:
Hay muchas clases de discusiones, ésta ha sido interesante y con un tono cordial entre dos compañeros foriles, no creo que el maestro ese estuviera pensando en este tipo de discusiones cuando dijo lo que dijo y cuando lo dijo.

Es, o hubiera sido, interesante seguir y sacar una conclusión, más que nada porque esa información no es privada, es pública, y hay gente afectada por esas "vulnerabilidades", pero también las hay que no saben qué están haciendo cuando parchean o si realmente es necesario.

En cualquier caso, ha sido un placer. :-d

Un saluete, Mabel. ;-)

Liamngls:
Entonces hemos quedado en que cualquier vulnerabilidad por leve que sea debe ser parcheada a la mayor brevedad porque lo que hoy es una inocente tontería mañana puede ser un agujero de seguridad importante ¿ no ?

halo:

--- Cita de: Liamngls en 11 de Marzo de 2006, 07:59:09 am ---Entonces hemos quedado en que cualquier vulnerabilidad por leve que sea debe ser parcheada a la mayor brevedad porque lo que hoy es una inocente tontería mañana puede ser un agujero de seguridad importante ¿ no ?

--- Fin de la cita ---

Hola Liamngls :)

No es exactamente como lo planteas, pues tal y como lo planteas lo mejor sería no usar ningún tipo de CMS. Se trata de llevar el mantenimiento de una web gestionada a través de un CMS.

Éste que planteo sería un plan ->

Mantenimiento correctivo:


* Aplicación de parches oficiales.
* Solución a problemas creados por modificaciones personales.
Mantenimiento preventivo sistemático:


* Copia de seguridad BBDD.
* Copia seguridad archivos.
* Purgas.
Mantenimiento preventivo predictivo:


* Revisión permisos a archivos con contenido privado.
* Revisión codificación.
* Revisión de las partes de la web.
* Revisión logs.
* Revisión anomalías visuales.
Mantenimiento modificativo:


* Aplicación medidas extraordinarias a través de mods "oficiosos".
* Aplicación mejoras personales.
* Aplicación de medidas paliativas ante errores críticos de seguridad sin solución oficial.
Teniendo en cuenta esas claves (que pueden ser más o menos, seguro que se me olvida más de una interesante) han de crearse las rutinas.

Las "vulnerabilidades" encontradas, una vez evaluadas, forman parte del mantenimiento correctivo para todos aquellos que tienen correctamente configurado el servidor. Para los que no lo tienen entraría a formar parte del modificativo, el correctivo le corresponde a la configuración del servidor.

Edito: he hecho una modificación en los preventivos. Creo que así está mejor y no afecta a la conclusión final. Aunque la aplicación de este plan a la web no implica, según casos, la parada de la web creo que ahora está mejor clasificado.

Saluetes. :-d

Dabo:
muy bueno Halo, estoy de acuerdo con todos en general,todos decis cosas muy lógicas, voy a comentaros algo que todavía no he puesto en el Daboblog y que me queda pendiente, la configuración del php en un sistema en producción , debe tener la variable en el php.ini "display_errors" a Off, de este modo, es imposible que se vea el path cuando falle el php.

Partiendo de esa base, cuando Wordpress dice "es un problema de configuración del servidor, no nuestro", llevan su parte de razón. Donde tengo sentimientos encontrados es con una cosa, es una línea de código que no afecta para nada a la aplicación y es facilisimo, hay gente que no tiene acceso a ese tipo de configuraciones, un hosting compartido, el tipico en el que están alojadas 200 o 500 webs, ahí no hay nada que hacer por parte del usuario, o parcheas o nada.

Además se puede tener el que muestre errores en "off" y por detrás que esté corriendo un log en el que el administrador pueda ver que falla. Hay gente a la que le gusta tenerlo en "on" por no tirar de un log y porque sabes al momento que falla pero como digo, cuando el sistema está a punto, no tiene lógica tenerlo activado.

El problema es que ver el path en si no es un problema, hay cosas más graves pero cuando ciertos ataques o exploits van como más directos cuando sabes la ruta pues no se, son 2 líneas de código, lo hacen bien, el software es bueno y mucha gente lo usamos pero la crítica y la autocrítica creo que siempre es buena -:)

Paulet:
buenas

interesante hilo, con visiones diferentes, pero denoto sobre el tema demasiado alarmismo, hasta la fecha no correspondido con la realidad, cojonuda tu exposición halo, y excelente tu plan, habrá que tomar nota

salu2

Navegación

[0] Índice de Mensajes

[#] Página Siguiente

[*] Página Anterior

Ir a la versión completa