Seguridad web mediante Spring MVC y HDIV
-
Upload
hdivframework -
Category
Technology
-
view
1.471 -
download
7
Transcript of 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
Riesgos web (OWASP top ten)
• 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
Riesgos web (OWASP top ten)
• 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
Riesgos web (OWASP top ten)
• Inyection Flaws (A1) - Consecuencias
– Modificación de la BBDD
– Consulta de datos ajenos
– …
Riesgos web (OWASP top ten)
• 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)
Riesgos web (OWASP top ten)
• 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,…
Riesgos web (OWASP top ten)
• Cross site scripting o XSS (A2) - Ejemplo
Riesgos web (OWASP top ten)
• 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>
Riesgos web (OWASP top ten)
• 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>
Riesgos web (OWASP top ten)
• Cross site scripting o XSS (A2) - Ejemplo
Riesgos web (OWASP top ten)
• Cross site scripting o XSS (A2) – Consecuencias
• Robo de sesiones • Modificación de páginas• Es una de las bases para el
phising
Riesgos web (OWASP top ten)
• 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)
Riesgos web (OWASP top ten)
• 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
Riesgos web (OWASP top ten)
• 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
Riesgos web (OWASP top ten)
• 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>
Riesgos web (OWASP top ten)
• 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
Riesgos web (OWASP top ten)
• 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">
Riesgos web (OWASP top ten)
• Security Misconfiguration (A6)
• Insecure Cryptographic storage (A7)
• Failure to Restrict Url Access (A8)
• Insufficient Transport Layer Protection (A9)
• Unvalidated Redirects and Forwards (A10)
Riesgos web (OWASP top ten)
• 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)
Soluciones de seguridad tradicionales
• 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
Soluciones de seguridad tradicionales
• 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
Soluciones de seguridad tradicionales
• 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
• 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
Integración HDIV & Spring MVC
• 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
Integración HDIV & Spring MVC
• HDIV custom schema – configuración mínima
<hdiv:config errorPage="/error.jsp">
<hdiv:startPages>/</hdiv:startPages>
</hdiv:config>
Integración HDIV & Spring MVC
• HDIV custom schema – Validación editables
<hdiv:editableValidations>
<hdiv:validationRule url=".*“/>
</hdiv:editableValidations>
Integración HDIV & Spring MVC
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
Q&A