Segsoft 3 Trab

Asignatura Datos del alumno Fecha
Apellidos: Vera Gaibor

Seguridad en el
08/11/2018
Software
Nombre: Catherine
Contenido
Índice de Figuras...................................................................................................... 2
Auditoría de código de una aplicación con la herramienta de HP Fortify ....................... 3
1. Command Injection: ........................................................................................ 4
1.1 Estudio Detallado ........................................................................................... 4
2. Cross-Site Scripting: Persistent. ................................................................... 6
2.1 Estudio Detallado. .......................................................................................... 6
3. Cross-Site Scripting: Reflected. .................................................................... 9
3.1 Estudio Detallado. .......................................................................................... 9
4. Dynamic Code Evaluation: Code Injection................................................ 11
4.1 Estudio Detallado. ......................................................................................... 11
5. Key Management: Hardcoded Encryption Key. ....................................... 13
6. Open Redirect. .................................................................................................. 15
7. Password Management: Hardcoded Password. ...................................... 17
8. Key Management: Hardcoded Encryption Key. ....................................... 19
9. XML External Entity Injection. ................................................................... 22
9.1 Estudio Detallado. ........................................................................................ 22
10. XPath Injection............................................................................................ 24
10.1 Estudio Detallado. .................................................................................... 24
TEMA 3 – Actividades
1
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Índice de Figuras
Figura 1. Vulnerabilidad. .............................................................................................. 4

Figura 2. Flujo de Vulnerabilidad................................................................................ 4
Figura 3. ParameterParser. .......................................................................................... 4
Figura 4. WSDLScanning. ............................................................................................ 5
Figura 5. Diagrama. ....................................................................................................... 5
Figura 6. Vulnerabilidad 2. ........................................................................................... 6
Figura 7. Flujo de Vulnerabilidad 2............................................................................. 6
Figura 8. WSDLScanning ............................................................................................. 7
Figura 9. WSDLScanning 2. ......................................................................................... 7
Figura 10. Diagrama de Vulnerabilidad 2. ................................................................. 8
Figura 11. Vulnerabilidad 3........................................................................................... 9
Figura 12. Flujo de Vulnerabilidad 3. .......................................................................... 9
Figura 13. getReader. ..................................................................................................... 9
Figura 14. addElement. ............................................................................................... 10
Figura 15. Diagrama de Vulnerabilidad 3................................................................. 10
Figura 16. Vulnerabilidad 4. ....................................................................................... 11
Figura 17. Flujo de Vulnerabilidad 4. ........................................................................ 11
Figura 18. menu_system.js......................................................................................... 12
Figura 19. Diagrama de Vulnerabilidad 4. ............................................................... 12
Figura 20. Vulnerabilidad 5. ...................................................................................... 13
Figura 21. Flujo de Vulnerabilidad 5. ........................................................................ 13
Figura 22. DOMInjection............................................................................................ 14
Figura 25. Flujo de Vulnerabilidad 6. ....................................................................... 15
Figura 26. Redirect ...................................................................................................... 16
Figura 30. LogSpoofing............................................................................................... 18
Figura 31. Diagrama de Vulnerabilidad 7. ................................................................ 18
Figura 32. Vulnerabilidad 8 ....................................................................................... 19
Figura 34. ParameterValues ....................................................................................... 20
Figura 35. SqlNumericInjection ................................................................................ 20
Figura 37. Vulnerabilidad 9. ....................................................................................... 22
Figura 39. WsSAXInjection ........................................................................................ 23
Figura 41. Vulnerabilidad 10. ..................................................................................... 24
Figura 42. Flujo de Vulnerabilidad 10. ..................................................................... 24
Figura 43. ParameterParser ....................................................................................... 25
Figura 44. XPATHInjection.java. .............................................................................. 25
Figura 45. Diagrama de Vulnerabilidad 10. ............................................................. 25
2
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Actividades
Auditoría de código de una aplicación con la

herramienta de HP Fortify
Con este ejercicio te iniciarás en el uso y manejo de la aplicación de análisis estático de
código Fortify SCA mediante el análisis de toda una aplicación escrita en Java. Se
describe cómo utilizar el componente de la aplicación Audit Workbench, para realizar
el ciclo de revisión de código de los resultados que Fortify SCA genera.
El método más sencillo para el análisis de una aplicación Java es indicar a Audit
Workbench el directorio de base de los archivos fuente que componen la aplicación.
Con esta información, Fortify SCA identifica automáticamente todos los tipos de
fuentes conocidas de archivos en los directorios especificados, como archivos fuente de
Java, Java Server Pages (JSP), PL / SQL y TSQL archivos, y archivos de configuración
XML. También identifica y utiliza los archivos .jar que encuentra para resolver nombres
de símbolos definidos en el código fuente.
El documento en el que se describe cómo utilizar Audit Workbench está disponible en

el aula virtual.
La aplicación Fortify SCA y su licencia están disponible en el siguiente enlace:

http://descargas.unir.net/escueladeingenieria/05 Seguridad_del_Software/Trabajo 4
Análisis Estatico con Herramienta Fortify de SSW.rar
La aplicación también está disponible, ya instalada, en el escritorio virtual de la UNIR:

https://salainformaticaunir.u-cloudservices.com/
Realizar un trabajo en el que se explique la auditoría realizada, de 10 de las

vulnerabilidades de diferente tipo y de carácter crítico encontradas por la herramienta
que incluya un estudio detallado del código (incluir esquemas. gráficos de llamadas,
flujos del programa, porciones de código explicadas, etc.) y documentación de las
mismas y se proponga una posible solución.
3
Seguridad en el
08/11/2018
Software
Nombre: Catherine
1. Command Injection:
WSDLScanning.java:143
Figura 1. Vulnerabilidad.
1.1 Estudio Detallado
1.1.1. Flujo de la Vulnerabilidad.
Figura 2. Flujo de Vulnerabilidad.
1.1.2. Explicación y Código.

Un atacante puede cambiar el comando que ejecuta el programa.
Los datos ingresan a la aplicación desde una fuente no confiable, en este caso, los
datos entran en getParameterValues() en la línea 593 dentro de
ParameterParser.java.
Figura 3. ParameterParser.
4
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Los datos se utilizan como parte de una cadena que representa un comando que
ejecuta la aplicación, el comando se ejecuta con setOperationName() en la línea
143 de WSDLScanning.java.
Figura 4. WSDLScanning.
Al ejecutar el comando, la aplicación le otorga a un atacante un privilegio o

capacidad que de otra manera este no podría tener.
1.1.3. Diagrama
Figura 5. Diagrama.
En este diagrma se muestra el camino que se ha seguido hasta la vulnerabilidad.
1.1.4. Posible Solución

No se debe confiar en el entorno y se deben tomar precauciones para evitar que un
atacante use alguna manipulación del entorno. Siempre que sea posible, los
comandos deben ser controlados por la aplicación y ejecutados utilizando una ruta
absoluta. En los casos en que no se conoce la ruta en el momento de la compilación,
como en el caso de las aplicaciones multiplataforma, se debe construir una ruta
absoluta a partir de valores confiables durante la ejecución. Los valores de comando
y las rutas que se leen desde los archivos de configuración o el entorno deben
5
Seguridad en el
08/11/2018
Software
Nombre: Catherine
verificarse sanamente contra un conjunto de invariantes que definen valores

válidos.
Asegurarse de aplicar el principio de privilegio mínimo siempre que el programa
ejecute un comando externo: no se debe tener privilegios que no sean esenciales
para el programa.
2. Cross-Site Scripting: Persistent.

WDLSScanning.java:221
Figura 6. Vulnerabilidad 2.
2.1 Estudio Detallado.
Figura 7. Flujo de Vulnerabilidad 2.
2.1.2. Explicación y Código

Los datos ingresan a una aplicación web a través de una fuente no confiable. En el
caso de XSS persistente (también conocido como almacenado), la fuente no
confiable suele ser una base de datos u otro almacén de datos de back-end. En ese
caso, los datos entran en invoke() en la línea 150 de WSDLScanning.java.
6
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 8. WSDLScanning
Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin
ser validado, los datos se envían en addElement() en la línea 221 de
WSDLScanning.java
Figura 9. WSDLScanning 2.
El contenido malicioso enviado al navegador web a menudo toma la forma de un

segmento de JavaScript, pero también puede incluir HTML, Flash o cualquier
otro tipo de código que el navegador pueda ejecutar. La variedad de ataques
basados en XSS es casi ilimitada, pero comúnmente incluyen transmitir datos
7
Seguridad en el
08/11/2018
Software
Nombre: Catherine
privados como cookies u otra información de sesión al atacante, redirigir a la

víctima a contenido web controlado por el atacante o realizar otras operaciones
maliciosas en la máquina del usuario bajo la disfraz del sitio vulnerable.
2.1.3. Diagrama.
Figura 10. Diagrama de Vulnerabilidad 2.

Se puede notar que la información ingresa desde la línea 150 y llega a la línea 221 en
donde está el elemento addElement(), el cual realiza la validación durante el proceso.

Dado que las vulnerabilidades de XSS ocurren cuando una aplicación incluye
datos maliciosos en su salida, un enfoque lógico es validar los datos
inmediatamente antes de que salga de la aplicación en este caso la línea 221. Sin
embargo, dado que las aplicaciones web a menudo tienen un código complejo e
intrincado para generar contenido dinámico, este método es propenso a errores
de omisión. Una forma efectiva de mitigar este riesgo es también realizar una
validación de entrada para XSS, aquí la línea 150.
8
Seguridad en el
08/11/2018
Software
Nombre: Catherine
3. Cross-Site Scripting: Reflected.

AbstractLesson.java:920

En este caso, los datos ingresan en getReader() en AbstractLesson.java en la
línea 900.
Figura 13. getReader.
Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin
ser validado, los datos se envían en addElement() en la línea 920 de
AbstractLesson.java.
9
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 14. addElement.
El contenido malicioso enviado al navegador web a menudo toma la forma de un

segmento de JavaScript, pero también puede incluir HTML, Flash o cualquier
otro tipo de código que el navegador pueda ejecutar. La variedad de ataques
basados en XSS es casi ilimitada, pero comúnmente incluyen transmitir datos
privados como cookies u otra información de sesión al atacante, redirigir a la
víctima a contenido web controlado por el atacante o realizar otras operaciones
maliciosas en la máquina del usuario bajo la disfraz del sitio vulnerable.
3.1.3. Diagrama.
Se puede notar que la información ingresa desde la línea 150 y llega a la línea 221 en
donde está el elemento addElement(), el cual realiza la validación durante el proceso.
10
Seguridad en el
08/11/2018
Software
Nombre: Catherine

Dado que las vulnerabilidades de XSS ocurren cuando una aplicación incluye
datos maliciosos en su salida, un enfoque lógico es validar los datos
inmediatamente antes de que salga de la aplicación en este caso la línea 221. Sin
embargo, dado que las aplicaciones web a menudo tienen un código complejo e
intrincado para generar contenido dinámico, este método es propenso a errores
de omisión. Una forma efectiva de mitigar este riesgo es también realizar una
validación de entrada para XSS, aquí la línea 150, también se puede implementar
una lista blanca de caracteres permitidos, para evitar que inserten comandos
con objetivos maliciosos.
4. Dynamic Code Evaluation: Code Injection.

AbstractLesson.java:920

El archivo menu_system.js interpreta las entradas no validadas del usuario como
código fuente en la línea 137. La interpretación de las instrucciones controladas
11
Seguridad en el
08/11/2018
Software
Nombre: Catherine
por el usuario en el tiempo de ejecución puede permitir a los atacantes ejecutar

código malicioso.
Figura 18. menu_system.js
Las vulnerabilidades de inyección de código se producen cuando el programador

supone incorrectamente que las instrucciones proporcionadas directamente por
el usuario solo realizarán operaciones inocentes, como realizar cálculos simples
en objetos de usuario activos o modificar el estado del usuario. Sin embargo, sin
la validación adecuada, un usuario puede especificar las operaciones que el
programador no pretende.
4.1.3. Diagrama.
12
Seguridad en el
08/11/2018
Software
Nombre: Catherine

En caso de ser necesario que el código se interprete dinámicamente, la
probabilidad de ataque se puede minimizar al restringir el código que el
programa ejecutará dinámicamente tanto como sea posible, limitándolo a un
subconjunto específico de la aplicación y del contexto del lenguaje de
programación base.
Si se requiere la ejecución de código dinámico, la aplicación nunca debe ejecutar e
interpretar directamente la entrada de usuario sin validar, en cambio será
recomendable crear una lista de operaciones legítimas y objetos de datos que los
usuarios pueden especificar, y solo permita que los usuarios seleccionen de la
lista.
5. Key Management: Hardcoded Encryption Key.

DOMInjection.java.57

Las claves de cifrado codificadas pueden comprometer la seguridad del sistema
de una manera que no puede remediarse fácilmente.
No es buena idea codificar una clave de cifrado porque permite a todos los
desarrolladores del proyecto ver dicha clave y hace que la solución del problema
sea extremadamente difícil. Una vez que el código está en producción, la clave de
cifrado no se puede cambiar sin parchear el software. Si la cuenta que está
13
Seguridad en el
08/11/2018
Software
Nombre: Catherine
protegida por la clave de cifrado está comprometida, los propietarios del sistema
se verán obligados a elegir entre seguridad y disponibilidad.
Figura 22. DOMInjection
5.1.3. Diagrama.

Las claves de cifrado nunca deben estar codificadas y deben estar ofuscadas y
administradas en una fuente externa. El almacenamiento de las claves de cifrado
en texto sin formato en cualquier parte del sistema permite que cualquier persona
con permisos suficientes para leer y posiblemente haga un mal uso de la clave de
cifrado.
14
Seguridad en el
08/11/2018
Software
Nombre: Catherine
6. Open Redirect.
Redirect.jsp:12(SharedSink)
From redirect.jsp:12(OpenRedirect)

El archivo redirect.jsp pasa datos no validados a una función de
redireccionamiento HTTP en la línea 12. Permitir que la entrada no validada
controle la URL utilizada en una redirección puede ayudar a los ataques de
phishing. Los redireccionamientos permiten a las aplicaciones web dirigir a los
usuarios a diferentes páginas dentro de la misma aplicación o a sitios externos.
En este caso, la URL a la que se redireccionará al cliente se acepta en

getParameter () en redirect.jsp en la línea 12, los datos se envían en sendRedirect
() en redirect.jsp en la línea 12.
15
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 26. Redirect
6.1.3. Diagrama.

No se debe permitir que las entradas de usuario sin validar controlen la URL de
destino en una redirección. En su lugar, use un nivel de direccionamiento
indirecto: cree una lista de URL legítimas que los usuarios pueden especificar y
solo permita que los usuarios seleccionen de la lista. Con este enfoque, la entrada
proporcionada por los usuarios nunca se usa directamente para especificar una
URL para las redirecciones.
redirect.jsp en la línea 12.
16
Seguridad en el
08/11/2018
Software
Nombre: Catherine
7. Password Management: Hardcoded Password.

LogSpoofing.java:59

Las contraseñas codificadas pueden comprometer la seguridad del sistema de una
manera que no puede remediarse fácilmente.
Nunca es una buena idea codificar una contraseña. La codificación de una
contraseña no solo permite a todos los desarrolladores del proyecto ver la
contraseña, sino que también dificulta la solución del problema. Una vez que el
código está en producción, la contraseña no se puede cambiar sin parchear el
software. Si la cuenta protegida por la contraseña está comprometida, los
propietarios del sistema se verán obligados a elegir entre seguridad y
disponibilidad.
17
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 30. LogSpoofing
7.1.3. Diagrama.

Las contraseñas nunca deben estar codificadas y, por lo general, deben estar
ofuscadas y administradas en una fuente externa. El almacenamiento de
contraseñas en texto sin formato en cualquier parte del sistema le permite a
cualquier persona con permisos suficientes leer y potencialmente hacer un mal uso
de la contraseña. Como mínimo, las contraseñas deben estar grabadas antes de ser
almacenadas. Algunos productos de terceros afirman la capacidad de administrar
contraseñas de una manera más segura. Por ejemplo, WebSphere Application
Server 4.x utiliza un algoritmo de cifrado XOR simple para confundir los valores,
pero sea escéptico acerca de tales instalaciones. WebSphere y otros servidores de
aplicaciones ofrecen mecanismos de cifrado obsoletos y relativamente débiles que
son insuficientes para entornos sensibles a la seguridad. Para una solución genérica
segura, la mejor opción hoy parece ser un mecanismo propietario que usted crea.
18
Seguridad en el
08/11/2018
Software
Nombre: Catherine
8. Key Management: Hardcoded Encryption Key.

DOMInjection.java.57
Figura 32. Vulnerabilidad 8

En la línea 130 de SqlNumericInjection.java, el método injectableQuery () invoca
una consulta SQL creada utilizando una entrada proveniente de una fuente no
confiable. Esta llamada podría permitir a un atacante modificar el significado de
la declaración o ejecutar comandos SQL arbitrarios.
Los errores de inyección de SQL ocurren cuando, los datos ingresan a un
programa desde una fuente no confiable se puede notar en la figura a
continuación que los datos entran en getParameterValues () en
ParameterParser.java en la línea 627.
19
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 34. ParameterValues
Los datos se utilizan para construir dinámicamente una consulta SQL, en la figura 35 se
puede constar que los datos se pasan a executeQuery () en SqlNumericInjection.java en
la línea 130.
Figura 35. SqlNumericInjection
20
Seguridad en el
08/11/2018
Software
Nombre: Catherine
8.1.3. Diagrama.

La causa raíz de una vulnerabilidad de inyección de SQL es la capacidad de un
atacante para cambiar el contexto en la consulta SQL, lo que genera un valor que
el programador pretende interpretar como datos que deben interpretarse como
un comando. Cuando se construye una consulta SQL, el programador sabe qué se
debe interpretar como parte del comando y qué se debe interpretar como datos.
Las sentencias SQL parametrizadas pueden imponer este comportamiento al
rechazar los cambios de contexto dirigidos por datos y evitar casi todos los
ataques de inyección de SQL. Los parámetros de enlace permiten al programador
especificar explícitamente a la base de datos qué se debe tratar como un comando
y qué se debe tratar como datos. Cuando el programa está listo para ejecutar una
declaración, especifica a la base de datos los valores de tiempo de ejecución que
se deben utilizar para cada uno de los parámetros de enlace sin el riesgo de que
los datos se interpreten como una modificación del comando.
21
Seguridad en el
08/11/2018
Software
Nombre: Catherine
9. XML External Entity Injection.

WsSAXInjection.java:179

El analizador XML configurado en WsSAXInjection.java:179 no impide ni limita
la resolución de las entidades externas. Esto puede exponer al analizador a un
ataque de entidades externas XML.
Los ataques de entidades externas XML se benefician de una característica XML
para construir documentos dinámicamente en el momento del procesamiento.
Una entidad XML permite la inclusión dinámica de datos de un recurso dado.
22
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 39. WsSAXInjection
9.1.3. Diagrama.

El desaprobador de XML se debe configurar de forma segura para que no permita
que las entidades externas formen parte de un documento XML entrante.
Para evitar la inyección XXE, no utilice métodos unmarshal que procesen una
fuente XML directamente como java.io.File, java.io.Reader o java.io.InputStream.
Analice el documento con un analizador configurado de forma segura y utilice un
método unmarshal que tome el analizador seguro como fuente XML.
23
Seguridad en el
08/11/2018
Software
Nombre: Catherine
10. XPath Injection.

XPATHInjection.java:158

En la línea 158 de XPATHInjection.java, el método createContent () llama una
consulta XPath creada utilizando una entrada no validada. Esta llamada podría
permitir a un atacante modificar el significado de la declaración o ejecutar
consultas XPath arbitrarias. La inyección de XPath ocurre cuando los datos
ingresan a un programa desde una fuente no confiable.
En este caso, los datos entran en getParameterValues () en ParameterParser.java
en la línea 627.
24
Seguridad en el
08/11/2018
Software
Nombre: Catherine
Figura 43. ParameterParser
Los datos utilizados para construir dinámicamente una consulta XPath, la consulta se
pasa a evaluar () en XPATHInjection.java en la línea 158.
Figura 44. XPATHInjection.java.
10.1.3. Diagrama.
25
Seguridad en el
08/11/2018
Software
Nombre: Catherine

Para evitar que un atacante viole las expectativas del programador, use una lista
blanca para asegurarse de que los valores controlados por el usuario que se usan
en una consulta XPath se componen solo del conjunto esperado de caracteres y
no contengan ningún metacarácter XPath dado el contexto en el que se usan. Si
un valor controlado por el usuario requiere que contenga metacaracteres XPath,
use un mecanismo de codificación apropiado para eliminar su importancia dentro
de la consulta XPath.
26

Segsoft 3 Trab

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Segsoft 3 Trab

Cargado por

Copyright:

Formatos disponibles

Asignatura Datos del alumno Fecha

Apellidos: Vera Gaibor

Figura 1. Vulnerabilidad. .............................................................................................. 4

Auditoría de código de una aplicación con la

El documento en el que se describe cómo utilizar Audit Workbench está disponible en

La aplicación Fortify SCA y su licencia están disponible en el siguiente enlace:

La aplicación también está disponible, ya instalada, en el escritorio virtual de la UNIR:

Realizar un trabajo en el que se explique la auditoría realizada, de 10 de las

1.1 Estudio Detallado

1.1.1. Flujo de la Vulnerabilidad.

Figura 2. Flujo de Vulnerabilidad.

1.1.2. Explicación y Código.

Al ejecutar el comando, la aplicación le otorga a un atacante un privilegio o

En este diagrma se muestra el camino que se ha seguido hasta la vulnerabilidad.

1.1.4. Posible Solución

verificarse sanamente contra un conjunto de invariantes que definen valores

2. Cross-Site Scripting: Persistent.

2.1 Estudio Detallado.

2.1.1. Flujo de la Vulnerabilidad.

Figura 7. Flujo de Vulnerabilidad 2.

2.1.2. Explicación y Código

El contenido malicioso enviado al navegador web a menudo toma la forma de un

privados como cookies u otra información de sesión al atacante, redirigir a la

Figura 10. Diagrama de Vulnerabilidad 2.

2.1.4. Posible Solución

3. Cross-Site Scripting: Reflected.

Figura 11. Vulnerabilidad 3.

3.1 Estudio Detallado.

3.1.1. Flujo de la Vulnerabilidad.

Figura 12. Flujo de Vulnerabilidad 3.

3.1.2. Explicación y Código

Figura 13. getReader.

Figura 14. addElement.

El contenido malicioso enviado al navegador web a menudo toma la forma de un

Figura 15. Diagrama de Vulnerabilidad 3.

3.1.4. Posible Solución

4. Dynamic Code Evaluation: Code Injection.

Figura 16. Vulnerabilidad 4.

4.1 Estudio Detallado.

4.1.1. Flujo de la Vulnerabilidad.

Figura 17. Flujo de Vulnerabilidad 4.

4.1.2. Explicación y Código

por el usuario en el tiempo de ejecución puede permitir a los atacantes ejecutar

Figura 18. menu_system.js

Las vulnerabilidades de inyección de código se producen cuando el programador

Figura 19. Diagrama de Vulnerabilidad 4.

4.1.4. Posible Solución

5. Key Management: Hardcoded Encryption Key.

Figura 20. Vulnerabilidad 5.

5.1 Estudio Detallado.

5.1.1. Flujo de la Vulnerabilidad.

Figura 21. Flujo de Vulnerabilidad 5.

5.1.2. Explicación y Código

Figura 22. DOMInjection

Figura 23. Diagrama de Vulnerabilidad 5.

5.1.4. Posible Solución

Figura 24. Vulnerabilidad 6.

6.1 Estudio Detallado.

6.1.1. Flujo de la Vulnerabilidad.

Figura 25. Flujo de Vulnerabilidad 6.

6.1.2. Explicación y Código

En este caso, la URL a la que se redireccionará al cliente se acepta en

Figura 26. Redirect