Desarrollo Web Avanzado

Transcripción

Universidad Jaume I
Desarrollo
Web Avanzado
Seguridad Web
2
Seguridad Web
ÍNDICE
3
Índice
Índice de figuras
3
1. Introducción a la seguridad Web.
6
2. Algunos datos.
7
3. Consideraciones básicas de seguridad.
3.1. Entrada de datos, variables globales y escapado automático, consideraciones.
3.2. Autenticación de usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Almacenamiento de contraseñas. . . . . . . . . . . . . . . . . . . . .
3.3. Gestión de la sesión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
11
14
15
4. Errores de seguridad convencionales.
4.1. HTML injection. . . . . . . . . . . . . .
4.2. SQL Injection. . . . . . . . . . . . . . . .
4.3. Blind SQL Injection. . . . . . . . . . . .
4.4. Cross Site Scripting (XSS). . . . . . . . .
4.4.1. XSS en sesiones no autenticadas.
4.4.2. XSS autocontenidos. . . . . . . .
4.5. Cross Site Request Forgeries (CSRF). . .
4.6. XPath Injection. . . . . . . . . . . . . .
4.7. Cross Site Tracing (XST). . . . . . . . .
4.8. Session Fixation. . . . . . . . . . . . . .
4.9. Session Hijacking. . . . . . . . . . . . . .
4.10. Weak Upload File Checks. . . . . . . . .
4.11. Allow url fopen. . . . . . . . . . . . . . .
4.12. División de respuesta HTTP. . . . . . . .
4.13. DNS Rebinding. . . . . . . . . . . . . . .
4.14. Comprobación insuficiente. . . . . . . . .
4.15. Null Byte. . . . . . . . . . . . . . . . . .
4.16. Apache y mod mime. . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
18
19
20
21
21
22
22
23
24
24
25
25
26
27
27
28
.
.
.
.
28
28
29
30
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Técnicas de protección adicionales.
5.1. Captchas, tipos de ataques. . . . . . . . . .
5.2. Controles anti-spam, ofuscación JavaScript. .
5.3. Herramientas de auditorı́a. . . . . . . . . . .
5.4. Cookies httponly y secure. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Referencias
32
Índice de figuras
1.
2.
3.
Clasificación por objetivo de los atacantes. . . . . . . . . . . . . . . . . . .
A quién se ataca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vulnerabilidades o tipos de ataques utilizados. . . . . . . . . . . . . . . . .
8
8
9
Seguridad Web
4
Índice de figuras
4.
5.
6.
7.
Inyección HTML. . . . . . . . . . . . . .
Cross Site Scripting. . . . . . . . . . . .
Un ejemplo de Captcha. . . . . . . . . .
Captcha de fácil reconocimiento de forma
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
automatizada.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
20
29
29
Seguridad Web
ÍNDICE DE FIGURAS
5
Seguridad Web
6
1 Introducción a la seguridad Web.
1.
Introducción a la seguridad Web.
La teorı́a de seguridad tradicional contempla tres dimensiones o propiedades básicas que
deben protegerse, éstas son la confidencialidad, la integridad y la disponibilidad.
Confidencialidad: Esta propiedad hace referencia a que el acceso a los datos solo
puede ser realizado por aquellas personas o entidades autorizadas.
Integridad: Esta propiedad indica que los datos deben mantenerse ı́ntegros, es decir,
exactamente igual que en su origen.
Disponibilidad: Esta propiedad hace referencia a que los datos deben estar accesibles
en el momento en el que son necesarios.
Autenticidad: Esta propiedad indica que los datos son auténticos, es decir, que
proceden de quien los originó y que no han sido modificados. Esta propiedad esta
ı́ntimamente relacionada con la integridad.
La teorı́a de seguridad tradicional intenta cubrir, fundamentalmente estos aspectos a pesar
de que no son las únicas propiedades a tener en cuenta1 .
Con la evolución de Internet y la Web, las aplicaciones de escritorio se han visto desplazadas por las aplicaciones Web basadas en tecnologı́as de cliente rico. Esto ha sido posible,
en parte, por la evolución de los navegadores que han pasado de ser simples presentadores
de páginas web a plataformas de ejecución de aplicaciones gracias a la adición por parte
de los desarrolladores de funcionalidades como XMLHttpRequest y redibujado dinámico
de secciones ası́ como la continua optimización aplicada sobre los motores JavaScript que
incorporan los navegadores.
Este hecho ha producido un desplazamiento de la investigación en materia de seguridad
desde la búsqueda y explotación2 en aplicaciones locales o de escritorio hacia la investigación en seguridad de aplicaciones Web. Fruto de esa investigación, aparece una clasificación
de vulnerabilidades más frecuentes, comúnmente aceptadas por los profesionales del sector. Organizaciones como OWASP3 o WASC4 dirigen sus esfuerzos hacia la mejora de la
seguridad Web en general ofreciendo para ello una clasificación de problemas comunes de
seguridad y qué medidas pueden adoptarse para cada una de ellas.
1
También existe, por ejemplo, el no repudio
Acto de aprovechar un error de seguridad para obtener un efecto que, inicialmente, no se nos permite.
3
Open Web Application Security Project
4
Web Application Consortium
2
Seguridad Web
7
2.
Algunos datos.
Sobre la mencionada clasificación, han surgido estudios que indican, en la medida de lo
posible, que objetivos se buscan detrás de un ataque contra una aplicación Web y qué tipo
de errores se suelen aprovechar para conseguirlos. Estos estudios, se realizan mediante la
exploración de las listas de información de vulnerabilidades5 o por empresas del sector de
la seguridad informática.
WASC esta llevando a cabo un proyecto en el que las empresas más relevantes en el ámbito
de la seguridad informática ofrecen sus datos estadı́sticos para mantener una información
completa sobre las amenazas más relevantes en cuanto a errores aprovechados por ataques
en aplicaciones Web.
A continuación expondremos los datos, para el informe que comprende el año 2007. El
primer aspecto que se estudia en el informe es la motivación de los ataques realizados, esto
es, el porqué de las acciones llevadas a cabo. Con respecto a esto, la figura 1 podemos ver
como la mayorı́a de los ataques buscan obtener información confidencial sobre la que no
tienen acceso lı́cito, esto vulnerarı́a la confidencialidad y el tipo de información que suele
buscarse en estos ataques son números de tarjetas de crédito, cuentas bancarias, credenciales de acceso a aplicaciones, direcciones de correo electrónico y secretos industriales.
Por otro lado vemos que la segunda motivación en orden de aparición es el “defacement”
o modificación de alguna de las páginas Web que componen el sitio, este hecho suele
responder a motivos polı́ticos6 o ideológicos y afecta fundamentalmente a la integridad
de la información. Podemos también apreciar como el objetivo de instalar “malware”7 en
los servidores web también es el tercer motivo de ataque de las aplicaciones Web, estas
instalaciones de “malware” permiten a los atacantes instalar software malicioso en algunas de las máquinas que visitan el sitio Web obteniendo el control sobre las mismas y
creando redes de botnets 8 . Por último el tipo de motivaciones que podemos identificar,
las podemos agrupar en chantajes y estafas o engaños. Recientemente surgió la alarma
en Internet por la aparición del virus GPCode9 , este virus realiza un cifrado de archivos
con ciertas extensiones utilizando criptografı́a fuerte de clave pública y después solicita la
compra de un software para recuperar lo archivos. Esto serı́a, obviamente, un ejemplo de
chantaje.
5
Como, por ejemplo, Bugtraq o Full-disclosure
Noticias relacionadas Hackean la web Ministerio de Vivienda y Un descuido en la web de Rajoy
permite que cualquiera la cambie.
7
Malware.
8
Botnet en wikipedia.
9
Información sobre el virus.
6
Seguridad Web
8
2 Algunos datos.
Figura 1: Clasificación por objetivo de los atacantes.
En este estudio también se clasifican los ataques por organizaciones como puede verse en
la figura 2. Podemos ver como los objetivos más atacados son aplicaciones Web gubernamentales, organizaciones educativas y tiendas on-line.
Figura 2: A quién se ataca.
El informe nos ofrece también una clasificación por tipos de errores o técnicas de ataque
utilizadas contra estas aplicaciones Web.Véase la figura 3.
Seguridad Web
9
A través de este documento presentaremos una descripción de estas técnicas y algunas
otras también utilizas ası́ como la forma de prevenirlas en nuestras aplicaciones web.
Figura 3: Vulnerabilidades o tipos de ataques utilizados.
3.
3.1.
Consideraciones básicas de seguridad.
Entrada de datos, variables globales y escapado automático,
consideraciones.
Podemos simplificar el funcionamiento de una aplicación web indicando que ésta funciona
de la siguiente forma:
1. El cliente, usualmente un navegador, solicita unos datos mediante una petición
HTTP. En algunos casos el cliente ofrece datos necesarios para acceder a esos datos
(inputs).
Seguridad Web
10
3 Consideraciones básicas de seguridad.
2. El servidor procesa los datos de entrada, en el caso de existir, y en función de
ellos recupera otros datos de alguna fuente (BBDD, ficheros,etc), les da un formato
determinado y los muestra.
La entrada de datos en el servidor desde el cliente puede darse de diferentes formas:
En la petición HTTP mediante GET o POST: Es la forma estándar de recibir datos
por parte del servidor, en el primer caso los datos se codifican en la URL de la
petición y en el segundo en el cuerpo de la misma petición.
En campos INPUT de un formulario: Estos campos input son enviados al servidor
utilizando uno de los dos métodos indicados arriba.
En forma de COOKIE: Podemos ver una cookie como un dato que establece un
servidor en un cliente y que éste último envı́a automáticamente en cada petición
posterior.
Estos inputs o entradas de datos deben ser siempre saneados en función del uso que se
vaya a hacer de ellos, por ejemplo, para utilizarlos en el acceso a BBDD debemos escapar
los caracteres \ ’ “ i NULL puesto que estos pueden dar lugar a modificaciones sobre las
consultas predefinidas provocando comportamientos no esperados en nuestra aplicación,
como veremos más adelante en la sección relativa a SQL injection y Blind SQL Injection.
Otro tipo de modificaciones sobre estos datos, pueden alterar el comportamiento de consultas sobre estructuras XML, como también veremos en la sección de XPath injection.
Si los datos de entrada van a ser incluidos en la presentación Web final, entonces, debemos tener especial cuidado con las marcas HTML que éstas entradas posean puesto que
nuevamente, una entrada especialmente diseñada puede modificar la página Web final.
Los lenguajes de programación más utilizados en programación web, nos ofrecen herramientas para realizar estos saneamientos, por ejemplo en PHP y Java podemos utilizar:
PHP
• magic quotes gpc: Esta directiva se establece en el fichero de configuración del
interprete PHP y hace que las entradas de datos a través de GET, POST y
COOKIE se “escapen” automáticamente frente a los caracteres ’,”,\ i NULL.
Esta funcionalidad ha sido motivo de polémica entre los desarrolladores de
PHP puesto que confiar en ella puede ser peligroso si la aplicación que lo hace
necesita migrarse por cualquier motivo y la nueva instalación de PHP tiene
esta funcionalidad desactivada. Probablemente, esto harı́a que en la aplicación
Seguridad Web
3.2 Autenticación de usuarios.
11
aparecieran multitud de problemas de seguridad que no existı́an antes. Otra
razón en contra es que todos los datos de entrada son escapados indiscriminadamente, a pesar de que éstos no vayan a ir a parar a una consulta SQL. Por
ultimo, tener en cuenta estos dos últimos aspectos, hace que la programación
sea algo más tediosa como puede verse en el siguiente ejemplo:
gpc.php
<?
if (!get_magic_quotes_gpc()) {
$data = addslashes($_POST[’data’]);
} else {
$data = $_POST[’data’];
}
?>
1
2
3
4
5
6
7
Por esto, los desarrolladores de PHP han decidido eliminar esta caracterı́stica
de la versión 6 de PHP y dejar en manos del programador o los entornos de
desarrollo las medidas de seguridad necesarias.
• strip tags(): Función PHP que elimina las marcas correspondientes a HTML y
PHP.
• addslashes(): Tiene el mismo efecto que la activación de magic quotes gpc al
ser aplicada sobre una variable.
• htmlentities(): Esta función convierte los caracteres especiales HTML a sus
correspondientes entidades codificadas de forma que el navegador las muestra
sin que interfieran en el código original.
• htmlspecialchars(): Convierte también caracteres especiales a entidades HTML,
la diferencia con htmlentities es que no convierte todos los caracteres, sólo los
más habituales.
Java
• PreparedStatement: En Java, esta clase escapa los caracteres especiales en relación a consultas SQL.
• StringEscapeUtils: Esta clase perteneciente al paquete commons de Apache,
nos permite realizar la misma traducción que htmlentities
3.2.
Autenticación de usuarios.
Entendemos por autenticación de usuarios el proceso que indica que un usuario es quien
dice ser o, al menos, tiene bajo su control las credenciales que le han sido ofrecidas en
algún tipo de proceso de registro.
Seguridad Web
12
Por otro lado la autorización es entendida como la capacidad de que un usuario ya identificado acceda a un recurso concreto dependiendo del grupo o rol al que pertenece dentro
de la aplicación.
En lo que al desarrollo de aplicaciones Web se refiere, debemos adoptar varias consideraciones especiales con respecto a este procedimiento:
Autenticación en el lado del cliente:
• Autenticación mediante scripts ejecutados en cliente: Nunca hay que autenticar
al usuario en el lado del cliente mediante scripts sobre los que él tiene control
puesto que puede manipularlos obteniendo acceso a recursos para los que no
esta autorizado.
• Autenticación utilizando Applets Java o Flash: Si la autenticación del usuario
va a llevarse a cabo mediante el despliegue de una aplicación Java (applet) o
Flash en el cliente, debe hacerse correctamente y cuidadosamente de forma que
no se incluyan datos relevantes en el proceso de autenticación que permitan
a un atacante saltarse el mismo. Esta recomendación viene dada puesto que
los applets Java son fácilmente decompilables con, por ejemplo, JAD10 y los
ficheros swf generados durante la compilación de flash, pueden decompilarse
también con facilidad utilizando, por ejemplo, Flash Decompiler11 .
La forma correcta de autenticar a un usuario utilizando un applet Java o una
aplicación flash, es mediante la utilización de un servicio Web que realice la
comprobación e indique la página a visitar en caso de éxito.
Autenticación por IP: La forma más simple de autenticar a un usuario es en función
de la ip de la máquina que utiliza y a pesar de ser éste un método poco seguro si se
utiliza de forma aislada, puede complementar controles sobre sesiones autenticadas
como veremos más adelante.
Cuando un cliente realiza una petición HTTP a un servidor, éste exporta dos variables de entorno que son fundamentales en la relación con la autenticación por IP,
estas son
• REMOTE ADDR: Nos indica la ip de la máquina que ha conectado con el
servidor.
• X FORWARDED FOR: La aparición de este campo en la petición HTTP es
debido a que la máquina que realiza la petición HTTP se encuentra detrás de
un proxy, y éste establece esta cabecera como información adicional sobre cual
de las máquinas que realizan peticiones a través de él ha sido la causante de la
petición.
Cuando autenticamos, o realizamos controles sobre la IP, no es suficiente comprobar el campo REMOTE ADDR puesto que dos máquinas que realizaran peticiones
10
11
Página del proyecto JAD
Página del proyecto Flash Decompiler
Seguridad Web
3.2 Autenticación de usuarios.
13
a través del mismo proxy compartirı́an el valor de este campo y por tanto la autenticación sin ser este el efecto deseado.
El utilizar únicamente el campo X FORWARDED FOR tampoco es correcto puesto
que este campo puede ser manipulado por el cliente para indicar cualquier dirección
IP.
Para realizar un correcto control de la dirección IP deberı́amos utilizar el campo
REMOTE ADDR y si existe el campo X FORWARDED FOR, la unión de ambos,
por ejemplo de esta forma: REMOTE ADDR - X FORWARDED FOR.
Autenticación por Usuario/Contraseña:
Cuando autenticamos al usuario por medio de un nombre de usuario y contraseña
y en general por cualquier tipo de datos que el usuario utilice como credenciales de
acceso y éstas le den acceso a ciertas partes de la aplicación Web, debemos tener
en cuenta que puede estar accediendo desde, por ejemplo, una red inalámbrica sin
cifrado de datos, o desde una LAN donde, con las herramientas adecuadas, puede
redirigirse el tráfico de datos de una máquina a otra sin que el usuario lo perciba.
Por esto, debemos utilizar SSL en la medida de lo posible, de forma que aunque los
datos sean capturados, estos no sean inteligibles por terceros.
Autenticación tipo CHAP:
Muchas veces, por restricciones de nuestro proveedor de hosting o por el hecho de
intentar eliminar el requisito SSL de nuestro proyecto, no podemos utilizar esta
tecnologı́a. En estos casos podemos utilizar CHAP12 .
CHAP es interesante por el hecho de que permite realizar autenticación sin transmitir ninguna contraseña por el canal de comunicaciones utilizado. Este método se
compone de los siguientes pasos:
1. Ambas partes, cliente y servidor conocen las credenciales de autenticación.
2. El cliente solicita iniciar el procedimiento de autenticación.
3. El servidor genera un reto aleatorio y lo envı́a al cliente.
4. Cliente y servidor realizan la operación x = hash(reto + credenciales), donde
hash es una función de resumen13 y + representa una operación de concatenación.
5. El cliente envı́a x al servidor.
6. El servidor compara x con x0 correspondiente al valor calculado por él. Si ambos
coinciden, la autenticación se ha llevado a cabo con éxito.
De esta forma si alguien captura x al ser enviado desde el cliente al servidor no
podrı́a utilizarlo puesto que deberı́a iniciar el proceso de autenticación y el servidor
generarı́a un nuevo reto y por tanto x serı́a distinto.
Se puede encontrar una implementación completa haciendo uso de JavaScript en el
lado del cliente y PHP en el lado del servidor en:
12
13
Challenge Handshake Authentication Protocol.
http://en.wikipedia.org/wiki/Cryptographic hash function
Seguridad Web
14
http://www.devarticles.com/c/a/JavaScript/Building-a-CHAP-Login-System-EncryptingData-in-the-Client/
Una implementación alternativa de este método pasa por la utilización del algoritmo
de cifrado por flujo RC4 de sencilla implementación y que sustituirı́a el uso de la
función de resumen.
Como contrapartida, este método obliga al servidor a almacenar la contraseña del
cliente en formato “plano”.
Autenticación X509:
Este tipo de autenticación forma parte del protocolo TLS14 y permite autenticar
tanto a cliente como servidor haciendo uso de una infraestructura de clave pública15 .
Para ello es necesario que tanto el servidor como el cliente “entiendan” ssl. Utilizando
un tamaño de clave adecuado para cada algoritmo de cifrado, este método es uno
de los más “fuertes” que podemos utilizar.
En este punto cabe mencionar que este tipo de autenticación puede utilizarse también sin necesidad de hacer uso de SSL. Para esto, serı́a necesario desplegar una
aplicación en el cliente, por ejemplo un applet Java, que le permitiera al usuario firmar unos datos aleatorios que el servidor habrı́a enviado, el procedimiento completo
serı́a:
1. El cliente realiza un petición de autenticación al servidor.
2. El servidor genera unos datos aleatorios y los envı́a junto con un applet que se
“despliega” en el cliente permitiéndole firmar.
3. El cliente firma esos datos haciendo uso del applet y envı́a la firma de vuelta
al servidor.
4. El servidor comprueba que la firma es correcta y válida y en tal caso da al
cliente como autenticado.
3.2.1.
Almacenamiento de contraseñas.
En el cliente: Una de las funciones de la aplicación en cuanto a su nivel de seguridad
es informar en la medida de lo posible y de una forma útil y clara al usuario de los
problemas de seguridad que puede experimentar al utilizar ciertas funcionalidades
de los navegadores, como por ejemplo el almacenamiento de contraseñas.
Este almacenamiento es relevante desde el punto de vista de la seguridad puesto que,
como veremos más adelante, existen técnicas para obtener esos datos utilizando otras
vulnerabilidades de las aplicaciones Web.
En el servidor: En el lado del servidor, las contraseñas deberı́an almacenarse, en la
medida de lo posible, de forma ininteligible. De esta forma las contraseñas estarán
14
15
http://www.faqs.org/rfcs/rfc2246.html
http://es.wikipedia.org/wiki/X.509
Seguridad Web
3.3 Gestión de la sesión.
15
protegidas frente a accesos no autorizados a este tipo de información. Para ello
podemos utilizar, nuevamente, una función de resumen (como sha1 o sha256 ).
3.3.
Gestión de la sesión.
En este punto nos referimos a sesión como la parte que queda en el servidor que relaciona
a un usuario con su “entorno” autenticado, dejando a un lado otras generalidades como
sesiones no autenticadas.
Sobre una sesión autenticada, debemos establecer, al menos, los siguientes controles:
Validez temporal de la sesión: La sesión debe expirar en un tiempo razonable,
dependiendo el objetivo de la misma, pero no debe permitir sesiones sin caducidad
ni con excesivo tiempo de expiración.
Un ejemplo donde la gestión incorrecta de este aspecto de la sesión podrı́a inducir
problemas de seguridad es en los ordenadores de acceso público, bien sean cibercafés,
bibliotecas, salas multimedia, etc. Donde al cambiar de un usuario a otro, si el
primero no ha eliminado la sesión de alguna forma, el segundo puede utilizarla
ilı́citamente.
Debe realizarse un control de IP: Si, por cualquier motivo, un atacante consigue
el identificador de sesión de otro, no debe ser posible que acceda a la aplicación
utilizando este identificador desde otra máquina.
Envı́o de token asociado a formularios: Este control consiste en establecer o bien
un campo hidden con un token único en formularios y enlaces a zonas autenticadas
de la aplicación o un parámetro token=xxxxxxxxxx a las URL destino de zonas
autenticadas. De esta forma emulamos sesiones autenticadas con accesos, “de un
solo uso” y este uso se invalida frente un acceso del usuario generando un nuevo
token. La forma de utilizar esto es la siguiente:
1. El cliente se autentica ofreciendo las credenciales correctas.
2. El servidor genera un valor aleatorio suficientemente grande, unos 20 bytes
serı́a más que suficiente, y lo añade a un campo hidden o a la URL de todas
los enlaces que se generen en la página a enviar al cliente.
3. El servidor almacena ese valor aleatorio en la sesión.
4. Cuando el cliente realiza una nueva petición, envı́a el token de forma transparente, el servidor lo valida, genera un nuevo token y sustituye el anterior. A
partir de aquı́ se continúa nuevamente desde el punto 2.
En entornos abiertos: En este punto, nos referimos a transmisiones realizadas mediante WIFI, LANs y entornos poco fiables. En estos casos, deberı́amos utilizar SSL
Seguridad Web
16
4 Errores de seguridad convencionales.
puesto que a un usuario autenticado, se le podrı́a robar el identificador de sesión y
suplantar su dirección IP.
Mediante cookies: Podemos ver las cookies como datos adicionales que se establecen
en el lado del cliente y contienen, en el caso de las sesiones, el identificador de sesión.
Sobre éstas, deben aplicarse las medidas de seguridad explicadas anteriormente.
SessionId: De forma alternativa a las cookies para almacenar el identificador de
sesión en el cliente, algunas implementaciones de lenguajes de servidor, nos permiten
inicializar la sesión añadiendo sessionid=xxxxxx al final de la URL que representa
la petición.
4.
Errores de seguridad convencionales.
A continuación, veremos una relación de descripción, ejemplo y solución a aplicar para
las técnicas más utilizadas en cuanto a explotación Web.
4.1.
HTML injection.
Descripción: Este tipo de técnica consiste en inyectar código HTML que no es
correctamente saneado para manipular el código HTML final que visualizará el
usuario. Este tipo de ataques se utilizan como complemento de otros más complejos
como, por ejemplo, el phishing16 .
Ejemplo: A continuación puede verse un código, escrito en PHP, que es vulnerable,
en él podemos introducir en el formulario <H1>Injection</H1> alterando el resultado final.
htmlinj.php
1
2
3
4
5
6
7
8
9
16
<?
if ($_GET[’user’]){
echo "Hola: " . $_GET[’user’];
}
else{
echo "<form method=’GET’ action=’’>".
"Introduce tu nombre: <input type=’text’ name=’user’>".
"<input type=’submit’ value=’enviar’>";
}
http://es.wikipedia.org/wiki/Phishing
Seguridad Web
4.2 SQL Injection.
10
17
?>
11
Figura 4: Inyección HTML.
Solución: Utilizar funciones de conversión de caracteres especiales a entidades HTML
para que éstos sean visualizados a través del navegador en lugar de ser interpretados
por él.
4.2.
SQL Injection.
Descripción: Esta técnica permite manipular las consultas SQL que se realizan contra una base de datos para que el comportamiento no sea el esperado por el programador.
Ejemplo: Imaginemos que en la consulta del siguiente ejemplo, “SELECT * FROM
users WHERE login=’$login’ and pass=’$pass”’ el usuario introduce el siguiente
valor de login: ’OR 1=1#, la consulta SQL resultante se convertirı́a en “SELECT *
FROM users WHERE login=’’OR 1=1#’ and pass=”” que siempre devolverá tantas filas como usuarios existan en la BBDD y por tanto la comprobación de la lı́nea
13 se evaluarı́a como cierta sin haber introducido las credenciales de acceso correctas.
sqlinj.php
1
2
3
4
<?
$login= $_POST[’login’];
$pass= $_POST[’pass’];
$host= "localhost";
5
6
7
8
$conexion= mysql_connect($host, ’user’, ’pwd’);
$consulta="SELECT * FROM users WHERE login=’$login’" .
"and pass=’$pass’";
Seguridad Web
18
9
10
11
12
13
14
15
16
17
$result= mysql_db_query(’bbdd’, $consulta)
or die("<h1>Fallo en la consulta</h1>");
$num_rows= mysql_num_rows($result);
if ($num_rows > 0)
//Usuario logeado;
else
//Usuario invalido;
?>
Solución: Utilizar funciones de escapado de caracteres especiales en consultas a
BBDD para los valores introducidos por el usuario. En PHP puede utilizarse la
función mysql real escape string y en Java la clase PreparedStatement.
4.3.
Blind SQL Injection.
Descripción: Esta técnica se basa en el mismo error de programación del SQL injection convencional con la diferencia de que, modificando la sentencia, el atacante
sólo logra alguna modificación sutil del sitio Web sin más información. Esto suele
aprovecharse por medio de ataques de fuerza bruta (prueba y error de determinado espacio de soluciones) o ataques con diccionario (prueba y error con espacio de
soluciones predefinido).
Ejemplo: En este ejemplo, podemos ver como ante una consulta válida, a pesar
de no existir un id determinado, el texto “Noticia:” aparecerá. Si la consulta falla,
este no aparecerá. De esta forma el atacante tiene la certeza de que esta enviando
consultas válidas contra la BBDD y por tanto puede ejecutar el código SQL que sea
necesario para conseguir su objetivo.
Un ataque común que aprovecha esta vulnerabilidad es el uso de la función user()
para obtener el usuario que conecta con la bbdd ejecutando la siguiente secuencia
de sentencias SQL aprovechando la inyección:
• select * where user() like “a %”
• select * where user() like “b %”
• select * where user() like “c %”
• select * where user() like “d %”
• ...
• select * where user() like “ra %”
• select * where user() like “rb %”
• select * where user() like “rc %”
• select * where user() like “rd %”
Seguridad Web
4.4 Cross Site Scripting (XSS).
19
• ...
Hasta obtener el nombre de usuario correcto.
bsqlinj.php
1
2
3
<?
$login= $_POST[’id’];
$host= "localhost";
4
5
6
$conexion= mysql_connect($host, ’user’, ’pwd’);
$consulta="SELECT text FROM news WHERE id=’$id’";
7
8
9
10
11
12
13
14
15
$result= mysql_db_query(’bbdd’, $consulta)
if (!$result)
die();
else{
while($r= mysql_fetch_assoc($result))
echo "Noticia: " . $r[’text’];
}
?>
Solución: Como en el caso anterior, utilizar funciones de escapado de caracteres
especiales SQL.
4.4.
Cross Site Scripting (XSS).
Descripción: Esta técnica aprovecha, de nuevo, el hecho de un saneamiento de
parámetros de entrada incorrecto para inyectar código de script en el cliente, por
ejemplo JavaScript, para obtener datos confidenciales y enviarlos a un tercer servidor.
Ejemplo: El código que se ha utilizado como ejemplo es el mostrado en el listado del
punto 4.1. En cuyo formulario hemos introducido la siguiente secuencia de caracteres
<script>alert(document.cookie);</script> haciendo que se nos muestre la cookie
seleccionada para ese dominio.
El ataque completo, consiste en hacer que un usuario “pinche” sobre un enlace
especialmente creado con el código indicado en él.
Seguridad Web
20
Figura 5: Cross Site Scripting.
En el ejemplo, hemos utilizado la función JavaScript alert para mostrar el efecto
aunque en un ataque real se utilzarı́an marcas como <img src= o <iframe src=
para hacer que el usuario enviara los datos de sesión a un tercer servidor controlado
por el atacante.
Solución: Este error se evita, también, realizando el saneamiento adecuado sobre las
variables de entrada, o bien eliminando las marcas especiales o bien traduciendo los
caracteres especiales a entidades html.
4.4.1.
XSS en sesiones no autenticadas.
Cuando la sesión aún no ha sido autenticada, el identificador de sesión existente en la
cookie aún no tiene valor, aún ası́, pueden realizarse dos tipos de ataques.
Fijación de sesión: Un atacante podrı́a establecer la cookie mediante, por ejemplo,
Javascript utilizando document.cookie=, una vez hecho esto, solo harı́a falta esperar
a que el usuario se autenticara para que el atacante posea un identificador de sesión
correspondiente a una sesión autenticada.
Abuso del gestor de contraseñas: Esta técnica se basa en intentar extraer la contraseña del formulario una vez se introduzca automáticamente por el gestor de contraseñas del navegador.
El ataque se basa en inyectar algo como:
Seguridad Web
4.5 Cross Site Request Forgeries (CSRF).
21
<script>
function getPwd(){
alert(document.forms[0].pwd.value);
}
setTimeout("getPwd();",4000);
</script>
En un sitio Web en el que existe un formulario de autenticación, el campo de introducción de password posee como name pwd y el usuario ha utilizado el gestor de
contraseñas para recordarla.
4.4.2.
XSS autocontenidos.
Las últimas versiones de navegadores Web, en concreto Firefox y Opera, incorporan la
implementación del RFC 239717 por medio del cual se pueden especificar url’s con el siguiente formato:
data:[<mediatype>][;base64],<data>
Esto permite evitar, por parte del atacante, los controles sobre marcas de formato puesto
que estas pueden ir codificadas en base64 como puede verse a continuación:
data:text/html;base64,PHNjcmlwdD4KYWxlcnQoIlNlbGYtY29udGFpbm
VkIFhTUyIpOwo8L3NjcmlwdD4=
Que es equivalente a:
<script>
alert("Self-contained XSS");
</script>
4.5.
Cross Site Request Forgeries (CSRF).
Descripción: Un forjado o creación de petición cruzada consiste, aprovechando una
vulnerabilidad de inyección de código HTML, en hacer que el usuario realice, sin
percatarse, una petición a determinado sitio.
17
http://www.ietf.org/rfc/rfc2397.txt
Seguridad Web
22
Ejemplo: Supongamos que un usuario permanece autenticado en, por ejemplo, un
webmail, nosotros desde un enlace especialmente diseñado, hacemos que cargue una
página en la que inyectamos el siguiente código:
<img src=http://webmail.xx.yy/index.php?cmd=delete&mailbox=Inbox&confirm=false/>
Casualmente el código inyectado realiza un borrado de la carpeta de entrada de
correo electrónico de ese usuario en el webmail y puesto que la petición la realiza
el navegador del usuario, éste envı́a el identificador de sesión y en consecuencia la
acción se ejecuta exitosamente.
Solución: Nuevamente, el escapado de caracteres especiales debidamente, soluciona
este problema.
4.6.
XPath Injection.
Descripción: Esta técnica permite manipular las consultas XPath que se realizan
contra estructuras de datos XML.
Ejemplo: Imaginemos la siguiente consulta
//user[name/text()=’$login’ and password/text()=’$pass’]
si se introduce como login: ’ or 1=1 or ”=’, la consulta XPath resultante se convertirı́a en “//user[name/text()=’’ or 1=1 or ”=’’ and password/text()=”] que siempre
devolverá tantas entidades como usuarios existan en la estructura XML y por tanto
si se comprobara que el número de entidades devueltas es distinto de cero, el atacante habrı́a conseguido obviar la autenticación.
Solución: Escapar los caracteres especiales en consultas XPath.
4.7.
Cross Site Tracing (XST).
Descripción: Este ataque utiliza el método TRACE del protocolo HTTP para tener
acceso a las cabeceras que envı́a el cliente. Como ejemplo de aplicación práctica,
supongamos que un cliente posee una cookie establecida con el valor httponly (ver
punto 5.4), de forma que no se puede acceder a ella mediante scripting por vulnerabilidades XSS pero, si el servidor tuviera activo este método, se podrı́a construir una
petición XMLHttpRequest haciendo uso del método TRACE y la cookie nos serı́a
devuelta en el cuerpo de la respuesta como puede verse en el ejemplo a continuación.
Ejemplo: Este es un ejemplo de funcionamiento del método TRACE en cuya lı́nea 17
podemos apreciar como se devuelve la cookie utilizada en el cuerpo de la respuesta.
Seguridad Web
4.8 Session Fixation.
1
2
3
4
5
6
7
23
xst.sh
paul@chip:~$ telnet jepsi.org 80
Trying 66.98.168.3...
Connected to jepsi.org.
Escape character is ’^]’.
TRACE / HTTP/1.1
Host: www.jepsi.org
Cookie: id=1234567
8
9
10
11
12
13
HTTP/1.1 200 OK
Date: Tue, 17 Jun 2008 14:57:09 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http
14
15
16
17
18
3d
TRACE / HTTP/1.1
Cookie: id=1234567
Host: www.jepsi.org
19
20
21
0
22
23
Connection closed by foreign host.
Solución: Este ataque no se puede llevar a cabo por sı́, es necesario un vector de
ataque como puede ser la explotación de una vulnerabilidad XSS en la aplicación.
Por tanto la solución aquı́ pasa por, nuevamente, aplicar las medidas de filtrado de
entradas de forma adecuada.
Obviamente, la desactivación del método TRACE en el lado del servidor, anula la
posibilidad de explotar esta particularidad.
4.8.
Session Fixation.
Descripción: Esta técnica consiste en “fijar” la sesión del usuario previamente y
esperar a que se autentique en el sistema. De esta forma, como la sesión la ha
establecido el atacante posee su id y por tanto tiene acceso a esta sesión autenticada.
Ejemplo: El atacante hace que el usuario siga un enlace, bien sea publicándolo en un
foro, enviándole un mail o mediante un acceso a una página controlada por el atacante que contenga enlaces tipo <img src=”http://www.xxx.yy/?sessionid=123456”>.
Una vez que el usuario accede a esa URL de una forma u otra, se le establece una
cookie con ese identificador de sesión y en caso de autenticarse seguidamente en el
sitio al que pertenece la cookie, el atacante ya tendrı́a acceso autenticado.
Seguridad Web
24
Solución: El no aceptar sesiones que no hayan sido generadas por el servidor, la
regeneración del identificador de sesión frente a cada petición o el uso de tokens
(véase 3.3) son soluciones posibles. A continuación mostramos un ejemplo de como
aceptar únicamente sesiones generadas en el servidor:
sessfix.php
<?
if (!isset($_SESSION[’SERVER_GENERATED_SID’])) {
session_destroy(); // destroy all data in session
}
session_regenerate_id(); // generate a new session identifier
$_SESSION[’SERVER_GENERATED_SID’] = true;
?>
1
2
3
4
5
6
7
4.9.
Session Hijacking.
Descripción: Podemos traducir esta técnica como “secuestro de sesión” y consiste en
obtener acceso a los datos de la sesión para obtener acceso autenticado a determinado
sitio Web.
Ejemplo: En un entorno en el que utilizamos conectividad WIFI, alguien captura
todos los paquetes que las máquinas conectadas estas emitiendo, en uno de ellos
encuentra una petición HTTP generada por nuestra máquina en la que se envı́a una
cookie a un sitio Web en el que estamos autenticados. Este usuario, se establece
dicha cookie y accede al sitio.
Solución: Las soluciones en este punto pasan por cifrar el canal de comunicaciones
o realizar comprobaciones adicionales sobre el cliente que mantiene la cookie de
sesión lı́cita. Esta última, tiene también problemas de seguridad puesto que en una
red “abierta” cualquiera puede “competir” con nosotros por la misma dirección IP
si no se adoptan las medidas necesarias.
4.10.
Weak Upload File Checks.
Descripción: Se comprueba el upload o renombrado de ficheros de forma insuficiente.
Ejemplo: Permitimos que el usuario suba y nombre sus ficheros con extensiones del
tipo .php, .php4, .php5, .cgi, .py, .asp, .aspx, etc. Estos ficheros, dependiendo de
la configuración del servidor Web, pueden convertirse en ejecutables por módulos
interprete del servidor Web por el simple hecho de nombrarse ası́. De esta forma un
atacante que perciba esta situación podrı́a ejecutar código arbitrario en el servidor.
Seguridad Web
4.11 Allow url fopen.
25
Solución: Desactivar “motores interpretes” en los directorios en los que se almacenen
los ficheros (i.e. “php admin flag engine off” para PHP) o realizar comprobaciones
restrictivas en cuanto a nombre de ficheros, esto es, por ejemplo para imágenes .jpg,
permitir únicamente el upload y renombrado de ficheros con extensión .jpg en lugar
de permitir todas las extensiones salvo aquellas que acaben en .php, .php5, etc.
Las comprobaciones sobre la extensión y las comprobaciones permisivas tienen problemas de seguridad adicionales como veremos en los puntos 4.15 y 4.16
4.11.
Allow url fopen.
Descripción: Muchos módulos correspondientes a interpretes de lenguajes de servidor, permiten llevar a cabo acciones como esta (en PHP):
file get contents(“http://www.xxxxx.yy/a”)
Por otro lado, muchos programadores cometen el error de implementar sus aplicaciones Web con URLs como esta:
http://www.xxxx.yy/index.php?content=products.php
estas dos circunstancias permiten inyectar código en el servidor.
Ejemplo: En la URL anterior, el atacante introduce en vez de la cadena products.php, esta otra: http://www.xxxxx.yy/myphp de forma que su script se incluirá en el script del servidor y se interpretará pudiendo ejecutar código arbitrario.
Solución: Deshabilitar esta funcionalidad y no permitir que el usuario pueda modificar los “includes” que realiza el código del servidor.
4.12.
División de respuesta HTTP.
Descripción: Esta técnica consiste en hacer que el servidor imprima un “carriage return” junto con un “line feed” seguido de una respuesta especialmente confeccionada
por el atacante. De esta forma el atacante, puede conseguir realizar ataques XSS o
cache poisoning, éstos últimos, consisten en manipular la cache de los proxy-cache
intermedios si los hubiera, de forma que, después del ataque, enviarán la información
manipulada como válida.
Ejemplo: Supongamos una aplicación que establece el nombre de usuario en una
cookie obteniendo el mismo de una entrada que ha proporcionado el usuario, en
condiciones normales, la cookie se establecerı́a como vemos a continuación:
Seguridad Web
26
setcook
HTTP/1.1 200 OK
...
Set-Cookie: usuario=paul
...
1
2
3
4
1
2
3
Pero si el usuario introduce la siguiente cadena paulCRLFHTTP/1.1 200 OKCRLF
la respuesta ofrecida por el servidor es la siguiente:
setcookspl
HTTP/1.1 200 OK
...
Set-Cookie: usuario=paul
4
HTTP/1.1 200 OK
...
5
6
De esta forma, se ha divido la respuesta HTTP en dos confundiendo a proxy caches
intermedios los cuales pueden almacenar en cache la segunda respuesta como buena,
a partir de entonces servirán esa página como si de la original se tratara.
Solución: Filtrar correctamente las entradas para no permitir que el usuario pueda
manipular la respuesta del servidor.
4.13.
DNS Rebinding.
Descripción: La técnica de DNS rebinding es aprovechable desde Applets en Java,
aplicaciones Flash y tecnologı́as similares de cliente. El objetivo principal de esta
técnica suele ser la realización de un escaneo de servicios contra máquinas de una
red privada no visible desde Internet.
Ejemplo: La secuencia de realización de este ataque es la siguiente:
1. El atacante logra que la vı́ctima visite un sitio Web controlado por él y sobre
cuyo registro DNS correspondiente al dominio tiene control y ha seleccionado
un TTL muy bajo en la configuración del mismo.
2. El cliente descarga un applet.
3. Este applet únicamente puede conectarse con el dominio del que se descargo
debido a la “same origin policy”.
4. El atacante cambia el registro DNS para que apunte a un ip correspondiente
a la máquina que queremos escanear dentro de la red privada, por ejemplo
10.0.0.5
5. El applet intenta conectar a todos los puertos de esa máquina y recopila toda
la información posible.
Seguridad Web
4.14 Comprobación insuficiente.
27
6. El atacante restablece el registro DNS con su información original.
7. El applet conecta de nuevo al servidor para devolver el resultado del escaneo.
Solución: La gestión, a veces impredecible, de la cache de los servidores DNS hace
que este ataque sea impracticable en la realidad. A pesar de ello, las últimas versiones
de entornos de ejecución de aplicaciones en cliente (plugin Java, plugin Flash, etc.)
realizan una resolución de nombre en el despliegue de la aplicación y cachean el
resultado para utilizarlo durante toda la sesión.
4.14.
Comprobación insuficiente.
Descripción: Otro de los errores comunes en lo referente a la programación Web
es el hecho de no realizar las comprobaciones suficientes, por ejemplo, frente a la
autorización de usuarios al acceso de algunos recursos.
Ejemplo: En un sitio Web, cuando un usuario se autentica le aparece un enlace que
le permite llevar a cabo una acción privilegiada. Cuando otro usuario no autenticado
accede directamente a este enlace a pesar de no estar autenticado, puede realizar la
acción privilegiada.
Solución: Comprobar siempre la autorización frente al acceso a un recurso en cada
script. Una técnica aconsejable es separar scripts con acciones privilegiadas de aquellos que no lo son, en la medida de lo posible, e invocar funciones de comprobación
siempre al inicio de los scripts que requieren autenticación.
4.15.
Null Byte.
Descripción: Esta técnica se basa en la forma en la que se implementan ciertas
funcionalidades por parte de los interpretes de código. Cuando se abre un fichero o
se realiza una lectura, las llamadas a funciones suelen traducirse a implementaciones
nativas en C. Esta técnica aprovecha esta situación para introducir una marca de
fin de de cadena 0x0 que tiene el efecto de delimitar el fin de la cadena en C, pero
no tiene más significado que un carácter adicional en lenguajes interpretados.
Ejemplo: Si por ejemplo utilizamos el lenguaje de programación Java en el servidor,
podrı́amos realizar la comprobación de que un nombre de fichero finaliza con .jpg
de la siguiente forma:
1
2
3
nullbyte.java
if (filename.endsWith(".jpg"))
{
File f = new File(filename);
Seguridad Web
28
5 Técnicas de protección adicionales.
...
4
5
Esta comprobación se evaluarı́a a true ante la cadena fichero secreto.txt %00.jpg
pero al realizar la apertura del fichero, éste se interpretarı́a como fichero secreto.txt
puesto que la cadena contiene un byte nulo aquı́. Por tanto el fichero accedido
finalmente serı́a este último.
Solución: Filtrar y eliminar los Null Bytes de la cadena antes de realizar operaciones
de bajo nivel.
4.16.
Apache y mod mime.
Descripción: Puesto que Apache es uno de los servidores Web más utilizados para servir sitios Web, cabe comentar una particularidad que puede hacer que las
comprobaciones sobre ficheros no se realicen correctamente.
Ejemplo: Cuando nombramos un fichero como script.php.xyz, el módulo encargado
de interpretar el tipo de fichero adecuado (mod mime), intenta mapear el tipo .xyz,
sino existe, intenta mapear el tipo .php y ası́ sucesivamente.
Solución: Realizar comprobaciones restrictivas sobre los nombres de fichero como se
indica en el punto 4.10.
5.
Técnicas de protección adicionales.
A través del documento, se han ido mostrando técnicas de explotación de errores de
seguridad ası́ como las soluciones a aplicar en cada caso, pero existen vulnerabilidades
que tienen relación, no tanto con los errores de programación, sino con las aplicaciones
en sı́, a continuación, describimos algunas de estas situaciones.
5.1.
Captchas, tipos de ataques.
Si nuestra aplicación posee un formulario de registro, contacto, etc. Podemos sufrir un
ataque automatizado en el que un usuario malintencionado puede insertar cientos de
registros inválidos en la BBDD. Para evitar esto, se introducen los captchas, variantes de
la Prueba de Turing18 cuyo objetivo es garantizar o asegurar, en la medida de lo posible
que el registro no esta siendo realizado de forma automática.
18
http://es.wikipedia.org/wiki/Prueba de Turing
Seguridad Web
5.2 Controles anti-spam, ofuscación JavaScript.
29
Figura 6: Un ejemplo de Captcha.
Estos captchas deben ser lo suficientemente irregulares para imposibilitar el reconocimiento automático por programas de reconocimiento de imágenes. Por ejemplo un captcha
como el presentado en la figura 7 serı́a fácil de obviar por herramientas automatizadas.
Figura 7: Captcha de fácil reconocimiento de forma automatizada.
5.2.
Controles anti-spam, ofuscación JavaScript.
Una práctica habitual de los denominados spammers es la de descargar el contenido de
sitios Web y analizarlos en busca de direcciones de correo electrónico a las que poder
enviar correo basura. Para evitar el análisis automatizado en busca de direcciones de
correo por estas herramientas existen, al menos, dos opciones recomendables:
Codificar la dirección de correo electrónico indicando al usuario que se debe sustituir
para obtener el original. Por ejemplo santapau at uji dot es.
Como segunda opción podemos utilizar una codificación en javascript19 de forma que
este código transforma un texto ininteligible en la dirección correcta. Este método
funciona por el hecho de que los analizadores no suelen incorporar interpretes de
javascript y por tanto no encuentran la dirección de correo electrónico en el texto.
De estas opciones, la segunda es más recomendable puesto que algunos analizadores sı́ poseen la habilidad de sustituir ciertas cadenas como las mostradas en el ejemplo (at y dot)
obteniendo ası́ la dirección original.
19
Podéis encontrar un utilidad en: http://members.cox.net/timandbeth/spam/
Seguridad Web
30
5.3.
5 Técnicas de protección adicionales.
Herramientas de auditorı́a.
Existen diferentes herramientas para comprobar si nuestros desarrollos web son vulnerables a cierto tipo de ataques automatizados. Puesto que la descripción detallada del uso
de estas herramientas sobrepasa el objetivo de este texto, mencionaremos aquı́ cada una
de ellas junto con una descripción de las mismas.
WebScarab20 Herramienta promovida por el OWASP, permite auditar diferentes
tipos de errores como SQL injection o XSS entre otros. La herramienta ha sido
diseñada utilizando un arquitectura de plugins de forma que es bastante simple
incorporar nueva funcionalidad.
LiveHTTPHeaders21 Esta herramienta viene implementada en forma de extensión
para Mozilla Firefox y nos permite ver que cabeceras, tanto en la petición como en
la respuesta, se están produciendo en cada momento.
Tamper Data22 Esta herramienta también es una extensión para Mozilla Firefox, su
caracterı́stica principal es que permite manipular las cabeceras relativas al protocolo
HTTP antes de enviarlas.
Nessus Es una completa herramienta de auditorı́a que no se ciñe únicamente a la
auditorı́a web sino que explora otros diversos aspectos como arquitectura de red,
servicios de mail, DNS, etc. También posee una arquitectura de plugins que permite
incorporar fácilmente nuevas funcionalidades.
Fuzzers Podı́amos describir un fuzzer como “un alimentador de entradas aleatorias
de un espacio de posibilidades indicado”, es decir, un fuzzer genera entradas aleatorias que se corresponden a determinados criterios y las ofrecen al programa en
busca de comportamientos poco usuales.
5.4.
Cookies httponly y secure.
httponly: Este modificador de cookie hace que ésta no sea accesible mediante lenguajes de scripting en el lado del cliente, por tanto solo será enviada en peticiones
HTTP.
secure: Este modificador hace que la cookie sólo se envı́e si la conexión por la que
va a ser enviada implementa SSL, esto es, utiliza el protocolo https.
20
http://www.owasp.org/index.php/Category:OWASP webScarab Project
http://livehttpheaders.mozdev.org/installation.html
22
http://tamperdata.mozdev.org/
21
Seguridad Web
5.4 Cookies httponly y secure.
31
Seguridad Web
32
Referencias
Referencias
[1] Web Application Security Consortium. http://www.webappsec.org/. 2008.
[2] Open Web Application Security Project. http://www.owasp.org/. 2008.
[3] Gnu Citizen blog. http://www.gnucitizen.org/blog/self-contained-xss-attacks/. 2008.
[4] PortSwigger.
http://blog.portswigger.net/2008/05/null-byte-attacks-are-alive-andwell.html. 2008.
[5] Dafydd Stuttard and Marcus Pinto, The Web Application Hacker’s Handbook: Detecting and Exploiting Security Flaws.. Wiley, Octubre 2007.
Seguridad Web
REFERENCIAS
33
Reconocimiento - No comercial - Compartir igual: Este material puede ser distribuido,
copiado y exhibido por terceros si se muestra en los créditos la autorı́a del mismo. No se
puede obtener ningún beneficio comercial y las obras derivadas tienen que estar bajo los
mismos términos de licencia que el trabajo original.
Autor: Paúl Santapau Nebot. <[email protected]>
Revisado por: Manuel David Mollar Villanueva, Jacobo Avariento Gimeno.

Desarrollo Web Avanzado

Transcripción

Documentos relacionados

Respuestas Fase Preselectiva – 7° ORM

Coordinador de Servicios Médicos / Medical Services Coordinator

1 ¿Para qué valor de x el siguiente conjunto de vectores es