| Artículos | 01 SEP 2006

La seguridad en la web

Tags: Histórico
Chema Alonso.
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 2.000 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 períodos 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 del 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 porque 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.
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 sólo planteárselo. “El que sabe programar en un lenguaje sabe programar en todos”. Quizá 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 cómo 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, o Hijacking, por ejemplo, se repitan una y otra vez.
Me preguntan muchas veces, al finalizar una sesión, una demo o una conferencia, sobre qué 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.- Le van a atacar, asúmalo. Es lo que hay, las alternativas son: le 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 prepare su plan de seguridad, piense en las acciones que va a ir realizando a lo largo del tiempo para mantenerla.
3.- Formación, Formación, Formación. Forme a sus desarrolladores en la tecnología elegida, forme a sus desarrolladores en seguridad y forme a su equipo de seguridad en técnicas hacker.
4.- Que le pegue otro. Periódicamente planifique test de intrusión en sus sistemas con alguien externo. No le garantizan que su sistema esté seguro, pero sí le ayudan a saber si es capaz de resistir el ataque de alguien de un determinado nivel.
5.- No use 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. Aplique 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 está de más en seguridad.
7.- Mínimo punto de exposición. Haga 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. Configure 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.


Chema Alonso. Microsoft MVP Windows Security. Informática 64. Consultor de Seguridad

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información