csp level 2: defensa en profundidad para aplicaciones web
DESCRIPTION
XSS continúa siendo el vector de ataque más común, y no es un secreto que la mayoría de las aplicaciones web son susceptibles a algún tipo de injection, proveyendo una puerta de acceso para atacar a cada usuario de la aplicación. También no es un secreto que la mayoría de los desarrolladores Web presta poca, o ninguna, atención a este tema, y las herramientas disponibles en el mercado para analizar el código y detectar posibles vías de inyección están basadas en análisis heurístico, lo que implica que tienen una efectividad muy limitada. A finales del 2012, W3C aceptó una propuesta para estandarizar CSP 1.0, que describe un interruptor mecánico controlado desde un servidor a un cliente para definir las políticas a seguir por la aplicación web, y declarar un conjunto de restricciones de contenido. La falla principal de CSP 1.0 consiste en su falta de flexibilidad, como por ejemplo soportar scripts en línea, una práctica muy arraigada en los desarrolladores web, y mucho dicen es una funcionalidad esencial para cualquier aplicación web. Hoy por hoy, tenemos CSP Level 2 como parte de las nuevas normativas de W3C, ya incluso disponible en algunos de los navegadores, y este promete ser mucho más efectivo y flexible a la vez. En esta presentación vamos a cubrir detalles de CSP Level 2, y algunas de las prácticas recomendadas. A la vez, queremos proveer un espacio para demostrar la efectividad de esta tecnología a través de un ejercicio de hackeo.TRANSCRIPT
Caridy Patiño@caridy
github.com/caridy/csp
Content Security Policy (CSP)
Agenda !
- XSS - inyecciones más comunes - Técnicas de prevención (historia) - CSP Level 1 - CSP Level 2 - Demo - Concurso
XSS
Técnicas de prevención de inyecciones
Heurística
Code Review
Commit Hooks
Análisis de caja negra
Escaping Libraries
Template Engines
{{this.userValue}} vs
{{{this.configValue}}}
Handlebars Template Engine
{{this.userValue}} vs
{{dangerOfInjection this.configValue}}
Handlebars Template Engine
App Middleware
Browser middleware (traffic layer)
app layer
request modified request
Una capa de seguridad no es suficiente
CSP
- Protección contra XSS !
- Protección mecánica (no heurística) !
- Defensa en profundidad (redundancia)
¿Qué es CPS?
Interruptor Mecánico
“Content-Security-Policy” Header
Reglas- script-src: para los javascript. - connect-src: para los pedidos de XHR, WebSockets, etc. - font-src: para los web fonts. - frame-src: para los frames/iframes. - img-src: para imágenes. - media-src: para video y audio streams. - object-src: para flash y otros plugins. - style-src: para los stylesheets/css. - default-src: reglas por defecto.
“Content-Security-Policy” Header
vs
vs
Requiere compromiso(todos se rigen por las mismas reglas)
No hay distinción
Inline scripts no son permitidos
Inline scripts con “nonce” o “hash” son permitidos
Reporte de Violaciones CSP
Header
Beacon
Desafios de CSP
SSL
Crear y mantener el whitelist es difícil
Habilitar reglas por default de CSP no es suficiente
Inline scripts
Penalidades de Desempeño
embedding widgets
• twitter por ejemplo te deja activar directivas de CSP es sus widget a través de un meta tag:
• <meta name=“twitter:widgets:csp” content=“on">
• https://dev.twitter.com/web/overview/widgets-meta-elements
Browser Plugins / Addons
Report Only Mode
“Content-Security-Policy-Report-Only”
Herramientas
caspr.io + enforcer
DEMO
Gracias
@caridy