codecamp 2010 | diez formas de escribir código (in)seguro
TRANSCRIPT
1
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
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
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.