Ciclos de vida del Software Seguro (S-SDLC)

OWASP TOP 10 2017	OWASP TOP 10 2013
1→ Inyección	1→ Inyección
2→ Perdida de autenticación y gestión de sesión	2→ Perdida de autenticación y gestión de sesión
3→ Secuencia de comandos en sitios cruzados (XSS)	3→ Secuencia de comandos en sitios cruzados (XSS)
4→ Control de acceso sin protección	4→ Referencia directa insegura a objetos
5→ Configuración de seguridad incorrecta	5→ Configuración de seguridad incorrecta
6→ Exposición de datos sensibles	6→ Exposición de datos sensibles
7→ Protección insuficiente contra ataques	7→ Ausencia de control de acceso a las funciones
8→ Falsificación de petición en sitios cruzados (CSRF)	8→ Falsificación de petición en sitios cruzados (CSRF)
9→ Uso de componentes con vulnerabilidades conocidas	9→ Uso de componentes con vulnerabilidades conocidas
10→ API’s bajo protección	10→ Redirección y reenvíos no válidos

Como se puede observar son 7 vulnerabilidades las que coinciden. Esto denota que los desarrolladores no están concienciados en desarrollar de una manera segura puesto que se vuelven a repetir los mismos errores de seguridad años después.

Yo nunca tengo la culpa.

Ataque a la página de la presidencia española de la U.E. el 5 de enero de 2010

Para que no nos ocurran sucesos como los de la imagen anterior deberíamos mitigar estos fallos de seguridad en aplicaciones web lo que se puede realizar en un alto grado, puesto que no existe 100% de seguridad, utilizando técnicas de S-SDLC.

Fases y roles en la S-SDLC.

El SDLC, Systems Development Life Cycle, son unas técnicas de desarrollo que permiten crear un software de calidad desde que empezamos el proyecto, es muy importante que incorporemos a estas técnicas de desarrollo una capa de seguridad. Esta capa de seguridad debe cumplir al menos los principios de confidencialidad, integridad y disponibilidad para considerar que son seguros.

Al tratarse de un ciclo conlleva a que tenga iteraciones que deben de ejecutarse durante todo el periodo de vida de las aplicaciones.

Ciclo de vida del SDLC

El primer paso sería establecer requerimientos y controles de seguridad (Security

requirements) para el ciclo de desarrollo de software los cuales tienen que poder cuantificarse.

-Control de autenticación (creación de usuarios con contraseña robusta).

-Control de roles y privilegios(cada usuario tan solo debe tener acceso a lo necesario dentro de la aplicación).

-Requerimientos orientados al riesgo(requerir contraseñas y metodos de autenticacion fiables).

-Aprobación de privilegios(mínimo privilegio, autorizar a cada usuario el acceso imprescindible).

La siguiente fase sería de análisis y diseño (Threat Modeling) puesto que muchas fallos de seguridad en las aplicaciones fueron detectados en la fase de diseño de las mismas.

-Diseño seguro de mensajes de error(no se debe poder interactuar con los mensajes de error por que pudieran dar acceso a la aplicación) .

-Diseño seguro de autenticación(para evitar errores como los de tener acceso con 1=1 y descartar eso datos de entrada).

-Diseño de autoría y loggin(seria un diseño centrado en usabilidad pero sin dejar de lado el no acceso sin contraseña a los servicios).

-Análisis de riesgo(analizar la aplicación en busca de posibles riesgos que pudieran aparecer en esta fase de análisis y diseño).

Después se llevará a cabo la fase de implementación y codificación, una falta de control en la codificación puede conllevar a que se comprometa la aplicación y los datos de la misma (Security architesture desing review). Unas buenas prácticas para la codificación segura serian.

-Validar siempre los datos de entrada antes de procesarlos(comprobar que los datos son correctos por ejemplo que no son sentencias SQL que darían acceso a un atacante a la base de datos).

-Controlar el tamaño y tipos de datos de entrada(controlar lo datos que se ingresan en formularios etc para evitar riesgos de entradas que comprometan la aplicación).

-Eliminar caracteres especiales(para que no se puedan ingresar sentencias de programación que pudieran dar lugar a procesarlas por la aplicación).

-Transformar lo datos de entrada en un encoding establecido(transformar estos datos para un mejor tratamiento por ejemplo transformar todas la letras en minúsculas).

-No mezclar datos con código(para evitar errores de procesamiento con lo que podría llevar a un fallo de seguridad).

-Reemplazar sentencias SQL dinámicas por Stored procedures(procedimiento almacenado por lo que no se necesita manipular los datos tan solo es necesario ofrecerlos al usuario).

Análisis de código estático y Dinámico (Static & dinamics, analisis secure code reviews) que trataria como su nombre indica de un analisis del codigo en estático (mirando el código sin que la aplicación se esté ejecutando y un análisis con la aplicación ejecutándose.

Por último el test de penetración y seguridad ( Security testing, Penetration testing, secure configuration), qu trataría de realizar una auditoria de hacking etico de seguridad con la finalidad de detectar las vulnerabilidades y subsanarlas realizando por último una configuración de seguridad.

Ataque de Anonymous a la WEB del PP en 2011

En próximos artículos veremos cómo implementar este sistema de desarrollo seguro, para que no ocurran acciones como la de la imagen anterior en nuestros desarrollos, sean del tipo que sean.

Un saludo developers.