Your SlideShare is downloading. ×
CodeCamp 2010 | Diez formas de escribir código (in)seguro
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

CodeCamp 2010 | Diez formas de escribir código (in)seguro

691
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
691
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1.
  • 2. Las presentaciones
    El tiempo total de las presentaciones es de 1 hora y 15 minutos. Sugerimos presentaciones de 60 minutos, dejando 5-10 minutos finales para preguntas y discusión
    La puntualidadesmuyimportantepara el orden del evento. Solicitamospuntualidad en el comienzo y cierre de laspresentaciones.
    En www.codecamp.com.ar subiremos las PPT del evento. Le solicitamos nos envíe esta presentación una vez completa a: v-anasau@microsoft.com
  • 3. b1010 formas de escribir código (in)seguro
    Lic. CristianBorghello, CISSP - MVP
    Director
    Segu-Info
    info@segu-info.com.ar
  • 4. Licencia de uso:CreativeCommons 2.5
    Ud. puede:
    • Copiar, distribuir, exhibir, y ejecutar la obra
    • 5. Hacer obras derivadas
    Bajo las siguientes condiciones:
    Atribución. Debe atribuir la obra en la forma especificada por el autor
    No Comercial. No puede usar esta obra con fines comerciales.
    Compartir Obras Derivadas Igual. Si altera, transforma, o crea sobre esta obra, sólo podrá distribuir la obra derivada resultante bajo una licencia idéntica a ésta.
    http://creativecommons.org/licenses/by-nc-sa/2.5/ar/
  • 6. Temario
    Riesgo
    Redes externas vs internas
    Bugs “simples”
    Validación de archivos
    XSS y SQL Injection
    Cookies
    Control en producción
    Conclusiones
  • 7. Palabras de dudosa credibilidad...
    ¡El Cray es tanrápido que puede ejecutar un bucle infinito en menosde 2 segundos!
  • 8. Cuando hablamos de Seguridad, en realidad ¿de qué hablamos?
    R I E S G O
  • 9. Diseño
    Falla o Vuln.
    Costo< Ganancia
    Explotable
    SI
    SI
    SI
    Existe amenaza
    NO
    NO
    NO
    “Sin riesgo”
    SI
    Riesgo inaceptable
    Riesgo (simplificado)
  • 10. Superficie de ataque
    Remoto
    Restringido
    Local
    Administradores
    UsuariosAutenticados
    Anónimos
  • 11. Daño: cuan grande será el daño
    Reproducción: cuan fácil es reproducir el ataque
    Explotación: cuan fácil es lanzar el ataque
    Afectados: cuantos usuarios serán afectados
    Descubrimiento: cuan fácil es encontrar la vulnerabilidad
    Modelo de amenazas
    http://www.microsoft.com/sdl
  • 12. Redes Internas vs Externas
    Si sólo personal interno conoce el acceso, entonces nadie podrá acceder desde el exterior
    Se ingresa a Intranet, sitios de backend o de administración a través de URL públicas
    Problemas asociados:
    El enemigo interno y el abuso de conocimiento
    El descubrimiento “fortuito” de personal externo
  • 13. Redes Internas vs Externas
  • 14. Bugs ”simples”
    Encontramos un pequeño bug que podríamos resolver en un momento pero nos llevaría más tiempo implementarlo en producción que arreglarlo,así que…
    lo dejamos así, total funciona
  • 15. Bugs ”simples”
    Resolvemos el bug y realizamos una vaga descripción de la resolución porque resulta demasiado complicado explicarlo
    No detallamos los pasos para reproducir el error porque son triviales o muy complicados
  • 16. Bugs “solucionado”
  • 17. Validación de archivos
    Cargo los archivos en forma dinámica en tiempo de ejecución. ¡Qué buena idea!
    Falta de validación de archivos incluidos o subidos permiten la ejecución de los mismos en el servidor local o remoto
    Se debevalidar y rechazarcualquiertipo de archivo MIME no permitido
  • 18. RFI y LFI
  • 19. Inyección de archivos
  • 20. “Validación” al subir archivos
  • 21. Evitar RFI y LFI
    UrlScanpordefectobloquea: exe, bat, cmd, com, htw, ida, idq, htr, idc, printer, ini, pol, dat, etc.
    En PHP se puedeutilizarMod_Security y/o Sushosin
    Todaslasvalidaciones se debenrealizar en ambos lados:cliente y servidor
  • 22. XSS – Cross-Site Script
    Ejecución de código no validadoen el cliente a través de la inyección del mismopordiversosmétodos
  • 23. Las galletitas
  • 24. Las galletitas
    Programar, comer y beber
    ¡That’slife!
    Las cookiespueden ser obtenidasdesde el cliente a través de scriptssencillos y a través de ataques XSS
    Si el browsersoportaHTTP-Only, se puedebloquear la lectura y escritura de lascookies en el cliente
  • 25. XSS y Phishing
  • 26. Control de Cookies
    Controlar la información en lascookies
    Implementar HTTP-Only
    Sin HTTP-Only
    Con HTTP-Only
  • 27. Navegadores con HTTP-Only
    http://www.owasp.org/
  • 28. Cross DomainRequest
    Los archivos no alcanzaron así que cargamos img, frames, forms, CSS, JS, etc. desde múltiples dominios
    Cross-site HTTP requests: solicitudes HTTP que se realizandesdediferentesdominios
    La W3C ha propuesto un nuevo estándar para controlar el Cross DomainRequest
    Todos los navegadores lo soportan excepto Opera (por ahora)
  • 29. X-FrameOrigin
    Frame
  • 30. RIA: Rich Internet Applications
    Las aplicaciones no se validan porque no tienen vulnerabilidades, o las mismas no pueden explotarse
  • 31. Dos políticas a implementar
    Mismoorigen:si dos sitioscomparten el mismo [protocolo:puerto] entoncestienen el mismoorigenPuede ser utilizadopararestringir la ejecuciónsólodesdedominiosválidos
    SandBox: la ejecución se realiza en un entornocontrolado y no se accede a recursosque no hansidoespecíficamenteautorizadosLos procesos son considerados de “bajaintegridad” y no puedenacceder a procesos de integridad mayor (MIC y UIPI)
  • 32. URL Redirect
    Para controlar los “abandonos”de mi sitio, redirecciono a sitios externos mediante un script
  • 33. Bad URL Redirect
  • 34. Control de URL
    Registrar y administrarlas URL del sitio
    ¿Yadijequelasvalidaciones se debenhacer de ambos lados?
  • 35. Control de URL y Salt
    Ponele SALT a tu vida
    Intentarutilizar HMAC paragenerardatoscodificados y checksum en información sensible
  • 36. SQL Injection
  • 37. SQL Injection
    Creoqueya lo dije: lasvalidaciones se debenhacer de ambos lados
  • 38. Testing en producción
    El testing es rápido así que lo realizamos en el servidor productivo
    El desarrollo y el testingdebenrealizarse en servidores != producción
  • 39. Conclusiones y pasos a aplicar
    Asumir que cualquier entrada es maliciosa
    Validar todas las entradas
    Validar todas las salidas
    Codificar cada entrada y salida
    Utilizar aplicaciones para validación
    Validar permisos de la aplicación y sus usuarios
  • 40. Finalmente: mi preferida
    Sin palabras… 
  • 41. Referencias
    Microsoft Security Development Lifecycle v5http://bit.ly/9piMph
    Threat Analysis and Modeling (TAM) v3http://bit.ly/cTP0Uq
    FoundStone Free Toolshttp://bit.ly/aep4qs
    WebGoathttp://bit.ly/btPp9n
    Damn Vulnerable Web App (DVWA) http://bit.ly/9NeO8F
    WritingSecureCodehttp://amzn.to/aEytaE
    Sanitize HTMLhttp://bit.ly/b9fn0R
    URLScanhttp://bit.ly/aX8V4X
    Practical Windows Sandboxing (3 partes)http://bit.ly/adWAIW - http://bit.ly/cBgWW9 - http://bit.ly/9lSw97
  • 42. Preguntas
    Lic. CristianBorghello, CISSP - MVP
    info@segu-info.com.ar
  • 43. Participá del DEMOFEST
    Los mejores proyectos de las células Microsoft, los grupos de investigación de estudiantes, son seleccionados para participar en el espacio del DEMOFEST.
    ¡Conócelos!
  • 44. Necesitamos tu Feedback!
    Completá los FORM de avaluación que estarán en nuestra WEB:
    www.codecamp.com.ar
    Necesitamos de tu feedback para mejorar.
  • 45. © 2008 Microsoft Corporation. Todos los derechosreservados. Microsoft, Windows, Windows Vista y otrosnombres de producto son y pueden ser marcasregistradas y registros en EstadosUnidos y en otrospaíses.
    La informacióncontenida en el presenteessólopara fines informativos y representa la visión actual de Microsoft Corporation a la fecha de estapresentación. Debido a que Microsoft debe responder a lascambiantescondiciones del mercado, no se debeinterpretarcomo un compromisopor parte de Microsoft, y Microsoft no puedegarantizar la precisión de ningunainformaciónprovistadespués de la fecha de estapresentación. MICROSOFT NO OFRECE GARANTÍA ALGUNA, EXPRESA, IMPLÍCITA O DE LEY, RESPECTO A LA INFORMACIÓN EN ESTA PRESENTACIÓN.