codecamp 2010 | diez formas de escribir código (in)seguro

1

3

b1010 formas de escribir código (in)seguro

Lic. Cristian Borghello, CISSP - MVPDirectorSegu-Infoinfo@segu-info.com.ar

4

Ud. puede: Copiar, distribuir, exhibir, y ejecutar la obra

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/

Licencia de uso:Creative Commons 2.5

5

TemarioRiesgoRedes externas vs internasBugs “simples”Validación de archivosXSS y SQL InjectionCookiesControl en producciónConclusiones

7

Cuando hablamos de Seguridad, en realidad

¿de qué hablamos?

R I E S G O

9

Superficie de ataque

Administradores UsuariosAutenticados

Anónimos

Remoto

Restringido

Local

11

Redes Internas vs Externas

Se ingresa a Intranet, sitios de backend o de administración a través de URL públicasProblemas asociados:

El enemigo interno y el abuso de conocimientoEl descubrimiento “fortuito” de personal externo

Si sólo personal interno conoce el acceso, entonces nadie podrá acceder desde el exterior

12

Redes Internas vs Externas

13

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

14

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

15

Bugs “solucionado”

16

Validación de archivos

Falta de validación de archivos incluidos o subidos permiten la ejecución de los mismos en el servidor local o remotoSe debe validar y rechazar cualquier tipo de archivo MIME no permitido

Cargo los archivos en forma dinámica en tiempo de ejecución. ¡Qué buena idea!

17

RFI y LFI

18

Inyección de archivos

19

“Validación” al subir archivos

20

Evitar RFI y LFIUrlScan por defecto bloquea: exe, bat, cmd, com, htw, ida, idq, htr, idc, printer, ini, pol, dat, etc.En PHP se puede utilizar Mod_Security y/o SushosinTodas las validaciones se deben realizar en ambos lados: cliente y servidor

21

XSS – Cross-Site ScriptEjecución de código no validado en el cliente a través de la inyección del mismo por diversos métodos

22

Las galletitas

23

Las galletitas

Las cookies pueden ser obtenidas desde el cliente a través de scripts sencillos y a través de ataques XSSSi el browser soporta HTTP-Only, se puede bloquear la lectura y escritura de las cookies en el cliente

Programar, comer y beber¡That’s life!

24

XSS y Phishing

25

Control de Cookies

Sin HTTP-Only

Con HTTP-Only

Controlar la información en las cookiesImplementar HTTP-Only

26

Navegadores con HTTP-Only

http://www.owasp.org/

27

Cross Domain RequestLos archivos no alcanzaron así que cargamos img, frames, forms, CSS, JS, etc. desde múltiples dominios

Cross-site HTTP requests: solicitudes HTTP que se realizan desde diferentes dominiosLa W3C ha propuesto un nuevo estándar para controlar el Cross Domain Request

Todos los navegadores lo soportan excepto Opera (por ahora)

28

X-Frame Origin

Frame

29

RIA: Rich Internet Applications

Las aplicaciones no se validan porque no tienen vulnerabilidades, o las mismas no pueden explotarse

30

Dos políticas a implementar

Mismo origen: si dos sitios comparten el mismo [protocolo:puerto] entonces tienen el mismo origenPuede ser utilizado para restringir la ejecución sólo desde dominios válidosSandBox: la ejecución se realiza en un entorno controlado y no se accede a recursos que no han sido específicamente autorizadosLos procesos son considerados de “baja integridad” y no pueden acceder a procesos de integridad mayor (MIC y UIPI)

31

URL RedirectPara controlar los “abandonos”de mi sitio, redirecciono a sitios externos mediante un script

32

Bad URL Redirect

33

Control de URLRegistrar y administrar las URL del sitio

¿Ya dije que las validaciones se deben hacer de ambos lados?

34

Control de URL y Salt

Intentar utilizar HMAC para generar datos codificados y checksum en información sensible

Ponele SALT a tu vida

35

SQL Injection

36

SQL Injection

Creo que ya lo dije: las validaciones se deben hacer de ambos lados

37

Testing en producciónEl testing es rápido así que lo realizamos en el servidor productivo

El desarrollo y el testing debenrealizarse en servidores != producción

38

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

Conclusiones y pasos a aplicar

39

Finalmente: mi preferidaSin palabras…

40

ReferenciasMicrosoft Security Development Lifecycle v5http://bit.ly/9piMph Threat Analysis and Modeling (TAM) v3http://bit.ly/cTP0Uq FoundStone Free Toolshttp://bit.ly/aep4qsWebGoathttp://bit.ly/btPp9n Damn Vulnerable Web App (DVWA) http://bit.ly/9NeO8F Writing Secure Codehttp://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

41

Preguntas

Lic. Cristian Borghello, CISSP - MVPinfo@segu-info.com.ar

42

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!

Participá del DEMOFEST

43

Necesitamos tu Feedback!

Completá los FORM de avaluación que estarán en nuestra WEB:www.codecamp.com.arNecesitamos de tu feedback para mejorar.

44

© 2008 Microsoft Corporation. Todos los derechos reservados. Microsoft, Windows, Windows Vista y otros nombres de producto son y pueden ser marcas registradas y registros en Estados

Unidos y en otros países.La información contenida en el presente es sólo para fines informativos y representa la visión actual de Microsoft Corporation a la fecha de esta presentación. Debido a que Microsoft debe

responder a las cambiantes condiciones del mercado, no se debe interpretar como un compromiso por parte de Microsoft, y Microsoft no puede garantizar la precisión de ninguna

información provista después de la fecha de esta presentación. MICROSOFT NO OFRECE GARANTÍA ALGUNA, EXPRESA, IMPLÍCITA O DE LEY, RESPECTO A LA INFORMACIÓN EN ESTA

PRESENTACIÓN.