Decálogo de Principios de Seguridad para Desarrollo de Aplicaciones Web
Independientemente del lenguaje y/o plataforma de desarrollo que usted utilice, hay cosas que de una o de otra forma siempre hay que tomar en cuenta si queremos tener una aplicación web "relativamente" segura.
Además acoto la palabra "relativamente", porque en primer orden nunca se puede obtener una aplicación 100% segura. Dice un chiste de seguridad que la única aplicación segura es la que está desconectada del cualquier red, no se ejecuta y se introduce en un "bunker antiaéreo" sellado a 50 metros de profundidad y aún así nadie apostaría un ojo un ojo por defender la integridad de la misma.
Por lo tanto el presente artículo, tiene como fin el poner al lector al tanto de una serie de principios de seguridad que debería seguir en el proceso de desarrollo si realmente desea obtener un resultado favorable en lo referente a este tema.
Defensa en profundidad.
- Nunca confíe en un solo punto de defensa. Su aplicación en la mayoría de los casos será siempre la última línea de defensa entre el atacante y servidores del entorno de redes corporativas. Por tanto usted debe proveerle a su aplicación más de un método de defensa si desea proteger servidores de bases de datos e información sensible de la empresa.
Nunca confíe en las entradas de datos.
- Como usted podrá descubrir mediante un simple ejemplo de XSS o SQL injection, la mayoría de los problemas empiezan por creer que la validación del lado cliente en Javascript puede ser suficiente, suponer que la única forma de solicitar un tipo de datos es un formulario u olvidar validar que los datos no excedan la capacidad de un contenedor. En las aplicaciones web los datos pueden venir de cualquier parte, pueden ser y muchas veces son forjados, y su aplicación debe tener la capacidad de responder ante este hecho.
Controle los errores elegantemente.
- Aunque usted haya pensado en todo, siempre algo nuevo puede suceder para lo que la aplicación podría no estar preparada. Controle las respuestas de error y trate de no entregar en ellas información que pudiera ayudar al atacante a descubrir datos acerca de como está hecha o funcionan los procedimientos de la misma. Utilice siempre que sea posible controles de error (try - catch) para que su aplicación no muestre la típica página de error 500. Una simple página de error 403 (acceso denegado) puede decirle a un escaner de vulnerabilidades que un directorio sacado de un diccionario existe, y permitirle montar un aproximado de su la estructura de directorios por ensayo y error.
Esté atento a los ataques.
- Inclusive si usted maneja los errores elegantemente, usted pudiera no estar guardando en bitácora (log) cuáles son las causas de dichos errores. Hacerlo le permitirá corregirlos sin esperar que un usuario se los reporte y además podrá verificar si la aplicación está siendo o ha sido atacada y lo mejor de todo, podrá verificar cómo está siendo atacada.
Use los menores privilegios posibles.
- Posiblemente a la hora de desarrollar la aplicación usted no tenga inconvenientes en utilizar una cuenta de administrador de su servidor de bases de datos, pero dejar esa información de conexión administrativa para una aplicación que probablemente solo ejecute procesos que pudieran perfectamente asociarse a una cuenta con muchos menos privilegios, es una falla que puede costar cara si el atacante logra obtener acceso a algún archivo de configuración. Lo mismo sucede con la permisología de escritura y ejecución en directorios. Si solo necesita subir archivos a un directorio una vez, no tiene sentido dejar los privilegios de escritura de forma permanente. Use siempre los menores privilegios posibles para su aplicación.
Los Cortafuegos (Firewalls) y la Criptografía no son una panacea.
- Es muy fácil creer que por que algo está cifrado no podrá ser accedido, o que porque tenemos un firewall el atacante no podrá tener acceso al sistema. Ninguno de los anteriores es cierto. Los firewalls deben permitir el acceso al puerto en el que se desempeña su aplicación (típicamente el puerto 80 y el 443) y una sentencia SQL a través de un campo mal validado no puede ser bloqueada por este medio.
- Lo mismo sucede con la criptografía, hace años se consideraba muy seguro un hash MD5 o SHA1, hoy en día los ataques por diccionario y tablas de arcoiris nos hacen pensar en nuevos métodos y trucos de cifrado que antes no eran necesarios. El ancho de banda y la velocidad de procesamiento hacen posibles ataques por fuerza bruta que tiempo atrás eran impensables.
La Seguridad debe ser el estatus por defecto.
- Es muy fácil instalar un servicio, hardware o aplicación y dejar los atributos por defecto que vienen habilitados desde la casa matriz. Un ejemplo de esto es la cara lección que tuvo que aprender Microsoft por el caso del SQL Slammer, que atacaba el el servicio de SQL Browser que venía activo por defecto en todos los paquetes de SQL Server, cuando en realidad la gran mayoría de usuarios no lo necesitaba. Revise bien los atributos por defecto de sus instalaciones y no deje servicios activos que no necesita. Usted reducirá así la superficie de ataque y con ello el riesgo de uno.
El Documento OWASP Top 10
- OWASP desarrolló una lista de los 10 grupos de vulnerabilidades más comunes en orden de importancia. También creó ejemplos explicativos de las mismas y de cómo proteger a su aplicación de dichas fallas o vulnerabilidades. Usted no puede dejar de leeer este documento y de aplicar esta lista en el rastreo de los posibles errores de seguridad en su desarrollo. También puede acceder a una traducción hecha por mi persona de la lista en este enlace.
Manténgase un paso adelante
- Su aplicación si bien puede haber sido realizada con todo lo anterior en emnte por su propia naturaleza será expuesta a todo el mundo. Internet no es una capsula, nada más lejos de eso. Su aplicación estará disponible a todos los posibles atacantes mediante una simple consulta en un buscador. Google Hacking Database es un ejemplo de cómo obtener listados de posibles aplicaciones víctimas mediante el uso de búsquedas avanzadas en Google. Por tanto usted debe estar al tanto de cualquier tipo de vulnerabilidad descubierta para poder protegerse de ella antes de que un posible atacante descubra la falla en su sitio.
Mantenga el software de terceros actualizados.
- Su aplicación se basa en software desarrollado por terceros en mayor o menor grado. Usted la coloca en un servidor web (Apache, ISS, Nginx, etc) que a su vez corre en un sistema operativo. También accede a manejadores de bases de datos. Todos estos servicios suelen tener fallas y deben siempre que sea posible ejecutar en sus últimas actualizaciones. Usted también podría utilizar manejadores y componentes de terceros directamente en su aplicación. Este y todo tipo de software de terceros debe estar actualizado siempre que sea posible . Usted se sorprenderá al saber que los atacantes son los primeros en estar registrados en las listas de control de vulnerabilidades para saber cuáles versiones de determinado software son vulnerables a un determinado tipo de ataque.
Todos las anteriores son recomendaciones y principios generales que no dependen del tipo de lenguaje y/o plataforma de desarrollo que utilice. Son prácticamente obligaciones que tiene usted como desarrollador para con su empresa, sus clientes y sus usuarios. Téngalos en cuenta y se ahorrará muchas molestias.
Fuente
