viernes, septiembre 29, 2006

Seguridad en La Web

Este es el artículo que publicó PC World, en nosecualo numero, pero este verano, vamos.

----------------------------------------------------------------

Entre boquerón y cazón en adobo comentábamos varios personajes, dedicados al tema de la seguridad en este país, cómo está el tema en la web. Hablábamos, antes de pasar a mayores en un pub de la zona, de lo que significa para nosotros realizar los tests de intrusión en las empresas. “Es genial que nos paguen por romper cristales”, decía yo, “siempre encuentras algo”, comentaba otro con mucho más prestigio en este país y autoridad que el resto de “tapensales”. Él venía de hacer un test de intrusión a una empresa, que mediante una vulnerabilidad conocida, publicada y solventada hace mucho tiempo, le había permitido entrar hasta la cocina, yo venía de haber terminado otra que también había resultado “productiva” mediante la búsqueda de fallos en el código de la web.

Lo cierto es, que cuando se realiza un test de intrusión en una empresa suelen ser pocas las que aguantan un análisis hacker completo, de ahí los sorprendentes resultados que se pueden apreciar diariamente en la web de defacements de Zone-h (http://www.zone-h.org) donde se puede ver en tiempo real lo que se acaban de “cepillar” y se contabilizan más de 2000 intrusiones con éxito al día. Esto sucede incluso, con aquellas empresas que realizan test de intrusión periódicos pues la web es un entorno cambiante, que es modificado por los programadores muchas veces en cortos periodos de tiempo.

¿Por qué está así la situación?

Los motivos por los que se produce esta situación hoy en día en las webs de las empresas en España son diversos y a veces poco acotables, pero si tuviéramos que hacer una selección de los motivos que más se repiten serían los siguientes:

1.- Pruebas antes de puesta en producción: Probar es un rollo, esto lo sabemos todos, hacer la fase de pruebas no es divertido, además de requerir una disciplina y metodología que pocas veces se realiza, suele tener poco “glamour”. Al final, los productos se quedan en la web con las pruebas iniciales de funcionamiento y unidad que realiza el propio programador, aunque esto no sea confesable.

2.- Tests de seguridad externos: Como siempre decía un amigo que pasó a mejor vida (a programar en Google donde disfruta de una agitada vida londinense) “El código es como tu niño, si le tienes que pegar por su bien, lo haces, pero le pegas poco y flojito, cosa que otro no va a hacer igual”. Y es así, cuando alguien viene con ganas de probar, le va a arrear de lo lindo, así que es mejor haberlo probado todo lo posible antes con alguien externo que lo pruebe de verdad haciendo esas cosas que al programador, tal vez, nunca se le hubiera ocurrido realizar con su código.

3.- Percepción de la seguridad. La gente percibe la seguridad como un sentimiento, en un cliente nos dijeron: “yo con [este producto que no voy a decir el nombre] me siento seguro”, da igual que luego se demostrara que no lo fuera, él se sentía seguro, o “a mi no me van a atacar por que yo no he hecho nada”, sin olvidarnos de “Los hackers sólo atacan a Microsoft así que yo estoy a salvo porque no uso nada de Microsoft” o “Me da igual si me hacen algo, yo no tengo nada de valor” son reducciones simplistas de la percepción de la seguridad que generan un entorno fácil de vulnerar para los atacantes .

Aprovechando justo esta motivación, quiero hacer notar este defacement de un argentino que lo hace por amor a una mujer. ¡Qué Lindo!

http://www.zone-h.org/index2.php?option=com_mirrorwrp&Itemid=44&id=4291311

4.- Costes de los productos. A la hora de realizar un proyecto de desarrollo en la web, siempre hay dos costes que parecen no entrar dentro lo admisible: los costes de formación de los desarrolladores y los costes de la auditoría de seguridad. Son los costes prescindibles para reducir el montante de cualquier proyecto. Parece como si los programadores pudieran pasar de una tecnología de desarrollo a otra con solo planteárselo. “El que sabe programar en un lenguaje sabe programar en todos”. Quizás tirar bucles, variables, y resolver problemas algorítmicos, sí sea cierto, pero hoy en día las tecnologías .NET, plataformas Java o PHP funcionan de forma muy diferente y es necesario conocerlas en profundidad si lo que se desea es hacer código seguro. Además si no se conoce como actúa un atacante es más que probable que fallos típicos, documentados y redocumentados en la comunidad hacker, que dan lugar a técnicas de ataque, como SQL Injection, Cross-Site Scripting, Remote File Inclusión, WebTrojans, Hijacking, etc… se repitan una y otra vez.

Me preguntan muchas veces, al finalizar una sesión, una demo o una conferencia, sobre que contramedidas se pueden tomar para securizar una web publicada en Internet. La verdad es que cada uno tiene su visión de la seguridad pero existen ciertas reglas básicas que siempre se pueden aplicar.

1.- Te van a atacar, asúmelo. Es lo que hay, las alternativas son: Te van a atacar Sí o Sí. Lo que tenemos es que estar preparados para resistir el ataque.

2.- La seguridad no es un producto, es un proceso a lo largo del tiempo, así que cuando prepares tu plan de seguridad, piensa en las acciones que vas a ir realizando a lo largo del tiempo para mantenerla.

3.- Formación, Formación, Formación. Forma a tus desarrolladores en la tecnología elegida, forma a tus desarrolladores en seguridad y forma a tu equipo de seguridad en técnicas hacker.

4.- Que te pegue otro. Periódicamente planifica test de intrusión en tus sistemas con alguien externo. No te garantizan que tu sistema esté seguro, pero si te ayudan a saber si es capaz de resistir el ataque de alguien de un determinado nivel.

5.- No uses sólo herramientas automáticas. Estas hacen una parte grande del trabajo de la auditoría, pero un test de intrusión requiere la participación de un atacante “inteligente” detrás que sea capaz de “imaginar” acciones contra una aplicación web concreta.

6.- Defensa en profundidad: Aplica el máximo número de medidas de seguridad a todos los niveles que puedas siempre que una medida no anule a otra y no falle la disponibilidad del sistema. Nada esta de más en seguridad.

7.- Mínimo punto de exposición: Haz que un servidor o una aplicación web sólo ejecute el software estrictamente necesario para el cumplimiento de su rol. Cuantas menos cosas puedan fallar mejor.

8.- Mínimo privilegio posible: Configura el sistema y la aplicación para que cada componente se ejecute con la menor credencial posible dentro del sistema. Si algo queda comprometido que pueda hacer el menor daño posible.

Mantener una aplicación web segura exige disciplina, pero se puede conseguir independientemente de la tecnología utilizada,… aunque, hay algunas que lo ponen más fácil que otras. ;)

9 comentarios:

Anónimo dijo...

me ha encantado el artículo!! de verdad, mu bueno, aunque se hecha de menos un poco del lenguaje bronxtolita ese ;)
zorionak!

gogoz

Chema Alonso dijo...

Era el primero, no quería cantearme de comienzo!. El segundo está más..."suelto".

Anónimo dijo...

Muy bueno. Dan unas ganas tremendas de defacementar (que yo traduzco muy libremente por "partir la cara") a algunas organizaciones de mi entorno. Sin entrar en muchos detalles ¿dónde podría ir aprendiendo lo básico para partir caras?

Sentí no poder asistir a tu charla en Madrid, espero no perderme la siguiente. Con dos crios pequeños empezando el colegio y la guardería en estas fechas es difícil hacer planes.

Un abrazo. Daniel

Chema Alonso dijo...

Hola Dani,

gracias por el comentario.

Vamos a impartir unos cursitos de técnicas Hacking en Madrid.

Se llama Contramedias Hacker, por no llamarele "a tu estilo" ;)

Tienes la URL de registro

Del 23 al 26 de Octubre.

Anónimo dijo...

Muchas gracias por la información, parece muy interesante. Pero no creo que tenga los conocimientos mínimos para sacarle partido o para no provocar carcajadas entre asistentes y profesores :P

Yo me refería a conceptos básicos para ir empezando, y probablemente existe alguna web que me sirva de inicio. También puedo ir mirando la documentación en PDF de informatica64 si así me lo aconsejas. De nuevo gracias. Un saludo.

Chema Alonso dijo...

Bueno, no se que a velocidad iré escribiendo pero en el blog de http://www.itsasontzibaten.net estoy escribiendo sobre seguridad desde el principio.

Auditar un Sistema
Footprinting

Bies!

Anónimo dijo...

Pues como por algo hay que empezar iré leyendo ese Blog con fruición, y además todo lo que me ha traído la mula, que no es poco...

Muchas gracias por las molestias tomadas. A ver si voy aprendiendo algo y así podré asistir a alguna de tus charlas con alguna esperanza de enterarme de algo.

Saludos. Daniel

Chema Alonso dijo...

Gracias a ti Daniel!

Unknown dijo...

#234

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares