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.

1. Caridy Patiño
@caridy
github.com/caridy/csp

2. Content Security Policy
(CSP)

3. Agenda
!
- XSS - inyecciones más comunes
- Técnicas de prevención (historia)
- CSP Level 1
- CSP Level 2
- Demo
- Concurso

4. XSS

10. Técnicas de prevención
de inyecciones

11. Heurística

12. Code Review

13. Commit Hooks

14. Análisis de caja negra

15. Escaping Libraries

16. Template Engines

17. Handlebars Template Engine
{{this.userValue}}
vs
{{{this.configValue}}}

18. Handlebars Template Engine
{{this.userValue}}
vs
{{dangerOfInjection this.configValue}}

19. App Middleware
Browser
middleware
(traffic layer)
app
layer
request modified
request

20. Una capa de seguridad no es suficiente

22. CSP

23. ¿Qué es CPS?
- Protección contra XSS
!
- Protección mecánica (no heurística)
!
- Defensa en profundidad (redundancia)

24. Interruptor Mecánico

25. “Content-Security-Policy”
Header

27. 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.

28. “Content-Security-Policy”
Header

29. vs
vs

30. Requiere compromiso
(todos se rigen por las mismas reglas)

31. No hay distinción

32. Inline scripts no son permitidos

33. Inline scripts con “nonce” o “hash”
son permitidos

34. Reporte de Violaciones CSP

35. Header
Beacon

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

37. Desafios de CSP

38. SSL

39. Crear y mantener
el whitelist es difícil

40. Habilitar reglas por default
de CSP no es suficiente

41. Inline scripts

42. Penalidades de Desempeño

43. 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

44. Browser Plugins / Addons

45. Report Only Mode

46. “Content-Security-Policy-Report-Only”

47. Herramientas

48. npmjs.org/package/content-security-
policy

49. caspr.io + enforcer

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

51. DEMO

52. Gracias
@caridy