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