seguridad web mediante spring mvc y hdiv

Seguridad web mediante Spring MVC y HDIV

Roberto Velasco Sarasola

• Experiencia:– Seguridad informática: s21sec (2001-2003)– Desarrollo web en entornos Java: EuroHelp (2004-2012)

• Fundador del proyecto open-source HDIV junto con Gorka Vicente (2005)

• Actualmente responsable de Arquitectura de EuroHelp

Sobre el autor

Contenidos

• Riesgos web (OWASP top ten)• Soluciones de seguridad tradicionales• Arquitecturas seguras• HDIV • Integración HDIV & Spring MVC • Aplicación de ejemplo• Futuras versiones de HDIV

• Las principales referencias en el mundo de la seguridad (securityfocus, CVE, …) indican que el principal riesgo proviene de la capa de aplicación

• Habitualmente relacionamos el concepto de seguridad a nivel aplicación con:– Autenticación (usuario/password, certificado)– Control de acceso:

• Controlar si un usuario puede acceder a una pantalla• Controlar si un usuario puede acceder o modificar un dato

Riesgos web

• Es suficiente con preocuparnos de la autenticación y el control de acceso?

• No podemos olvidarnos de los riesgos inherentes a las aplicaciones web– Son el principal foco de problemas de seguridad

• Los principales riesgos web están documentados– Incluidos en el Top Ten de OWASP 2010

Riesgos web

• OWASP (Open Web Application Security Project) top ten

– A1 - Injection– A2 - Cross site scripting– A3 - Broken Authentication and Session Management– A4 - Insecure Direct Object Reference – A5 - Cross – site Request Forgery– A6 - Security Misconfiguration– A7 - Failure to restrict URL access– A8 - Insecure Cryptographic Storage– A9 - Insufficient transport Layer– A10- Unvalidated Redirects and forwards

Riesgos web (OWASP top ten)

• Inyection Flaws (A1)

– El más importante: SQL injection

– Permite la modificación de las SQL-s ejecutadas en el servidor


• Inyection Flaws (A1) - Ejemplo

String data =

request.getParameter(“data”);

String sql= “select campo1 from tabla1 where id=‘” + data + ‘”

select campo1 from tabla1 where id=‘12’

http://host?data=12


• Inyection Flaws (A1) - Ejemplo

String data=

request.getParameter(“data”);

String sql= “select campo1 from tabla1 where id=‘” + data + ‘”

select campo1 from tabla1 where id=‘12’ or ‘1’=‘1’

http://host?data=12’ or ‘1’=‘1


• Inyection Flaws (A1) - Consecuencias

– Modificación de la BBDD

– Consulta de datos ajenos

– …


• SQL Injection (A1) - Recomendaciones

– Utilizar PreparedStatement en las consultas• Soluciona el problema de raíz no permitiendo esta vulnerabilidad

– Validación de entrada (whitelist en lo posible)


• Cross site scripting o XSS (A2)

– Permite la ejecución de scripts (Javascript,HTML,..) en el navegador de los clientes

– Existen diferentes tipos de XSS:

• Reflected: cuando una página visualiza directamente el dato (script) enviado por el atacante

• Stored: cuando el script se consigue almacenarlo en el servidor (BBDD, fichero). Este es especialmente grave puesto que puede afectar a muchos usuarios, ejemplos: foros, CRM,…


• Cross site scripting o XSS (A2) - Ejemplo



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head> <title>XSS Vulnerability Sample</title> </head>

<body>

<h1>XSS Vulnerability Sample</h1>

<form method="GET" action="XSS.jsp">

Enter string here:

<input type="text" name="userInput" size=50>

<input type=submit value="Submit">

</form>

<br> <hr> <br>

Output from last command: <%= request.getParameter("userInput")%>

<body>

</html>


• Cross site scripting o XSS (A2) – Ejemplo

– Si introducimos el siguiente texto en la caja de texto:

<script>

alert(“If you see that you have a potential XSS Vulnerability”);

</script>


• Cross site scripting o XSS (A2) – Consecuencias

• Robo de sesiones • Modificación de páginas• Es una de las bases para el

phising


• Cross Site Scripting (A2) – Recomendaciones

– Utilizar los tags de los frameworks web• Escapan la salida de los datos evitando el XSS

– Validación de entrada (whitelist en lo posible)


• Broken Authentication and session management (A3)

– Se trata de romper el sistema de autenticación o el mantenimiento de la sesión

• Por ejemplo haciendo uso del referer en caso de que se incluya el jsessionid en la url

– Los sistemas proporcionados por los servidores son seguros


• Insecure Direct Object Reference (A4)

– Habitualmente una página HTML está llena de referencias de datos del servidor (identificadores BBDD, paths de ficheros,…)

– El cliente puede modificar dichos datos y acceder a datos que no le corresponden


• Insecure Direct Object Reference (A4)- Ejemplo – En este caso el cliente puede seleccionar una cuenta que

no le corresponde

<select name=“cuentas”>

<option value=“20771111422000086456”>cuenta1</option>

<option value=“20771111422000086487”>cuenta2</option>

</select>


• Cross Site Request Forgery (A5)

– Se basa en provocar que un usuario autenticado realice una petición que favorezca al atacante

– La base del ataque habitualmente es una vulnerabilidad de XSS


• Cross Site Request Forgery (A5) - Ejemplo

– El atacante ha puesto un mensaje en un foro vulnerable a XSS con el siguiente código:

– La base del ataque habitualmente es una vulnerabilidad de XSS

<img src="http://www.example.com/transfer.do?

frmAcct=document.form.frmAcct&toAcct=4345754&

toSWIFTid=434343 &amt=3434.43">


• Security Misconfiguration (A6)

• Insecure Cryptographic storage (A7)

• Failure to Restrict Url Access (A8)

• Insufficient Transport Layer Protection (A9)

• Unvalidated Redirects and Forwards (A10)


• Habitualmente las aplicaciones web son desarrolladas sobre entornos de desarrollo o frameworks web (librerías)

• Entornos de desarrollo más utilizados:– Java (Struts 1, JSF, Spring MVC, Struts 2, …)– Groovy/Grails– .NET (Web Forms, MVC)– PHP– Ruby– …

Soluciones de seguridad tradicionales

• La mayoría de entornos de desarrollo ofrecen soluciones para la seguridad tradicional:– Autenticación – Control de acceso

• Url (a nivel pantalla)• Método de negocio• Componente gráfico• Instancia (registro BD)


• Los usuarios (posibles atacantes) disponen de una gran libertad– Los entornos de desarrollo o el propio protocolo HTTP permiten

una gran libertad

• Gracias a esta libertad se alimenta todo tipo de riesgos que fomentan la proliferación de vulnerabilidades


• Las soluciones ofrecidas por los entornos de desarrollo actuales obligan a la creación de soluciones manuales

• Una aplicación es insegura por defecto– Debe ser securizada de forma manual


• Gran parte de las arquitecturas o soluciones actuales delegan mucha responsabilidad a las personas

– La solución es manual y muy costosa (las implicaciones económicas son importantes)• Especialmente la seguridad a nivel instancia

– Posible solución Diseñar entornos de desarrollo o arquitecturas seguras• Secure by Design• Secure by Default

Arquitecturas seguras

• No es posible realizar ningún ataque siempre y cuando el usuario se limite a un uso esperado de la aplicación– En caso contrario estaríamos ante un caso de un funcionamiento

inadecuado

– Es más sencillo eliminar el riesgo que dar solución a todas las consecuencias

Arquitecturas seguras

• Solución open-source (Apache 2.0) creada en 2005– Impulsado por la empresa EuroHelp

• Es una implementación de los principios de Secure by Design o Secure by Default– Es un complemento a la seguridad tradicional

• Limita el radio de acción de los usuarios de las aplicaciones web a un uso lícito

HDIV

• La implementación actual de HDIV es para entornos Java– Es posible aplicar la misma idea a otras plataformas

• Extiende gran parte de los frameworks Java web más utilizados:– Struts 1– Struts 2– Spring MVC– JSF 1 & JSF 2– JSTL

HDIV

• HDIV no altera el modelo de programación de los frameworks extendidos

• Se aplica de forma declarativa (vía configuración) y no es necesario modificar el código fuente

HDIV

• Integridad de los datos no editables (urls, parámetros,…)– Soluciona

• A1 (SQL Injection) • A2 (XSS)• A4 (Indirect Object Reference)• A7 (Failure to Restrict URL Access)• A10 (Unvalidated Redirects and Forwards)

• Validación genérica de editables (textarea, textbox)– Reduce el riesgo

• A1 (SQL Injection)• A2 (XSS)

HDIV - Funcionalidades

• Token aleatorios en urls y formularios– Soluciona

• A5 (Cross-Site Request Forgery)

• Confidencialidad– Reduce el riesgo

• A2 (SQL Injection)

• Logs de los ataques (incluyendo la identidad del usuario) y actividad anómala detectada– Realiza función de IDS (Intrusion Detection System)

HDIV - Funcionalidades

HDIV - Arquitectura

@RequestMapping(value = "/usuarios", method =

RequestMethod.GET, produces ="application/json")

public @ResponseBody

List<Usuarios> getUsuarios() {

List <Usuarios> usuarios = usuarioFacade.getUsuarios();

hdivComposer.addList(usuarios,”parametro”,”propiedad”);

return usuarios;

}

HDIV – Arquitectura JSON

• Depende del modo de ejecución utilizado– Memoria (por defecto)– Hash– Cifrado

• Haciendo uso del modo memoria (opción recomendada)– Tiempo de respuesta: 1-3 ms por request– Memoria: + 4-8%

• Depende mucho del tamaño de cache definido

– CPU: + 1-2%

HDIV – Rendimiento y consumos

• Configuración óptima:

– Utilizar el modo de funcionamiento de memoria

– Desactivar la validación de las URLs sin parámetros (delegar esta responsabilidad a Spring Security)

• Mejora mucho los tiempos de respuesta y los consumos dado que no creamos un estado de HDIV para estos links

HDIV – Rendimiento y consumos

• Administración pública• Banca• Logística & Transportes • Telecomunicaciones• Automoción• …

HDIV - Usuarios de HDIV

• Desde la versión 3.1 de Spring MVC se ha incorporado la integración oficial con HDIV– https://jira.springsource.org/browse/SPR-7943

• Implementado mediante un nuevo interface de Spring MVC: RequestDataValueProcessor

Integración HDIV & Spring MVC

https://jira.springsource.org/browse/SPR-7943

• Gracias a esta nueva integración se evita la necesidad de un tld diferente

• Se hace uso de los tags de Spring MVC que hacen uso del nuevo interface RequestDataValueProcessor


• Instalación de HDIV desde la versión Spring MVC 3.1:– Añadir las librerías de HDIV – web.xml

• Añadir el filtro de HDIV• Añadir el listener de HDIV

– hdiv-config.xml (configuración basada en Spring)• Haciendo uso del custom schema de HDIV


• HDIV custom schema – configuración mínima

<hdiv:config errorPage="/error.jsp">

<hdiv:startPages>/</hdiv:startPages>

</hdiv:config>


• HDIV custom schema – Validación editables

<hdiv:editableValidations>

<hdiv:validationRule url=".*“/>

</hdiv:editableValidations>


Ejemplo (hdiv-spring-mvc-showcase)

• Versión actual (2.1.1) :– Mejora del soporte AJAX : actualización parcial de un formulario

– Modo debug: activación de HDIV sin parar las peticiones, únicamente generando logs • Interesante para implantaciones en aplicaciones previamente desarrolladas

• Versión 2.1.2 :– Almacenamiento de estados de HDIV en ServletContext

• Con el objeto de no afectar a la replicación de sesión

Futuras versiones de HDIV

• Versión 2.2 (Junio 2012):– Soporte Grails: actualmente en fase de análisis– En principio basado en el mismo interface que en Spring MVC: RequestValueDataProcessor– Primeras pruebas accesibles en

• https://github.com/hdiv/grails-core

• Versión 2.3 (Noviembre 2012):– Integración oficial con Struts 2:https://issues.apache.org/jira/browse/WW-3718

Futuras versiones de HDIV

https://github.com/hdiv/grails-core

https://issues.apache.org/jira/browse/WW-3718

seguridad web mediante spring mvc y hdiv

Technology