csp level 2: defensa en profundidad para aplicaciones web

Post on 25-Dec-2014

63 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

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

http://caniuse.com/#search=csp

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

npmjs.org/package/content-security-policy

caspr.io + enforcer

http://c0nrad.io/blog/csp.html

DEMO

Gracias

@caridy

top related