sirpask
Será en Octubre
- Desde
- 16 Oct 2009
- Mensajes
- 51.272
- Reputación
- 115.558
1. Introducción
La seguridad es un tema vital a la hora de desarrollar cualquier tipo de aplicación (y más si es una aplicación que contiene datos personales o de gran impacto social y mucho más si, además, va a estar expuesta como aplicación web accesible a un gran número de personas). Muchas veces, es un aspecto al que no se le dedica todo el esfuerzo y el cariño que se merece (desgraciadamente ). Es por esto que hay numerosos fallos de seguridad en las aplicaciones que comprometen el negocio llegando, incluso, a provocar pérdidas importantes (pérdidas tanto de información como pérdidas monetarias). Los usuarios debemos sentirnos seguros y tener cierta confianza en que nuestros datos que estamos cediendo van a ser protegidos contra posibles ataques (aunque lo que también tenemos que tener presente es que nuestra seguridad es siempre algo que va a estar en el punto de mira).
Las empresas deben ser responsables de ofrecer un servicio seguro y poner todos los esfuerzos posibles en hacer que así sea. La seguridad debería ser el primer aspecto a tener en cuenta a la hora de desarrollar cualquier aplicación y el desarrollo, por tanto, debería estar guiado o basado en aplicar metodologías que nos permitan realizar aplicaciones seguras. Para realizar un desarrollo seguro, en temas de seguridad, entre otras cosas, siempre es recomendable emplear frameworks o librerías de la comunidad o de empresas antes que aquellas desarrolladas por nosotros mismos (ya que nosotros no podemos tener toda la visión que puede tener una comunidad entera de desarrolladores). Por ejemplo, para evitar los ataques de SQL Injection, es recomendable emplear un framework de acceso a datos, como MyBatis o JPA en caso de una arquitectura Java, que ya incorpore mecanismos para evitar este tipo de ataques (también es importante saber usar los frameworks para hacer que estos ataques no sean posibles ya que si se usan mal no hemos conseguido nada) que realizar por nosotros mismos una librería de acceso a base de datos.
Muchas veces, no es siempre posible controlar que todo el desarrollo de las aplicaciones sea seguro (es una formación muy específica y hay empresas que no invierten suficiente en dicha formación), pero lo que sí es posible es realizar auditorías de seguridad sobre las aplicaciones ya desarrolladas para descubrir los posibles fallos de seguridad y tomar medidas en consecuencia. Tan importante es una auditoría de código como una auditoría de seguridad. De poco nos sirve que nuestra aplicación tenga una calidad elevada de código si tiene unos fallos de seguridad importantes a través de los cuales se puede obtener información sensible de los usuarios o comprometen nuestro negocio. Cierto es que algunas de las herramientas que se emplean para el análisis de la calidad de código ya indican si hay posibles fallos de seguridad, pero algunos fallos de seguridad no tienen lugar en el código sino en la configuración de la aplicación, del servidor donde residirá la aplicación, en los recursos empleados por la aplicación (bases de datos, FTP…) o incluso en el propio sistema operativo.
Es importante, por tanto, poder disponer de algún medio de referencia sobre la seguridad en aplicaciones web y aquellos fallos de seguridad más comunes dentro de las mismas. También, sería deseable poder disponer de herramientas que nos permitan analizar nuestras aplicaciones y obtener información de las vulnerabilidades que tienen. Menos mal que, afortunadamente, estamos de suerte y existe OWASP
2. ¿Qué es OWASP?
Open Web Application Security Project (OWASP) es una organización sin ánimo de lucro a nivel mundial dedicada a mejorar la seguridad de las aplicaciones y del software en general. Su misión es hacer que la seguridad dentro de las aplicaciones sea más visible para que, así, las organizaciones y los particulares puedan tomar decisiones sobre conceptos de seguridad basándose en información verídica y contrastada.
Es importante destacar que cualquiera puede participar en OWASP y que todos sus proyectos, materiales y documentación están disponibles de forma gratuita. Del mismo modo, y algo importante, es que todos los productos y servicios recomendados no son productos comerciales, sino que son productos también libres y de código abierto.
Como organización, tienen una serie de valores:
tras*parencia: todo lo relativo a OWASP es tras*parente, desde sus finanzas (que pueden ser consultadas directamente desde su página web) hasta el código de sus proyectos (los repositorios de código también están accesibles).
Innovación: promueven y favorecen la experimentación para aquellas soluciones a los nuevos desafíos de seguridad que aparecen.
Global: cualquier persona de cualquier parte del mundo está invitada a participar en la comunidad de OWASP (se puede aplicar desde un formulario).
Integridad: se declaran como una comunidad honesta y en la que se puede confiar. También se declaran neutrales sobre el aspecto comercial de los productos de seguridad disponibles en el mercado, no posicionándose sobre alguno de ellos.
Por lo tanto, OWASP pretende ser el centro de referencia de toda la información de seguridad enfocada a las aplicaciones web. Ya veremos que no sólo información sino también estudios, soluciones y proyectos con los que nos ayudarán a los desarrolladores a hacer que nuestras aplicaciones web sean más seguras.
3. Top 10 vulnerabilidades más comunes
OWASP, cada cierto tiempo, realiza un informe recogiendo las vulnerabilidades más comunes dentro de las aplicaciones web. Con este informe, podremos estar al tanto de dichas vulnerabilidades y podremos emplearlo para comprobar si nuestra aplicación tiene alguna de las que aparecen en dicho informe. También, ofrecen herramientas de detección y consejos sobre medidas a tomar para solucionar dicha vulnerabilidad.
A continuación, vamos a enumerar las 10 vulnerabilidades más comunes del informe realizado hasta 2013 (podéis acceder al documento íntegro desde aquí) y vamos a aportar una breve descripción sobre cada una de las vulnerabilidades:
Inyección: este ataque se produce cuando datos no confiables son enviados a un intérprete (ya sea del sistema operativo, de una base de datos o cualquier intérprete) como parte de un comando o consulta. Los datos hostiles introducidos por el atacante pueden engañar al intérprete haciendo que se ejecuten comandos no intencionados o accediendo a información sobre la que no se está autorizado. Uno de los ejemplos más significativos de este tipo de ataque es SQL Injection.
Pérdida de autenticación y gestión de sesiones: este tipo de ataque se produce cuando los mecanismos de la aplicación relacionados con la autenticación, autorización y control de sesiones son, frecuentemente, implementados de forma incorrecta o su configuración no se ha realizado de forma correcta. Esto provoca que un usuario malicioso pueda obtener las credenciales de un usuario, el identificador de la sesión o, incluso, el identificador de acceso y hacerse pasar por dicho usuario accediendo a todos sus datos. Uno de los ejemplos puede ser la gestión de la sesión mediante la propia página.
Secuencia de comandos en sitios cruzados (XSS): este tipo de ataque ocurre cuando se obtienen datos no confiables y se envían directamente al navegador web. Esto provoca que se puedan ejecutar comandos no deseados en el navegador del usuario. Estos comandos pueden obtener desde las credenciales de acceso del usuario como instalar ciertos programas maliciosos.
Referencia directa insegura a objetos: este tipo de ataque ocurre cuando no se controlan los accesos a recursos sobre los que un usuario no debería tener acceso. En las aplicaciones, la mayoría de las veces, existen distintos usuarios y cada usuario tiene una serie de recursos sobre los que tiene acceso y otros sobre los que no debería tener acceso. Un ejemplo podría ser el acceso a una tabla de base de datos sobre la que un determinado usuario no debería tener acceso (una tabla de gestión sobre la que sólo el administrador debería tener acceso).
Configuración de seguridad incorrecta: este tipo de ataque ocurre cuando se han realizado malas configuraciones en las aplicaciones, en los servidores de las aplicaciones, en las bases de datos o en la configuración del propio sistema operativo. Es importante tener todo el software bien actualizado con la última versión disponible (esperando a que no haya vulnerabilidades de día 0 ) y que todas las librerías o frameworks que use la aplicación también estén actualizadas ya que muchos cambios que se realizan en las versiones tienen que ver con aspectos de seguridad.
Exposición de datos sensibles: este tipo de ataque ocurre cuando se puede acceder de forma fácil a datos de carácter sensible almacenados en la aplicación. Cuando, por ejemplo, se almacenan las credenciales de los usuarios sin codificar o si la comunicación del servidor no es segura a la hora de realizar un pago con un tarjeta de crédito.
Ausencia de control de acceso a funciones: este tipo de ataque ocurre cuando se acceden a funciones del servidor sobre las que un usuario no debería tener permiso. Cuando, por ejemplo, el servicio de listado de usuario sólo debería estar disponible por la aplicación pero cualquier usuario puede también acceder a esta información.
Falsificación de peticiones en sitios cruzados: este tipo de ataque ocurre cuando se realizan peticiones HTTP falsificadas del ordenador de la víctima a una aplicación web vulnerable.
Utilización de componentes con vulnerabilidades conocidas: este tipo de ataque ocurre cuando se emplean librerías o frameworks que contienen vulnerabilidades. Es por esto que es importante actualizar estos componentes o revisar el histórico de revisiones para comprobar las mejoras de seguridad implementadas.
Redirecciones y reenvíos validados: este tipo de ataque ocurre cuando, al redireccionar al usuario a otra página, no se comprueba que el destino sea válido. Es por esto que se puede redirigir a un usuario a una página que contenga contenido malicioso para robar las credenciales de dicho usuario.
Una vez se han visto los 10 ataques más comunes, es importante destacar que casi siempre se usan ataques combinados para aprovecharse de todas las vulnerabilidades. Se puede hacer un ataque de SQL Injection para acceder a una tabla sobre la que el usuario no debería tener permiso para tener acceso a credenciales no codificadas de los usuarios del sistema. Por lo que es importante centrarse en todas y cada una de estas vulnerabilidades.
4. Herramientas
OWASP también realiza una serie de proyectos con el objetivo de darnos herramientas para afianzar la seguridad de nuestras aplicaciones. Estos proyectos se pueden acceder desde el siguiente enlace.
A continuación, se muestran algunos de estos proyectos junto con una breve descripción de cada uno de ellos (para acceder a la lista entera podéis acceder desde aquí):
Zed Attack Proxy: es una herramienta de pentesting que nos ayuda a encontrar vulnerabilidades en nuestras aplicaciones. Es recomendable el uso por gente con cierta experiencia en términos de seguridad.
OWTF: es una herramienta de pentesting que es, quizás, un poco más sencilla que la herramienta anterior.
Dependency Check: es una herramienta que nos permite analizar todas las dependencias de nuestra aplicación y comprobar si existen vulnerabilidades dentro de ellas.
Mobile Security Project: es una herramienta que nos permite realizar pentesting sobre aplicaciones móviles.
SSL advanced forensic tool: es una herramienta que nos permite mostrar información sobre SSL y los certificados.
Existen muchos proyectos más y es recomendable echar un vistazo a todos ellos ya que nos ayudan (y mucho) a nuestro objetivo de asegurar la seguridad en nuestra aplicaciones.
5. Conclusiones
Ya hemos visto, muy por encima, qué es OWASP y todas las bondades que nos ofrece. Con esto en mente, es importante dedicarle tiempo a conocer las vulnerabilidades y a conocer también los mecanismos para corregirlas. En futuros tutoriales, analizaremos las vulnerabilidades más comunes y aportaremos una serie de soluciones para poder corregirlas. Del mismo modo, también analizaremos las distintas herramientas que nos proporciona OWASP para realizar análisis de nuestras aplicaciones.
6. Referencias
Open Web Application Security Project (OWASP)
Regalo:
owasp-masvs/Document-es at master · OWASP/owasp-masvs · GitHub
La seguridad es un tema vital a la hora de desarrollar cualquier tipo de aplicación (y más si es una aplicación que contiene datos personales o de gran impacto social y mucho más si, además, va a estar expuesta como aplicación web accesible a un gran número de personas). Muchas veces, es un aspecto al que no se le dedica todo el esfuerzo y el cariño que se merece (desgraciadamente ). Es por esto que hay numerosos fallos de seguridad en las aplicaciones que comprometen el negocio llegando, incluso, a provocar pérdidas importantes (pérdidas tanto de información como pérdidas monetarias). Los usuarios debemos sentirnos seguros y tener cierta confianza en que nuestros datos que estamos cediendo van a ser protegidos contra posibles ataques (aunque lo que también tenemos que tener presente es que nuestra seguridad es siempre algo que va a estar en el punto de mira).
Las empresas deben ser responsables de ofrecer un servicio seguro y poner todos los esfuerzos posibles en hacer que así sea. La seguridad debería ser el primer aspecto a tener en cuenta a la hora de desarrollar cualquier aplicación y el desarrollo, por tanto, debería estar guiado o basado en aplicar metodologías que nos permitan realizar aplicaciones seguras. Para realizar un desarrollo seguro, en temas de seguridad, entre otras cosas, siempre es recomendable emplear frameworks o librerías de la comunidad o de empresas antes que aquellas desarrolladas por nosotros mismos (ya que nosotros no podemos tener toda la visión que puede tener una comunidad entera de desarrolladores). Por ejemplo, para evitar los ataques de SQL Injection, es recomendable emplear un framework de acceso a datos, como MyBatis o JPA en caso de una arquitectura Java, que ya incorpore mecanismos para evitar este tipo de ataques (también es importante saber usar los frameworks para hacer que estos ataques no sean posibles ya que si se usan mal no hemos conseguido nada) que realizar por nosotros mismos una librería de acceso a base de datos.
Muchas veces, no es siempre posible controlar que todo el desarrollo de las aplicaciones sea seguro (es una formación muy específica y hay empresas que no invierten suficiente en dicha formación), pero lo que sí es posible es realizar auditorías de seguridad sobre las aplicaciones ya desarrolladas para descubrir los posibles fallos de seguridad y tomar medidas en consecuencia. Tan importante es una auditoría de código como una auditoría de seguridad. De poco nos sirve que nuestra aplicación tenga una calidad elevada de código si tiene unos fallos de seguridad importantes a través de los cuales se puede obtener información sensible de los usuarios o comprometen nuestro negocio. Cierto es que algunas de las herramientas que se emplean para el análisis de la calidad de código ya indican si hay posibles fallos de seguridad, pero algunos fallos de seguridad no tienen lugar en el código sino en la configuración de la aplicación, del servidor donde residirá la aplicación, en los recursos empleados por la aplicación (bases de datos, FTP…) o incluso en el propio sistema operativo.
Es importante, por tanto, poder disponer de algún medio de referencia sobre la seguridad en aplicaciones web y aquellos fallos de seguridad más comunes dentro de las mismas. También, sería deseable poder disponer de herramientas que nos permitan analizar nuestras aplicaciones y obtener información de las vulnerabilidades que tienen. Menos mal que, afortunadamente, estamos de suerte y existe OWASP
2. ¿Qué es OWASP?
Open Web Application Security Project (OWASP) es una organización sin ánimo de lucro a nivel mundial dedicada a mejorar la seguridad de las aplicaciones y del software en general. Su misión es hacer que la seguridad dentro de las aplicaciones sea más visible para que, así, las organizaciones y los particulares puedan tomar decisiones sobre conceptos de seguridad basándose en información verídica y contrastada.
Es importante destacar que cualquiera puede participar en OWASP y que todos sus proyectos, materiales y documentación están disponibles de forma gratuita. Del mismo modo, y algo importante, es que todos los productos y servicios recomendados no son productos comerciales, sino que son productos también libres y de código abierto.
Como organización, tienen una serie de valores:
tras*parencia: todo lo relativo a OWASP es tras*parente, desde sus finanzas (que pueden ser consultadas directamente desde su página web) hasta el código de sus proyectos (los repositorios de código también están accesibles).
Innovación: promueven y favorecen la experimentación para aquellas soluciones a los nuevos desafíos de seguridad que aparecen.
Global: cualquier persona de cualquier parte del mundo está invitada a participar en la comunidad de OWASP (se puede aplicar desde un formulario).
Integridad: se declaran como una comunidad honesta y en la que se puede confiar. También se declaran neutrales sobre el aspecto comercial de los productos de seguridad disponibles en el mercado, no posicionándose sobre alguno de ellos.
Por lo tanto, OWASP pretende ser el centro de referencia de toda la información de seguridad enfocada a las aplicaciones web. Ya veremos que no sólo información sino también estudios, soluciones y proyectos con los que nos ayudarán a los desarrolladores a hacer que nuestras aplicaciones web sean más seguras.
3. Top 10 vulnerabilidades más comunes
OWASP, cada cierto tiempo, realiza un informe recogiendo las vulnerabilidades más comunes dentro de las aplicaciones web. Con este informe, podremos estar al tanto de dichas vulnerabilidades y podremos emplearlo para comprobar si nuestra aplicación tiene alguna de las que aparecen en dicho informe. También, ofrecen herramientas de detección y consejos sobre medidas a tomar para solucionar dicha vulnerabilidad.
A continuación, vamos a enumerar las 10 vulnerabilidades más comunes del informe realizado hasta 2013 (podéis acceder al documento íntegro desde aquí) y vamos a aportar una breve descripción sobre cada una de las vulnerabilidades:
Inyección: este ataque se produce cuando datos no confiables son enviados a un intérprete (ya sea del sistema operativo, de una base de datos o cualquier intérprete) como parte de un comando o consulta. Los datos hostiles introducidos por el atacante pueden engañar al intérprete haciendo que se ejecuten comandos no intencionados o accediendo a información sobre la que no se está autorizado. Uno de los ejemplos más significativos de este tipo de ataque es SQL Injection.
Pérdida de autenticación y gestión de sesiones: este tipo de ataque se produce cuando los mecanismos de la aplicación relacionados con la autenticación, autorización y control de sesiones son, frecuentemente, implementados de forma incorrecta o su configuración no se ha realizado de forma correcta. Esto provoca que un usuario malicioso pueda obtener las credenciales de un usuario, el identificador de la sesión o, incluso, el identificador de acceso y hacerse pasar por dicho usuario accediendo a todos sus datos. Uno de los ejemplos puede ser la gestión de la sesión mediante la propia página.
Secuencia de comandos en sitios cruzados (XSS): este tipo de ataque ocurre cuando se obtienen datos no confiables y se envían directamente al navegador web. Esto provoca que se puedan ejecutar comandos no deseados en el navegador del usuario. Estos comandos pueden obtener desde las credenciales de acceso del usuario como instalar ciertos programas maliciosos.
Referencia directa insegura a objetos: este tipo de ataque ocurre cuando no se controlan los accesos a recursos sobre los que un usuario no debería tener acceso. En las aplicaciones, la mayoría de las veces, existen distintos usuarios y cada usuario tiene una serie de recursos sobre los que tiene acceso y otros sobre los que no debería tener acceso. Un ejemplo podría ser el acceso a una tabla de base de datos sobre la que un determinado usuario no debería tener acceso (una tabla de gestión sobre la que sólo el administrador debería tener acceso).
Configuración de seguridad incorrecta: este tipo de ataque ocurre cuando se han realizado malas configuraciones en las aplicaciones, en los servidores de las aplicaciones, en las bases de datos o en la configuración del propio sistema operativo. Es importante tener todo el software bien actualizado con la última versión disponible (esperando a que no haya vulnerabilidades de día 0 ) y que todas las librerías o frameworks que use la aplicación también estén actualizadas ya que muchos cambios que se realizan en las versiones tienen que ver con aspectos de seguridad.
Exposición de datos sensibles: este tipo de ataque ocurre cuando se puede acceder de forma fácil a datos de carácter sensible almacenados en la aplicación. Cuando, por ejemplo, se almacenan las credenciales de los usuarios sin codificar o si la comunicación del servidor no es segura a la hora de realizar un pago con un tarjeta de crédito.
Ausencia de control de acceso a funciones: este tipo de ataque ocurre cuando se acceden a funciones del servidor sobre las que un usuario no debería tener permiso. Cuando, por ejemplo, el servicio de listado de usuario sólo debería estar disponible por la aplicación pero cualquier usuario puede también acceder a esta información.
Falsificación de peticiones en sitios cruzados: este tipo de ataque ocurre cuando se realizan peticiones HTTP falsificadas del ordenador de la víctima a una aplicación web vulnerable.
Utilización de componentes con vulnerabilidades conocidas: este tipo de ataque ocurre cuando se emplean librerías o frameworks que contienen vulnerabilidades. Es por esto que es importante actualizar estos componentes o revisar el histórico de revisiones para comprobar las mejoras de seguridad implementadas.
Redirecciones y reenvíos validados: este tipo de ataque ocurre cuando, al redireccionar al usuario a otra página, no se comprueba que el destino sea válido. Es por esto que se puede redirigir a un usuario a una página que contenga contenido malicioso para robar las credenciales de dicho usuario.
Una vez se han visto los 10 ataques más comunes, es importante destacar que casi siempre se usan ataques combinados para aprovecharse de todas las vulnerabilidades. Se puede hacer un ataque de SQL Injection para acceder a una tabla sobre la que el usuario no debería tener permiso para tener acceso a credenciales no codificadas de los usuarios del sistema. Por lo que es importante centrarse en todas y cada una de estas vulnerabilidades.
4. Herramientas
OWASP también realiza una serie de proyectos con el objetivo de darnos herramientas para afianzar la seguridad de nuestras aplicaciones. Estos proyectos se pueden acceder desde el siguiente enlace.
A continuación, se muestran algunos de estos proyectos junto con una breve descripción de cada uno de ellos (para acceder a la lista entera podéis acceder desde aquí):
Zed Attack Proxy: es una herramienta de pentesting que nos ayuda a encontrar vulnerabilidades en nuestras aplicaciones. Es recomendable el uso por gente con cierta experiencia en términos de seguridad.
OWTF: es una herramienta de pentesting que es, quizás, un poco más sencilla que la herramienta anterior.
Dependency Check: es una herramienta que nos permite analizar todas las dependencias de nuestra aplicación y comprobar si existen vulnerabilidades dentro de ellas.
Mobile Security Project: es una herramienta que nos permite realizar pentesting sobre aplicaciones móviles.
SSL advanced forensic tool: es una herramienta que nos permite mostrar información sobre SSL y los certificados.
Existen muchos proyectos más y es recomendable echar un vistazo a todos ellos ya que nos ayudan (y mucho) a nuestro objetivo de asegurar la seguridad en nuestra aplicaciones.
5. Conclusiones
Ya hemos visto, muy por encima, qué es OWASP y todas las bondades que nos ofrece. Con esto en mente, es importante dedicarle tiempo a conocer las vulnerabilidades y a conocer también los mecanismos para corregirlas. En futuros tutoriales, analizaremos las vulnerabilidades más comunes y aportaremos una serie de soluciones para poder corregirlas. Del mismo modo, también analizaremos las distintas herramientas que nos proporciona OWASP para realizar análisis de nuestras aplicaciones.
6. Referencias
Open Web Application Security Project (OWASP)
Regalo:
owasp-masvs/Document-es at master · OWASP/owasp-masvs · GitHub
