1. Curso: 5007427 (28585) Diseno de aplicaciones
seguras (Bloque Servicios Web y seguridad
informatica)
Fernando Tricas Garc´
ıa
Departamento de Inform´tica e Ingenier´ de Sistemas
a ıa
Universidad de Zaragoza
http://www.cps.unizar.es/~ftricas/
ftricas@unizar.es
Departamento de Inform´tica e Ingenier´ de Sistemas (Univ.
a ıa
Zaragoza) - Curso: Desarrollo de aplicaciones seguras
1
2. Introducci´n
o
Fernando Tricas Garc´
ıa
Departamento de Inform´tica e Ingenier´ de Sistemas
a ıa
Universidad de Zaragoza
http://www.cps.unizar.es/~ftricas/
ftricas@unizar.es
Departamento de Inform´tica e Ingenier´ de Sistemas (Univ.
a ıa
Zaragoza) - Curso: Desarrollo de aplicaciones seguras
3. Un ´
ındice
Introducci´n
o
Gesti´n de riesgos
o
Selecci´n de tecnolog´
o ıas
C´digo abierto o cerrado
o
Principios
Auditor´ de programas
ıa
4. Un ´
ındice (cont.)
Desbordamiento de memoria
Control de acceso
Condiciones de carrera
Aleatoriedad y determinismo
Aplicaci´n de la criptograf´
o ıa
5. Un ´
ındice (cont.)
Gesti´n de la confianza y validaci´n de entradas
o o
Autentificaci´n con claves
o
Seguridad en bases de datos
Seguridad en el cliente
En la web
6. Introducci´n. Antes de empezar.
o
Se invierte mucho tiempo, dinero y esfuerzo en seguridad a
nivel de red por la mala calidad de los programas.
Algunas veces los cortafuegos, los sistemas de detecci´n de
o
intrusos (IDS) ayudan.
Los programas malos son mucho m´s abundantes de lo que
a
creemos.
La forma de desarrollar los programas es responsable en gran
medida del problema.
7. Cifras
El 30 % de los proyectos en entornos empresariales se cancelan
sin haber sido finalizados.
De los que se terminan, el 30 % cuesta al final entre un 150 %
y un 200 % del presupuesto original.
8. Cifras
Menos del 10 % de proyectos en empresas grandes terminan a
tiempo, y cumpliendo el presupuesto.
Las tasas de defectos en productos comerciales se estiman
entre 10 y 17 por cada 1000 l´ıneas de c´digo.
o
Otras estimaciones: entre 5 y 50 fallos.
9. M´s cifras
a
Diciembre de 1990: Miller, Fredrickson. ‘An empirical study of
the reliability of Unix Utilities’ (Communications of the ACM,
Vol 33, issue 12, pp.32-44).
Entre el 25 y el 33 % de las utilidades en Unix pod´
ıan
interrumpirse o colgarse proporcion´ndoles entradas
a
inesperadas.
1995: Miller otra vez, ejecutando Fuzz en nueve plataformas
tipo Unix diferentes:
Fallos entre un 15 y un 43 %
Muchos fallos ya avisados en el 90 segu´ all´
ıan ı
La menor tasa de fallos: utilidades de la FSF (7 %) y a las
incluidas junto con Linux (9 %) (¿Uh?)
No consiguieron hacer fallar ning´n servidor de red. Tampoco
u
el servidor X Window. Muchos clientes de X, si
10. Cifras
2000: Miller y Forrester. Fuzz con Windows NT.
45 % de los programas se colgaron o se interrumpieron
Enviar mensajes aleatorios Win32 a las aplicaciones hac´ fallar
ıa
al 100 %
Miller, Cooksey y Moore. Fuzz y Mac OS X.
7 % de las aplicaciones de l´
ınea de ´rdenes.
o
De las 30 basadas en GUI s´lo 8 no se colgaron o se pararon.
o
11. Cifras
2004-2005. Honeypot, con varios sistemas (Windows, Mac,
Linux)
Windows XP. SP 1.
Fue atacado 4857 veces
Infectado en 18 minutos (Blaster y Sasser)
En una hora era un ‘bot’ controlado remotamente, y
comenz´ a realizar sus propios ataques
o
Feb-Marzo 2005: menos del 24 % de los Windows XP
observados en un estudio de AssetMetrix Research Labs
ten´ SP2. Menos del 7 % del total lo ten´ 251 empresas
ıan ıan.
norteamericanas (seis meses desp´s de su lanzamiento).
e
http://www.stillsecure.com/docs/StillSecure_
DenverPost_Honeypot.pdf
12. Estudio OpenSSH
Julio 2002 se descubri´ un fallo de desbordamiento de
o
memoria remoto
Dos semanas despu´s de la publicaci´n del anuncio del fallo,
e o
mas de 2/3 de los servidores observados segu´ siendo
ıan
vulnerables.
Septiembre 2002. Un gusano explotaba el fallo (Slapper).
El 60 % de servidores era todav´ vulnerable.
ıa
Security holes. . . Who cares?
http:
//www.cgisecurity.com/lib/reports/slapper-report.pdf
13. Introducci´n. Antes de empezar.
o
Los programas no tienen garant´ (¿todav´
ıa ıa?).
La seguridad es un problema de gesti´n de riesgos.
o
Pensemos en la seguridad durante el dise˜o, despu´s ya es
n e
tarde.
14. Puede haber castigo
Cada vez se habla m´s de la responsabilidad de las empresas que
a
desarrollan programas:
1999. Ambrosia Software (Rochester, N.Y.) anunci´ que si alguno
o
de sus productos requer´ la reparaci´n de errores, el responsable
ıan o
de marketing comer´ insectos en alguna feria.
ıa
http://www.ambrosiasw.com/PRs/eatbugs_PR.html
Parece que finalmente tuvieron que comerlos . . .
http://www.ambrosiasw.com/news/old_newsletter.php?id=34019&page=3
31 de diciembre de 1999. Las autoridades chinas obligaron a los
ejecutivos de la compa˜´ a´rea nacional a volar durante esa noche
nıa e
en los vuelos programados.
15. ¿Por qu´ es importante?
e
Cada vez hay m´s computadores y en m´s sitios.
a a
La gente ni sabe ni quiere saber de estos temas.
A´n peor, saben lo que dicen las noticias.
u
16. Son los programas
Dependemos (mucho) de los computadores (y sus programas).
El principal problema es que la mayor´ de los desarrolladores
ıa
ni siquiera saben que hay un problema.
Ni los cortafuegos ni la criptograf´ resolver´n los problemas
ıa a
(el 85 % de los avisos del CERT no se pueden prevenir con
criptograf´
ıa).
17. Son los programas (est´pido)
u
Est´ bien proteger la transmisi´n pero los atacantes prefieren
a o
los extremos
Las aplicaciones que interact´an con Internet son las m´s
u a
delicadas, pero no es imprescindible que tengan contacto con
la red para ser peligrosas.
18. Son los programas
Empezar pronto
Conocer las amenazas
Dise˜ar pensando en la seguridad
n
Ce˜ir el dise˜o a los an´lisis de riesgos y las pruebas
n n a
19. Gesti´n del riesgo
o
La seguridad es un compromiso entre muchos factores:
Tiempo hasta que se puede vender
Coste
Flexibilidad
Reutilizabilidad
Relaciones entre los anteriores
Hay que establecer las prioridades, a veces la seguridad no es
la principal necesidad.
20. Seguro o Inseguro
Mucha gente piensa en la seguridad como algo que se tiene o
no se tiene.
Es muy dif´ probar que un sistema de complejidad mediana
ıcil
es seguro.
Frecuentemente, ni si quiera vale la pena.
21. Seguro o Inseguro
Es mas realista pensar en t´rminos de gesti´n de riesgo:
e o
¿Cu´nto riesgo?
a
¿Cu´nto cuesta reducirlo?
a
Recordar: los ’malos’ no crean los defectos, simplemente los
utilizan.
22. Fallos en los programas
A˜o 2000: aproximadamente 20 nuevas vulnerabilidades cada
n
semana
Muchas en programas con c´digo, pero otras tantas en las
o
que no se conoce
Unix y Windows tambi´n est´n equilibrados
e a
Siguen apareciendo problemas en programas probados y
usados.
23. Algunas cifras
NIST: National Institute of Standards and Technology
NVD: National Vulnerabilities Database
http://nvd.nist.gov/statistics.cfm?results=1
24. M´s cifras
a
CERT: Organizaci´n del Software Engineering Institute (SEI).
o
http://www.cert.org/stats/
18 de febrero de 2008
25. Y m´s . . . la web
a
Figure 1. (a) Breakdown of disclosed vulnerabilities by software
type in May 2006, and (b) current vulnerability types disclosed in
Web-based applications. (Source: SecurityFocus.com)
http://www.computer.org/portal/site/security/menuitem.6f7b2414551cb84651286b108bcd45f3/index.
jsp?&pName=security_level1_article&TheCat=1015&path=security/2006/v4n4&file=gei.xml
Resumida: http://tinyurl.com/3862ba
26. M´s cifras
a
http://www.cisco.com/web/about/security/cspo/docs/Cisco2007Annual_Security_Report.pdf
28. ¿D´nde conocerlos?
o
Bugtraq (http://www.securityfocus.com/)
CERT Advisories http://www.cert.org/
http://www.rediris.es/cert/
Equipo de Seguridad para la Coordinaci´n de Emergencias en
o
Redes Telem´ticas (http://escert.upc.edu/)
a
ICAT Metabase (http://nvd.nist.gov/)
OSVDB, Open Source Vulnerability Database
(http://osvdb.org/)
INTECO, http://www.inteco.es/
RISKS Digest (http://catless.ncl.ac.uk/Risks/)
Help Net Security http://www.net-security.org/
29. ¿Y las tecnolog´
ıas?
La complejidad introduce riesgos.
A˜adir funcionalidades (no presente en el original)
n
Invisibilidad de ciertos problemas
Dificultad para analizar, comprender, asegurar.
31. La complejidad
Windows NT → 35 millones de l´
ıneas de c´digo.
o
Windows XP → 40 millones de l´
ıneas de c´digo.
o
Windows Vista → 50 millones de l´
ıneas de c´digo.
o
Linux 2.2 → 1.78 millones,
Solaris 7 → 400000.
Debian GNU/Linux 2.2 55 millones
Red Hat 6.2 17 millones.
Mac OS X Darwin 790000 (el kernel)
32. La complejidad
Windows NT → 35 millones de l´
ıneas de c´digo.
o
Windows XP → 40 millones de l´
ıneas de c´digo.
o
Windows Vista → 50 millones de l´
ıneas de c´digo.
o
Linux 2.2 → 1.78 millones,
Solaris 7 → 400000.
Debian GNU/Linux 2.2 55 millones
Red Hat 6.2 17 millones.
Mac OS X Darwin 790000 (el kernel)
Seguimos programando en C! (en el mejor de los casos C++)
Esto va cambiando . . . Java, .Net, . . .
Luego hay que instalar, configurar, usar
33. Complejidad
Linux + Apache Windows + IIS
http://blogs.zdnet.com/threatchaos/?p=311
Why Windows is less secure than Linux
Abril 2006
35. En red
Cada vez m´s redes
a
Los ataques pueden venir de m´s sitios
a
Ataques automatizados/autom´ticos
a
M´s sitios para atacar, m´s ataques, mas riesgo
a a
36. Extensibilidad
C´digo m´vil
o o
‘Enchufables’ en el navegador (‘plugins’)
M´dulos, ‘drivers’
o
Muchas aplicaciones tienen lenguajes que permiten extenderlas.
Econ´micamente conveniente (reutilizaci´n) pero ...
o o
37. El entorno
A˜adir seguridad a un sistema ya existente es casi imposible
n
Es mejor dise˜ar con la seguridad en mente
n
Otra fuente de problemas es ‘ambiental’: un sistema
completamente seguro en el entorno para el que fue dise˜ado,
n
deja de serlo en otros.
38. Pero ... ¿Qu´ es seguridad?
e
Primero, es importante establecer una pol´
ıtica que describa la
forma de acceder a los recursos.
Si no queremos accesos sin autentificar y alguien accede ...
Si alguien hace un ataque de denegaci´n de servicio ...
o
39. Pero ... ¿Qu´ es seguridad?
e
A veces es evidente lo que est´ mal, y no hay que hilar tan fino,
a
pero ...
¿Un escaneo de puertos es un ataque o no?
¿Hay que responder? ¿C´mo?
o
40. ¿Tiene que ver con la confiabilidad?
‘Reliability’, confiabilidad, ¿no deber´ proporcionar seguridad?
ıa
La confiabilidad se mide seg´n la robustez de la aplicaci´n
u o
respecto a los fallos.
La definici´n de fallo es an´loga a la definici´n de pol´
o a o ıtica de
seguridad.
41. ¿Tiene que ver con la confiabilidad?
Entonces, la seguridad ser´ una parte de la confiabilidad: si se
ıa
puede violar alguna parte de la pol´
ıtica de seguridad, hay un
fallo.
Sin embargo...
Los problemas de robustez no siempre son problemas de
seguridad
Lo son m´s frecuentemente de lo que se piensa, de todos
a
modos.
Si dise˜amos pensando en su robustez, seguramente tambi´n
n e
mejoraremos su seguridad
42. Malas pr´cticas
a
Se hacen los programas, se espera a que aparezcan problemas, y se
resuelven (si se puede).
S´lo se resuelven problemas conocidos por los desarrolladores
o
No se trabaja ni con el tiempo, ni con la tranquilidad que hace
falta.
Los parches habitualmente atacan al s´
ıntoma, no al problema
Los parches hay que aplicarlos ...
43. Las metas
La seguridad no es una caracter´
ıstica est´tica
a
100 % seguro no existe (o es mentira)
Mejor ...
¿Qu´ queremos proteger?
e
¿Contra qui´n?
e
¿Contra qu´?
e
44. Prevenci´n
o
Normalmente, se presta atenci´n cuando ya es tarde
o
El tiempo en la red es distinto (velocidad)
Los ataques se propagan muy r´pido
a
Incluso se automatizan
45. Trazabilidad, auditabilidad
Los ataques ocurrir´n
a
Los contables lo saben (dinero)
Estas medidas ayudan a detectar, comprender y demostrar los
ataques
Es delicado
46. Vigilancia
Auditor´ en tiempo real
ıa
Se puede hacer a muchos niveles
b´squeda de ‘firmas’, patrones ...
u
... pero tambi´n aserciones, c´digo a prop´sito.
e o o
A menudo, con trampas sencillas se puede capturar a un
ladr´n, o al menos evitar que haga da˜o.
o n
47. Privacidad y Confidencialidad
(Privacidad ←→ Intimidad)
Privacidad y confidencialidad son t´rminos muy relacionados
e
Las empresas deben proteger los datos de sus clientes, incluso
de los anunciantes
Los gobiernos tambi´n
e
48. Privacidad y Confidencialidad
No siempre comprendemos bien las consecuencias de nuestras
acciones
Los programas deber´ asegurar la privacidad ...
ıan
... pero los programas s´lo sirven para hacer el trabajo
o
Si es posible ... no almacenar secretos
49. Seguridad multinivel
Hay secretos ‘m´s secretos’ que otros
a
Ni las empresas ni los gobiernos quieren que se sepan algunos
datos
Adem´s, no todo el mundo tiene que saber lo mismo ...
a
...
Es complejo
50. Anonimato
Arma de doble filo
A veces, hay razones sociales para favorecerlo (SIDA)
Pero tambi´n las hay para controlarla (racismo, terrorismo,..)
e
Junto con la privacidad, es de los temas m´s importantes que
a
hay que decidir.
Global Identifier de Microsoft sirve para saber qu´ copia de
e
MS Office origin´ un documento
o
WGA (Windows Genuine Advantage)
las ’supercookies’ de Google y Microsoft . . .
51. Anonimato
Carnivore, Echelon, ... ¿qui´n nos garantiza que se usan
e
‘adecuadamente’ ?
¿Y las galletitas? ¿Realmente son necesarias? ¿Y si nos las
roban?
Hay empresas que las ‘coleccionan’
¿Y si tenemos que hacerlo nosotros? ¿Qu´ pasa si algo va
e
mal? ¿La comodidad es compatible con la privacidad?
52. Autentificaci´n
o
Saber qui´n para saber qu´ puede hacer
e e
Hasta no hace mucho bastaba con la presencia f´
ısica
Internet!!!
¿mibancofavorito.com realmente es MiBancoFavorito?
¿Realmente es un banco?
SSL da tranquilidad pero ... ¿qu´ garantiza?
e
53. Autentificaci´n
o
Nadie mira los datos
De muchas formas: mibancofavorito.com →
mibacofavorito.com
Si vale dinero, hay que tener cuidado.
Algunos esquemas suponen anonimato, otros auditor´
ıa.
Algunos esquemas est´n orientados a sesiones, otros a
a
transacciones.
54. Integridad
Seguir teniendo ‘lo mismo’
Precios, cotizaciones, ... ¿y si nos los cambian?
La informaci´n digital es muy f´cil de simular
o a
55. Conociendo al enemigo
Es bueno conocer los errores frecuentes, sobre todo porque no se
suele hablar mucho del tema.
Errores de programaci´n (buffers, condiciones de carrera,
o
n´meros aleatorios)
u
Pero tambi´n ...
e
La construcci´n es importante y tambi´n como se usa
o e
Arquitectura cliente/servidor
Ingenier´ social
ıa
Entradas maliciosas
56. En resumen
Ver lo que va por la red, ponerse en medio
Modificar lo que va por la red
Simular lo que deber´ ir por la red
ıa
Reemplazar el flujo de datos
Grabar y repetir
57. Las metas de un proyecto
Funcionalidad (resolver el problema)
Ergonom´ -usabilidad- (a veces la seguridad interfiere con la
ıa
comodidad/conveniencia)
Eficiencia (a nadie le gusta esperar)
El mercado (habitualmente en contra de la simplicidad, y de
la gesti´n de riesgos)
o
Simplicidad (buena para los proyectos, buena para la
seguridad)
58. Bibliograf´
ıa
John Viega and Gary McGraw. Building Secure Software.
Addison-Wesley
Michael Howard, David C. LeBlanc. Writing Secure Code.
Microsoft Press. Second Edition.
Innocent Code. A security wake-up call for web programmers.
Sverre H. Huseby. Wiley.
59. M´s libros
a
Software Security. Gary McGraw. Addison-Wesley Software
Security Series.
OWASP Guide to Building Secure Web Applications (va por
la versi´n 3.0)
o
http:
//www.owasp.org/index.php/OWASP_Guide_Project
60. M´s bibliograf´
a ıa
Mark G. Graff, Kenneth R. Van Wyk. Secure Coding:
Principles and Practices. O’Reilly & Associates
John Viega, Matt Messier. Secure Programming Cookbook for
C and C++. O’Reilly & Associates.
Gary McGraw, Edward W. Felten. Securing Java: Getting
Down to Business with Mobile Code
61. Bibliograf´
ıa
El otro lado.
Greg Hoglund, Gary McGraw. Exploiting Software. How to
break code. Addison Wesley.
Cyrus Peikari, Anton Chuvakin. Security Warrior. O’Reilly.
Andrews & Whittaker. How to Break Web Software. Addison
Wesley.
Tom Gallagher; Bryan Jeffries; Lawrence Landauer. Hunting
Security Bugs. Microsoft Press.
62. M´s bibliograf´
a ıa
En la red:
Secure Programming for Linux and Unix HOWTO
http://www.dwheeler.com/secure-programs/
Security Developer Center Microsoft
http://msdn.microsoft.com/security
Improving Web Application Security: Threats and
Countermeasures
http://www.microsoft.com/downloads/details.aspx?familyid=
E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en Hay mas...
63. Algunas listas de correo
Secure Coding http://www.securecoding.org/list/
WEB APPLICATION SECURITY
http://www.securityfocus.com/archive/107
SECPROG http://www.securityfocus.com/archive/98
Web Security http://webappsec.org/lists/
Listas de OWASP
http://lists.owasp.org/mailman/listinfo
HACK http://mailman.argo.es/listinfo/hacking
