Seguridad de JAX-RS frente a ataques por inyección de código I

Seguridad de JAX-RS frente a

ataques por inyección de código

Juan Carlos Fuyo Gonzales

Jael Alexander Rivera Oviedo

Universidad Católica de Colombia

Facultad de Ingeniería
Programa de Ingeniería de Sistemas
Modalidad
Bogotá D.C., Colombia
2016
II Título de la tesis o trabajo de investigación

Seguridad de JAX-RS frente a

ataques por inyección de código

Juan Carlos Fuyo Gonzales

Jael Alexander Rivera Oviedo

Monografía presentada como requisito parcial para optar al título de:

Ingeniero de Sistemas

Director (a):
[Link] Jhon Velandia

Coordinador Proyecto de Grado:

Ing. Jhon Velandia

Universidad Católica de Colombia

Facultad de Ingeniería
Programa de Ingeniería de Sistemas
Modalidad
Bogotá D.C., Colombia
2016
IV Título de la tesis o trabajo de investigación

CONTENIDO
Pág.

LISTA DE ILUSTRACIONES........................................................................................... VI

LISTA DE TABLAS ........................................................................................................ VII

LISTA DE CODIGOS FUENTE ...................................................................................... VIII

RESUMEN ....................................................................................................................... IX

ABSTRACT ...................................................................................................................... X

LISTA DE SÍMBOLOS Y ABREVIATURAS ....................................................................10

INTRODUCCIÓN .............................................................................................................14

1. GENERALIDADES ...................................................................................................17
1.1 ANTECEDENTES ............................................................................................. 17
1.2 PLANTEAMIENTO DEL PROBLEMA ................................................................ 18
1.2.1 Descripción del Problema .............................................................................. 18
1.2.2 Formulación del Problema ............................................................................. 18
1.3 OBJETIVOS ...................................................................................................... 19
1.3.1 Objetivo General ............................................................................................ 19
1.3.2 Objetivos Específicos ..................................................................................... 19
1.4 JUSTIFICACIÓN ............................................................................................... 19
1.5 DELIMITACIÓN ................................................................................................. 20
1.5.1 Espacio .......................................................................................................... 20
1.5.2 Tiempo ........................................................................................................... 20
1.5.3 Contenido ...................................................................................................... 20
1.5.4 Alcance .......................................................................................................... 20
1.6 MARCO REFERENCIAL ................................................................................... 21
1.6.1 Marco teórico ................................................................................................. 21
1.6.2 Marco Conceptual .......................................................................................... 25
1.7 METODOLOGÍA ................................................................................................ 32
1.7.1 Tipo de Estudio .............................................................................................. 32

2. SELECCIÓN DE ALGORITMOS ..............................................................................33

2.1. FACTIBILIDAD DE ÉXITO ................................................................................. 33
2.2. DOCUMENTACIÓN........................................................................................... 34
2.3. POSICIONAMIENTO OWASP ........................................................................... 36
2.4. PROBABILIDAD DE SER EXPLOTADO SEGÚN LA CWE ............................... 37
2.5. VALIDACION ..................................................................................................... 38

3. DEFINICIÓN DE REQUISITOS ................................................................................43

 3.1. REQUERIMIENTOS FUNCIONALES ................................................................ 43
3.2. REQUERIMIENTOS NO FUNCIONALES .......................................................... 43

4. DISEÑO DEL SISTEMA ...........................................................................................44

4.1 ACTORES ......................................................................................................... 44
4.2 CASOS DE USO ............................................................................................... 44
4.2.1 Realizar análisis ............................................................................................. 44
4.2.2 Escanear servicio Web................................................................................... 44
4.2.3 Ver resultados ................................................................................................ 44
4.3 DIAGRAMA DE CONTEXTO ............................................................................. 45

5. ARQUITECTURA DEL SISTEMA ............................................................................45

5.1. Diagrama de despliegue .................................................................................... 46
5.2. Diagrama de componentes ................................................................................ 46
5.3. Diagrama de clases ........................................................................................... 47

6. DESARROLLO DEL SISTEMA ................................................................................47

6.1. CAPA DE PRESENTACIÓN .............................................................................. 47
6.2. CAPA LÓGICA .................................................................................................. 48
6.3. CLIENTE ........................................................................................................... 55
6.4. CAPA DE NEGOCIO ......................................................................................... 55

7. ESCENARIO DE PRUEBAS ....................................................................................61

7.1. ESCENARIO DE PRUEBAS .............................................................................. 61
7.2. DESARROLLO DEL WEB SERVICE ................................................................. 62
7.2.1. Capa modelo.................................................................................................. 62
7.2.2. Capa de presentación .................................................................................... 67
7.2.3. Capa lógica .................................................................................................... 69
7.2.4. Capa de Despliegue....................................................................................... 88

8. EVALUACIÓN DE VULNERABILIDADES ...............................................................89

8.1. VULNERABILIDADES ....................................................................................... 89
8.1.1. Producto afectado .......................................................................................... 90
8.1.2. Ubicación ....................................................................................................... 91
8.1.3. Causa ............................................................................................................ 91
8.1.4. Impacto .......................................................................................................... 92
8.2. RESULTADOS .................................................................................................. 93
8.2.1. Producto afectado .......................................................................................... 93
8.2.2. Ubicación ....................................................................................................... 94
8.2.3. Causa ............................................................................................................ 95
8.2.4. Impacto .......................................................................................................... 96
8.2.5. Consolidado ................................................................................................... 97
8.3. ANÁLISIS DE RESULTADOS ........................................................................... 99

9. CONCLUSIONES ...................................................................................................101

10. REFERENCIAS ......................................................................................................103

Seguridad de JAX-RS frente a ataques por inyección de código VI

LISTA DE ILUSTRACIONES
Pág.
Ilustración 1: Cifrado SSL ................................................................................................ 23
Ilustración 2: Diagrama de casos de uso ......................................................................... 44
Ilustración 3: Diagrama de contexto ................................................................................. 45
Ilustración 4: Diagrama de despliegue ............................................................................. 46
Ilustración 5: Diagrama de componentes ......................................................................... 46
Ilustración 6: Diagrama de clases .................................................................................... 47
Ilustración 7 Interfaz PAIC ............................................................................................... 48
Ilustración 9: Despliegue implementaciones .................................................................... 88
Seguridad de JAX-RS frente a ataques por inyección de código VII

LISTA DE TABLAS
Pág.
Tabla 1: Selección según criterio de factibilidad de éxito ................................................. 34
Tabla 2: Resumen de resultados de la búsqueda de documentos ................................... 35
Tabla 3: Selección según criterio de documentación ....................................................... 36
Tabla 4: Selección según criterio de posicionamiento en OWASP ................................... 37
Tabla 5: Selección según criterio de probabilidad de ser explotado según la CWE ......... 37
Tabla 6: Selección de los algoritmos a implementar ........................................................ 38
Tabla 7: Librerías Persistencia......................................................................................... 65
Tabla 8: Librerías DAO .................................................................................................... 66
Tabla 9: librerias service rest ........................................................................................... 86
5. Tabla 10: Vulnerabilidades bajo el parámetro de productos afectados ..................... 90
Tabla 11: Vulnerabilidades bajo el parámetro de ubicación ............................................. 91
Tabla 12: Vulnerabilidades bajo el parámetro de causa ................................................... 92
Tabla 13: Vulnerabilidades bajo el parámetro de impacto ................................................ 93
Tabla 14: Nivel de vulnerabilidad bajo el parámetro de producto afectado ...................... 93
Tabla 15: Nivel de vulnerabilidad bajo el parámetro de ubicación .................................... 94
Tabla 16: Nivel de vulnerabilidad bajo el parámetro de causa ......................................... 95
Tabla 17: Nivel de vulnerabilidad bajo el parámetro de impacto ...................................... 96
Tabla 18: Nivel de vulnerabilidad final.............................................................................. 97
 VIII Título de la tesis o trabajo de investigación

LISTA DE CODIGOS FUENTE

Código fuente N° 1: Anotaciones de seguridad soportadas por JAX-RS.......................... 24

Código fuente N° 2: Exclusión de Anotaciones de seguridad en JAX-RS ........................ 25
Código fuente N° 3: Evento Click GET............................................................................. 48
Código fuente N° 4: Evento Click POST .......................................................................... 49
Código fuente N° 5: Clase HttpURLConnectionAttack ..................................................... 50
Código fuente N° 6: Attack GET ...................................................................................... 51
Código fuente N° 7: Attack POST .................................................................................... 52
Código fuente N° 8: Clase AlgoritmAttack ........................................................................ 53
Código fuente N° 9: Xpath Attack .................................................................................... 53
Código fuente N° 10: SQL Attack ..................................................................................... 54
Código fuente N° 11: Shell Attack .................................................................................... 54
Código fuente N° 12: Modelo XML ................................................................................... 63
Código fuente N° 13: Tabla log ........................................................................................ 64
Código fuente N° 16: Estructura HTML ............................................................................ 67
Código fuente N° 17: Estructura HTML ............................................................................ 67
Código fuente N° 18: Estructura CSS .............................................................................. 67
Código fuente N° 19: Función de login JavaScript ........................................................... 68
Código fuente N° 20: Función test de JavaScript ............................................................. 69
Código fuente N° 21: [Link] Jersey .............................................................................. 72
Código fuente N° 22: Get Jersey ..................................................................................... 73
Código fuente N° 23: Post Jersey 1 ................................................................................. 74
Código fuente N° 24: Post Jersey 2 ................................................................................. 74
Código fuente N° 25: [Link] RESTEasy ....................................................................... 76
Código fuente N° 26: Get RESTEasy............................................................................... 76
Código fuente N° 27: Post RESTEasy 1 .......................................................................... 78
Código fuente N° 28: Post RESTEasy 2 .......................................................................... 78
Código fuente N° 29: [Link] Restlet.............................................................................. 79
Código fuente N° 30: Restlet Route Attach ...................................................................... 80
Código fuente N° 31: Get Restlet ..................................................................................... 80
Código fuente N° 32: Post Restlet 1 ................................................................................ 81
Código fuente N° 33: Post Restlet 2 ................................................................................ 82
Código fuente N° 34: CXF [Link] ................................................................................. 83
Código fuente N° 35: CXF [Link] .............................................................................. 84
Código fuente N° 36: CXF ServiceRest ........................................................................... 85
Código fuente N° 38: CXF GET ....................................................................................... 86
Código fuente N° 39: CXF POST 1 .................................................................................. 87
Código fuente N° 40: CXF POST 2 .................................................................................. 87
 RESUMEN
Los servicios RESTful están inmersos en actividades tan cotidianas como usar una
aplicación de pagos o renovar una suscripción a una revista por internet, por esto es
importante que dichos servicios sean seguros frente a ataques informáticos. De acuerdo
al proyecto OWASP “Open Web Application Security Project”[1] el cual tiene un Top 10 de
principales amenazas a aplicaciones Web, destaca en primer lugar los ataques por
inyección de código.

En la edición empresarial de Java se incluye la especificación para la API JAX-RS, la cual

brinda utilidades para implementar servicios RESTful por medio de anotaciones, este
proyecto tiene como objetivo desarrollar un prototipo que realice ataques por inyección de
código a servicios RESTful desarrollados en 4 implementaciones de JAX-RS, con el fin de
medir la vulnerabilidad de estas frente a este tipo de ataques.

Inicialmente se realiza una introducción a los servicios RESTful con JAX-RS, se definen
sus principales características y algunas implementaciones usadas en la industria, las
utilidades de seguridad que define ORACLE y un contexto de seguridad de los servicios
RESTful en general, posteriormente se describen los algoritmos de ataque por inyección
de código definidos por OWASP[1].

En este proyecto se implementan tres algoritmos de los descritos en el documento, para

seleccionarlos se utiliza un método cuantitativo basado en cuatro criterios propuestos
aquí. Teniendo en cuenta los algoritmos a implementar se definen los requerimientos para
diseñar y desarrollar el prototipo, se describe la arquitectura y el desarrollo de la
aplicación, además del escenario de pruebas donde se encuentran los servicios RESTful
a ser atacados.

Por último se define una sección de evaluación de resultados, en la que se indican los
niveles de vulnerabilidad encontrados en cada una de las implementaciones
seleccionadas, frente a los tres tipos de ataque por inyección de código realizados por el
prototipo desarrollado, se finaliza con un análisis de los resultados encontrados y algunas
conclusiones de la investigación.
 X Título de la tesis o trabajo de investigación

ABSTRACT
RESTful services are immersed in daily activities like using an app to make payments or to
renew a subscription to a magazine through Internet. For this reason it is really important
for those services to be safe before cyber-attacks. According to the OWASP Project (Open
Web Application Security Project), which has a top ten web applications main threats, it
underlines firstly the code injection attacks.

The Java business edition includes the specification for the API JAX-RS, which gives
utilities to implement RESTful services throughout annotations. This project has the
objective to develop a prototype that makes code injection attacks to RESTful services
developed in four JAX-RS implementations, with the purpose of measuring their
vulnerability before this kind of attacks.

Initially an introduction with JAX-RS to the RESTful services is done. Then it is defined
their main characteristics and some implementations used in the industry, the safety
utilities defined by ORACLE and a security context of the RESTful services in general.
Afterwards the attack algorithms by code injection defined by OWASP are described.

This project implements three algorithms from those described in the document. To select
them, it is used a quantitative method based on four criterions here proposed. Taking into
account the algorithms to implement, the requirements to design and develop the
prototype are described. Besides, it is described the architecture and the development of
the application and the test scenarios where it can be found the RESTful services to be
attacked.

Finally it is defined a section of evaluation of results, in which it is indicated the levels of

vulnerability found in each one of the chosen implementations facing the three kind of
attacks by code injections made by the developed prototype. It ends also with an analysis
of the found results and some conclusions of the research.

LISTA DE SÍMBOLOS Y ABREVIATURAS

Abreviaturas

Abreviatura Término

Interfaz de Programación de Aplicaciones son un conjunto de

API funciones y procedimientos que cumplen una o muchas tareas con
el fin de ser usados por otro software
Seguridad de JAX-RS frente a ataques por inyección de código 11

Abreviatura Término

Un Objeto de Java Plano Antiguo es una clase sencilla que no

POJO extiende ni implementa nada adicional que no dependen de una
librería adicional

Identificador Único de Recursos sirve para localizar recursos en

URI
internet ya sea por ubicación o nombre
Localizador de Recursos Uniforme es un subconjunto de URI.
URL La URL define como se puede obtener el recurso

Entorno de desarrollo de trabajo que integra componente de

FRAMEWORK desarrollo como librerías y plantillas dependiendo el tipo de
lenguaje de programación

Clases de JAVA que se utilizan para extender sus capacidades

SERVLET de respuesta a los clientes al usar las potencialidades de JAVA

Verbo que se usa para obtener un recurso del servidor

GET
Verbo que se usa para crear un recurso en el servidor
POST
Verbo que se usa para actualizar un recurso en el servidor
PUT
DELETE Verbo que se usa para eliminar un recurso en el servidor

A
algoritmos
Conjunto ordenado de operaciones sistemáticas que permite hacer un cálculo y hallar la solución de un tipo de
problemas, X
anotaciones
Las anotaciones son observaciones, notas, explciaciones u otros tipos de comentarios externos que pueden
adjuntarse a un documento Web o an una parte de un documento., 20
arquitectura
Técnica y estilo con los que se diseña, proyecta y construye, 20
Autenticación
Procedimiento informático que permite asegurar que un usuario de un sitio web u otro servicio similar es auténtico o
quien dice ser, 30

C
certificados
El certificado es un tipo de texto administrativo empleado para constatar un determinado hecho., 25
computación
 12 Seguridad de JAX-RS frente a ataques por inyección de código

Es la disciplina que estudia e investiga las técnicas y dispositivos tecnológicos digitales, 13

conexión
nión que se establece entre dos o más cosas (aparatos, sistemas, lugares, etc.) o personas para que entre ellas haya
una relación o una comunicación, 25
Confidencialidad
Confidencialidad es la propiedad de la información, por la que se garantiza que está accesible únicamente a personal
autorizado, 30
configuración
Forma particular de una cosa, determinada por la disposición de las partes que la componen, 21
criptográfico
Arte y técnica de escribir con procedimientos o claves secretas o de un modo enigmático, de tal forma que lo escrito
solamente sea inteligible para quien sepa descifrarlo, 25

E
evaluación
Atribución o determinación del valor de algo, X

H
herramientas
Conjunto de instrumentos que se utilizan para desempeñar un oficio o un trabajo determinado, 19

I
implementación
Poner en funcionamiento o llevar a cabo una cosa determinada, 23
Internet
Red informática de nivel mundial que utiliza la línea telefónica para transmitir la información, 25

O
OWASP
es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea
inseguro, X

P
parámetros
Los parámetros son medidas descriptivas de toda una población que se utilizan como las entradas para una función
de distribución de probabilidad (PDF) con el fin de generar curvas de distribución., 23
pentest
Es un ataque a un sistema informático con la intención de encontrar las debilidades de seguridad y todo lo que podría
tener acceso a ella, su funcionalidad y datos., 19
protocolo
Conjunto de reglas de formalidad que rigen los actos y ceremonias diplomáticos y oficiales, 20
proxy
Es un ordenador intermedio que se usa en la comunicación de otros dos, 19
pruebas
Seguridad de JAX-RS frente a ataques por inyección de código 13

Acción de probar a alguien o algo para conocer sus cualidades, verificar su eficacia, saber cómo funciona o reacciona,
o qué resultado produce, 19

S
seguridad
Sensación de total confianza que se tiene en algo, X
servidor
Que está al servicio de algo o de alguien, 19
software
Conjunto de programas y rutinas que permiten a la computadora realizar determinadas tareas, 27

T
tecnologías
Conjunto de instrumentos, recursos técnicos o procedimientos empleados en un determinado campo o sector, 23

V
vulnerabilidad
Es algo que esta en contra de una ley o norma, X

W
Web
Conjunto de información que se encuentra en una dirección determinada de internet, 13
 14 Seguridad de JAX-RS frente a ataques por inyección de código

INTRODUCCIÓN
La computación distribuida ha traído consigo avances significativos en el mundo del
software y la comunicación en red, ya que desde la creación y desarrollo del lenguaje de
etiquetado de la Web HTML se vienen generando estándares y tecnologías
subsecuentes, cada una basada en la anterior y reforzando los baches que presentaba su
antecesora, o simplemente tomando lo mejor de cada una para llegar a los grandes
avances de la Web actual[2].
Aunque en un inicio no se pensaba que estas tecnologías llegarían a converger en la
World Wide Web y en la gran cantidad de aplicaciones distribuidas que existen hoy en día
ya se planteaban soluciones a problemas específicos, como por ejemplo que dos
aplicaciones puedan compartir datos y recursos, para esto las primeras técnicas
desarrolladas solucionaban en cierta medida este problema, entre estos se encuentran
CORBA y DCOM, Middleware[3] que permitían comunicar aplicaciones y datos
distribuidos aunque con la limitación de que el lenguaje de desarrollo debe ser el mismo
en ambos nodos, además de que dichos nodos deben estar configurados para soportar
estas tecnologías, algunas de las limitaciones que estos presentaban se solucionaron con
otras tecnologías como RMI de Java, que expone objetos que se pueden manipular de
forma remota, logrando así minimizar tiempos de desarrollo y respuesta al usuario final,
pero aun así no resuelve los problemas de fondo (Condicionamiento a plataforma y a
tecnologías especificas).
Es en la década del 90 cuando se reconocen las grandes ventajas que tiene la World
Wide Web para el desarrollo de la computación distribuida y ubicua[3], es entonces
cuando se idean los Web Services, que no son más que servicios que se pueden
consumir por medio de las tecnologías y estándares de Internet, inicialmente se
establecieron algunas definiciones restrictivas de los servicios Web, entre esas la que
indica que un servicio debe basarse en un documento WSDL (Web Service Definition
Languaje)(Barry & Associates, 2000).
El documento WSDL es la base de la especificación del protocolo de servicios SOAP, que
usa XML para compartir datos entre aplicaciones, esta arquitectura difiere de las
tecnologías mencionadas anteriormente como RMI o CORBA, en que como su nombre lo
indica, estas son tecnologías (desarrolladas e implementadas por una empresa o
Seguridad de JAX-RS frente a ataques por inyección de código 15

persona) por tanto generan restricciones inherentes a los medios y técnicas de desarrollo
utilizados en estas; mientras que SOAP es un protocolo, no enteramente de definición
como HTTP pero si independiente de la tecnología e infraestructura que se utilice para su
implementación[3].
SOAP hace uso de los metadatos para publicar servicios a sus clientes, estos descritos
mediante el lenguaje extensible de marcado XML, que puede ser interpretado
independiente de la plataforma y lenguaje de la aplicación, tiene una estructura definida
por la W3C por medio de la cual se generan, envían y reciben mensajes entre
aplicaciones en la red. Este nuevo estándar trajo consigo una multitud de expectativas
con respecto a la orientación a servicios (Arquitectura SOA) como el logro definitivo del
internet de las cosas y la computación Ubicua, sin embargo estas no fueron satisfechas
en la medida que se esperaba, según conocedores y expertos debido a la complejidad
que presenta su implementación, además de la falta de conocimiento y correcto enfoque
por parte de quienes implementas este tipo de sistemas[4].
Es por esto que en el año 2000, en una tesis doctoral, Roy Fielding propone una nueva e
innovadora forma de implementar servicios Web, la Transferencia de Estado
Representacional REST, que básicamente es usar la arquitectura de la Web para
compartir datos y recursos; aunque REST no es una tecnología ni un protocolo es una
solución efectiva, al ser una arquitectura (que va de la mano con SOA pero no deben
confundirse) es totalmente independiente de cualquier tecnología y plataforma, que
combina las ventajas de la comunicación mediante XML con la simplicidad de las
transacciones HTTP[5].
REST se basa en los estándares de la World Wide Web para generar servicios Web, en el
famoso principio de no reinventar la rueda, según Fielding no debemos buscar métodos
de comunicación y procesamiento de transacciones nuevos, ya que el protocolo HTTP los
tiene completamente definidos; son estos verbos (GET, POST, PUT, DELETE) los que
nos permiten llevar a cabo cualquier procesamiento sobre un recurso. Para REST todo es
un recurso, que puede identificarse y accederse por medio de su URI (Identificador de
recursos uniforme) por tanto estos pueden manipularse por medio de las operaciones
anteriormente mencionadas.
 16 Seguridad de JAX-RS frente a ataques por inyección de código

Al ser REST un estilo arquitectónico no obliga a quienes lo implementen a seguir todos

sus principios al pie de la letra, esto ha dado pie a una definición que acoge los sistemas
basados en estos principios de manera estricta, conocida como RESTful[5].
En este orden de ideas podemos afirmar que un servicio RESTful es la mejor alternativa
para integrar sistemas e implementar la arquitectura SOA, pero no se estaríamos teniendo
en cuenta aspectos fundamentales de requerimientos no funcionales del software como la
seguridad.
Actualmente existen APIs Y Framework de desarrollo que facilitan el desarrollo de
servicios web tanto SOAP como RESTful; Java posee una API de desarrollo para
servicios RESTful llamada JAX-RS que define algunas anotaciones para el desarrollo de
estos servicios, además de implementaciones tanto de ORACLE como de terceros que
facilitan la vida a desarrolladores en todo el mundo, una ampliamente conocida es Jersey,
aunque existen otras como RESTEasy[6].
Independiente de la implementación que se utilice, las definiciones y librerías de JAX-RS
tienen configuraciones de seguridad que protegen los servicios allí implementados de
ataques maliciosos como la inyección de código, aunque no hay certeza sobre los niveles
de seguridad que estos pueden ofrecer, por tanto tampoco podemos tener una
información completa a la hora a la hora de decidirnos por el tipo de servicio que debemos
desarrollar frente a una determinada necesidad.
Es por esto que el presente trabajo estará enfocado en encontrar los factores de
vulnerabilidad que tienen estas librerías y realizar una serie de pruebas de ataque sobre
estos de acuerdo a unos niveles e indicadores definidos al inicio de la investigación
usando como referencia la el modelo del ciclo de vida de software en V, con el fin de
obtener datos reales en cuanto a un requerimiento no funcional fundamental para
cualquier sistema de información e inherente a esto llegar a una certeza de decisión en la
elección de las alternativas de construcción del mismo.
Seguridad de JAX-RS frente a ataques por inyección de código 17

1. GENERALIDADES
Para desarrollar un prototipo que cumpla con el objetivo de este proyecto se deben tener
claros los conceptos que impactarán en él, es por esto que en los siguientes puntos se
abordarán todos los temas referentes a los conceptos introductorios y teóricos, con el fin
de tener un contexto de trabajo amplio y una base sólida para esta investigación. Además
de ser una ayuda al lector que no tenga conocimientos a fondo sobre estos temas.

1.1 ANTECEDENTES
Las pruebas de penetración o “pentest” son ataques a sistemas informáticos con la
intención de encontrar vulnerabilidades de seguridad que puedan ser usadas por entes
internos o externos para tener acceso al sistema y/o afectarlo deliberadamente. Estas han
sido mejoradas a lo largo de los años, ya que la seguridad informática siempre ha sido
uno de los principales objetivos de los gobiernos y organizaciones tecnológicas[7].
En junio de 1965, se celebró una conferencia sobre seguridad informática, organizada por
un contratista del gobierno de [Link]. Durante la conferencia, se encontró que un
empleado había evadido las protecciones de acceso a un importante sistema, los
asistentes pidieron que se realizaran estudios sobre como romper la seguridad en
sistemas informáticos, se puede decir que los participantes de la conferencia realizaron
una de las primeras peticiones formales para usar pentest para el estudio de la
seguridad[8].
Actualmente no solo existen procesos y estándares para realizar pruebas de penetración
sino además herramientas de software que permiten automatizar estos procesos, realizan
ataques en tiempo real y dan la posibilidad de encontrar fallas y vulnerabilidades de
acuerdo a los resultados de dichos ataques. Una herramienta de este tipo es la aplicación
desarrollada por OWASP[1] llamada ZAP por sus siglas en inglés “Zed Attack Proxy”[9].
Es un escáner de código abierto que está desarrollado para ser utilizado tanto por novatos
como por profesionales de seguridad informática, para realizar pruebas de penetración.
Cuando se utiliza como un servidor proxy permite al usuario manipular todo el tráfico que
pasa a través de él, incluyendo el tráfico mediante HTTPS. También puede funcionar en
un modo de 'demonio', que está controlado por medio de una interfaz REST, es
multiplataforma, está escrito en Java y está disponible en los principales sistemas
operativos, incluyendo Microsoft Windows, Linux y Mac OS X[9].

Así como ZAP, existen otras herramientas de penetración o “pentesting tools” que varían
en funcionalidades y objetivos, desde ataques específicos hasta control de flujo de datos
en las redes analizadas, algunas de estas son: SqlMap[10], AMNESIA[11] y SQLrand[12].
 18 Seguridad de JAX-RS frente a ataques por inyección de código

1.2 PLANTEAMIENTO DEL PROBLEMA

Desde el inicio de la Web, el uso del estilo de arquitectura REST se encuentra implícita en
sus bases tecnológicas, ya que sin el protocolo HTTP y sin el URI, no podría existir tal y
como la conocemos ahora[4]. Desde el la presentación del trabajo de Roy Fielding[5] se
han conocido las grandes ventajas del uso de esta arquitectura en los servicios web, y
esto ha generado un uso indiscriminado y sin seguir unos mínimos estándares de
implementación.
De acuerdo a lo indicado anteriormente, podemos afirmar que la información en la web
cuenta con un alto grado de vulnerabilidad, ya que los ataques a sistemas de información
utilizados frecuentemente se basan en el aprovechamiento de las debilidades en la
implementación de estos, por ejemplo los ataques por inyección que utilizan las URI para
acceder a los sistemas de información[13].

1.2.1 Descripción del Problema

Actualmente existen herramientas de desarrollo que permiten crear servicios Web,
proporcionando soporte de acuerdo a la arquitectura Representational State Transfer –
REST, como lo es la API de java JAX-RS. Los proveedores de esta tecnología, indican
que esta API cuenta con alto grado de seguridad, debido a características propias de la
API como las anotaciones de seguridad (@PermitAll, @DenyAll, @RolesAllowed) o el uso
de SSL[14].A pesar de su afirmación, también es susceptible de recibir ataques, debido a
su incorrecta implementación.

1.2.2 Formulación del Problema

¿Pueden los Web Services REST implementados en JAX-RS soportar diferentes ataques
por inyección de código?
Seguridad de JAX-RS frente a ataques por inyección de código 19

1.3 OBJETIVOS

1.3.1 Objetivo General

Desarrollar un prototipo que implemente los tipos de ataques por inyección de código
sobre libreras JAX-RS

1.3.2 Objetivos Específicos

 Seleccionar los algoritmos de ataque que se van a implementar sobre el prototipo.

 Diseñar e implementar el prototipo y sus escenarios de aplicación.
 Evaluar el nivel de vulnerabilidad de las librerías JAX-RS.

1.4 JUSTIFICACIÓN

Es importante destacar el impacto económico y social que conllevan los ataques

informáticos, desde la perdida de información confidencial de entidades financieras, hasta
la caída de servicios de gran demanda[10]. En la actualidad gran cantidad de estos
servicios hacen uso de tecnologías relativamente nuevas en la Web, como son los
servicios RESTful, algunos de estos son ofrecidos por framework de desarrollo como es el
caso de JAX-RS, el cual provee facilidades al programador para implementar estos
servicios por medio de anotaciones estándar definidas en la especificación, dejando a
este únicamente el trabajo de implementación del servicio, sin preocuparse por los
detalles de la configuración[14].

Las preguntas que se pueden realizar entonces son ¿proveen estos framework utilidades
de seguridad para los servicios RESTful? y ¿Qué tan vulnerables son los servicios
desarrollados con estos framework? Para responder a estas preguntas es importante
realizar un análisis de seguridad sobre algunas de las implementaciones que son usadas
actualmente en la industria, con el fin de encontrar las vulnerabilidades que estos puedan
tener.

Con esta investigación se buscan resultados útiles no solo para la industria sino también
para comunidad académica y científica, puesto que en este punto del desarrollo
 20 Seguridad de JAX-RS frente a ataques por inyección de código

tecnológico y el auge de la información, se exigen sistemas seguros y eficientes, que

permitan administrar la información y acceder a esta de forma segura.

1.5 DELIMITACIÓN

1.5.1 Espacio
El prototipo desarrollado puede ser usado en cualquier servicio RESTful desarrollado en
alguna de las cuatro implementaciones de JAX-RS definidas en este proyecto.

1.5.2 Tiempo
La entrega final del prototipo y del documento del proyecto que se definió es el día lunes
24 de Octubre del 2016, la cual contará con los elementos descritos en el siguiente punto.

1.5.3 Contenido
El proyecto está conformado por una aplicación prototipo denominada PAIC en
funcionamiento, los servicios RESTful de prueba, desarrollados en las cuatro
implementaciones definidas y el documento con las especificaciones tanto del prototipo
como de las técnicas de ataque y los resultados obtenidos.

1.5.4 Alcance
Este proyecto define el principio y funcionamiento del estilo de arquitectura REST. En este
caso el proyecto se centra en la implementación de algoritmos de inyección de código,
para demostrar la confiabilidad, fiabilidad y vulnerabilidad que presenta la API JAX-RS,
esto incluye:

 Realizar implementación del prototipo a librerías como Apache CXF, Jersey,

RESTeasy y Restlet.
 Generar análisis, estadísticas e informes, sobre cada implementación realizada a
cada una de las librerías descritas anteriormente.
 Identificar el nivel de vulnerabilidad que presenta JAX-RS sobre las
implementaciones descritas anteriormente.
Seguridad de JAX-RS frente a ataques por inyección de código 21

1.6 MARCO REFERENCIAL

1.6.1 Marco teórico

[Link] Servicios RESTFUL en Java

Actualmente existen diferentes tecnologías que facilitan el desarrollo, implementación y
mantenimiento de servicios RESTful, en el caso de Microsoft implementa una Web API
por medio del .NET Framework MVC para construir servicios REST, estos pueden
implementarse como parte de una aplicación Web o ser llamados desde un cliente
HTML[15].

JAX-RS

Es una API del lenguaje Java que proporciona soporte para la creación de servicios Web
basados en el estilo arquitectónico REST [16]. Esta usa anotaciones para simplificar el
despliegue de los clientes, estas ayudan a mapear una clase recurso (POJO) como un
recurso en la Web, algunas de estas son:

 @Path: especifica la ruta de acceso para una clase recurso o método.

 @GET, @PUT, @POST, @DELETE y @HEAD: especifican el tipo de solicitud
HTTP de un recurso.
 @Produces: especifica los tipos de medios MIME de respuesta.
 @Consumes: especifica los tipos de medios de petición aceptados.
 @QueryParam: enlaza el parámetro al valor de un parámetro de consulta HTTP.
 @FormParam: enlaza el parámetro a un valor de formulario.
 @PathParam: enlaza el parámetro a un segmento de ruta.

Además de otras anotaciones para los parámetros de los métodos, para extraer
información de la solicitud [14].

JAX-RS es una especificación de la API, de acuerdo a esto existen múltiples

implementaciones de esta, entre las que se incluyen las siguientes [6]:

 Apache CXF, un framework para Web services de código abierto.

 Jersey, la implementación de referencia de Oracle.
 RESTeasy, implementación de JBoss.
 Restlet, creado por Jerome Louvel, un pionero en frameworks de REST.
 Apache Wink, proyecto de Apache Software Foundation Incubator, el módulo del
servidor implementa JAX-RS.
 22 Seguridad de JAX-RS frente a ataques por inyección de código

Jersey: Jersey es la implementación de referencia de calidad de producción de Oracle

para JSR 311: JAX-RS: The Java API for RESTful Web Services. Jersey implementa
soporte para las anotaciones definidas en la JSR-311, lo que facilita a los desarrolladores
crear servicios web RESTful con Java y la JVM. Jersey también añade características
adicionales no especificadas por la JSR [14].

Apache CXF: Es un marco de servicios web de código abierto fácil de usar, estructurado
por un modelo de programación basado en estándares para el desarrollo de servicios
web. Estos servicios web pueden ser implementados por protocolos como XML,JSON y
HTTP [17].

RESTeasy: Es un proyecto que proporciona varios frameworks para soportar la

construcción de aplicaciones y servicios web REST. Se trata de un proyecto open source
respaldado por JBoss que es una implementación completa y certificada del JSR 311 [18].

Restlet: Es una API que nos permite implementar los Servlets de Java siguiendo el estilo
REST. La principal ventaja de Restlets es que permite programar Servicios Web de
carácter general, no está diseñado para un Servicio en particular ejemplo como ocurre
con las API de Amazon o eBay [19].

Apache Wink: Es un simple marco para la construcción de servicios web RESTful. Se

compone de un módulo de servidor y un módulo de cliente para desarrollar y consumir
servicios web RESTful [20].

[Link] Implementaciones de JAX-RS

A continuación se definen algunas implementaciones de JAX-RS, así como sus
principales características:

RESTEasy: Es una aplicación JAX-RS que surge de un proyecto de JBoss que

proporciona diversos marcos para ayudar a construir Servicios Web RESTful y
aplicaciones Java REST, esta implementación puede ejecutarse en cualquier contenedor
de Servlets[18].

Restlet: Es un marco de referencia que lleva el concepto de servlet para generar servicios
web. Restlet hace simple el desarrollo de web services[6].

Jersey: Es un marco de referencia que ofrece su propia API la cual extienden el conjunto
de herramientas JAX-RS con las características y utilidades adicionales para simplificar
aún más el servicio REST y desarrollo de clientes[14].

Apache CXF: Es un marco de referencia de servicios de Software Libre. CXF ayuda a

construir y desarrollar servicios utilizando JAX-WS como API de programación. Estos
Seguridad de JAX-RS frente a ataques por inyección de código 23

servicios pueden hablar una gran variedad de protocolos como SOAP, XML/HTTP, HTTP
RESTful, o CORBA, y pueden trabajar sobre transportes como HTTP, JMS o JBI[14].

[Link] Seguridad de JAX-RS

Seguridad de JAX-RS utilizando SSL

SSL es un protocolo criptográfico para comunicaciones seguras por una red, comúnmente
Internet, se basa en el intercambio de registros, estos poseen un campo que especifica el
protocolo que se está usando; cuando se inicia la conexión el cliente envía un mensaje
ClientHello especificando la versión del protocolo SSL, además puede incluir el
identificador de la sesión. Después, recibe un registro ServerHello, en el que el servidor
elige los parámetros de conexión. Cuando los parámetros de la conexión son conocidos,
cliente y servidor ellos intercambian certificados dependiendo de las claves públicas de
cifrado seleccionadas. Cliente y servidor negocian una clave secreta simétrica cifrando
una clave secreta con una clave pública que es descifrada con la clave privada de cada
uno (Ver Ilustración 1: Cifrado SSL). Para el intercambio de claves existen una serie de
algoritmos, entre estos se encuentra RSA [21].

RSA es un algoritmo asimétrico cifrado de bloques, que utiliza una clave pública, la cual
se distribuye (en forma autenticada preferentemente), y otra privada, la cual es guardada
en secreto por su propietario [21].

Ilustración 1: Cifrado SSL

Protección de recursos JAX-RS utilizando anotaciones

Utilizando las mismas herramientas que se utiliza para crear servicios REST se realizan
definiciones y se añaden restricciones de seguridad. Las restricciones se configuran en el
descriptor de despliegue Web[14].

Un ejemplo de definición de seguridad es la autenticación de usuario cuando se invoque a

recursos REST, ya que debe de cumplir con los siguientes requisitos
 24 Seguridad de JAX-RS frente a ataques por inyección de código

 Autenticación básica HTTP

 Control de autorización sobre recursos REST tal como definen las URI de los
recursos
 Uso de SSL para transporte cuando se invocan recursos REST
 Uso programático del objeto SecurityContext para determinar la identidad y los
roles del usuario

Los recursos se protegen a través de JAX-RS API Java para servicios Web RESTful
utilizando anotaciones que especifiquen valores de seguridad. Se Utilizan las siguientes
anotaciones para añadir autorización a los recursos de la aplicación JAX-RS [22]:

 @PermitAll: especifica que se permite a todos los roles de seguridad acceder a los
recursos JAX-RS
 @DenyAll: especifica que no se permite a ningún rol de seguridad acceder a los
recursos JAX-RS
 @RolesAllowed: especifica los roles de seguridad a los que se permite acceder a
los recursos JAX-RS
Elegir anotaciones a nivel de clase o a nivel de método. Las anotaciones en el nivel de
método tienen prioridad sobre las anotaciones en el nivel de clase.

En el siguiente fragmento de código, se observa que a nivel de clase el recurso se

accede desde cualquier rol, mientras que a nivel de método updateList() es accesible solo
desde el rol de Manager, teniendo este prioridad sobre la restricción de clase (ver Código
fuente N° 1: Anotaciones de seguridad soportadas por JAX-RS).

Código fuente N° 1: Anotaciones de seguridad soportadas por JAX-RS

Seguridad de JAX-RS frente a ataques por inyección de código 25

Las anotaciones de seguridad se excluyen mutuamente

Significa que cada recurso sólo se rige como máximo por una de las anotaciones de
seguridad. El ejemplo siguiente no es válido porque se especifica tanto @PermitAll como
@RolesAllowed. De acuerdo al Código fuente N° 2: Exclusión de Anotaciones de
seguridad en JAX-RS, la anotación @RolesAllowed tiene prioridad y la anotación
@PermitAll se ignora. Tal como si se utiliza tanto la anotación @RolesAllowed como la
anotación @DenyAll, la anotación @DenyAll tiene prioridad.

Si se utiliza tanto la anotación @PermitAll como la anotación @DenyAll en el nivel de

método o en el nivel de clase, la anotación @DenyAll tiene prioridad. Si se utilizan las
anotaciones @PermitAll, @DenyAll y @RolesAllowed en el nivel de método o de clase, la
anotación @DenyAll tiene prioridad sobre @RolesAllowed y @PermitAll. El orden de
prioridad de estas anotaciones es el siguiente [22]:

1. @DenyAll
2. @RolesAllowed
3. @PermitAll

Código fuente N° 2: Exclusión de Anotaciones de seguridad en JAX-RS

1.6.2 Marco Conceptual

[Link]. ¿Qué es REST?

Representational State Transfer por sus siglas en inglés es un estilo arquitectónico de
software que se basa en los estándares del protocolo HTTP para manipular datos y
operaciones, en distintos formatos XML, JSON a diferencia de SOAP que está basado en
 26 Seguridad de JAX-RS frente a ataques por inyección de código

el uso exclusivo de XML. Además este enfoque es libre de abstracciones de protocolos de

intercambio de mensajes, como es el caso de SOAP[3].

[Link]. Principios de REST

 Orientación a Recursos y Direccionamiento: en REST todo es un recurso, que puede
ser accedido por medio de una URI, desde una página HTML hasta un servicio de
aplicación. Este enfoque es el que siempre ha usado la World Wide Web - WWW, es
imprescindible para su funcionamiento y es imposible imaginarla como la conocemos
sin REST [4].
 Una Interface uniforme: para poder compartir datos, los sistemas necesitan mantener
una interface común y unas operaciones sobre los datos bien definidas, en el caso
de SOAP las interfaces se definen mediante los metadatos en XML, donde se
especifican los parámetros y métodos del servicio. Para el caso de REST se utiliza
una interfaz ampliamente conocida y usada desde hace más de dos décadas en todo
el mundo, se trata del protocolo de comunicaciones HTTP, este define unos verbos
(GET, POST, PUT, DELETE) que se pueden usar como las operaciones sobre los
datos que necesita el servicio Web, esta importancia del protocolo HTTP fue
detallada en el trabajo doctoral de Roy Fielding y se estableció como interfaz común
para las comunicaciones en REST [4].
 Representaciones y tipos de medios: la transferencia de estado representacional se
basa en que no existen sesiones de usuario del servicio en el servidor, por lo tanto
las solicitudes se responden de manera independiente del estado del cliente, así por
ejemplo es que una gran tienda virtual puede distribuir y procesas todas sus
solicitudes sin problemas de concurrencia o estado de los pedidos; esto se logra
gracias a la URI que puede identificar el estado del pedido en un momento dado.
Además de esto también es necesaria la estandarización de los medios y formatos a
usar en las comunicaciones, actualmente los navegadores pueden identificar una
amplia gama de formatos de archivos y cómo manejar la interacción de estos con el
usuario final, en definitiva “Sin transferencia de estado representacional y tipos de
medios estandarizados, no podría existir la actual World Wide Web.” [4]
 La Condición de Hypermedia: el acceso a los recursos es fundamental en cualquier
servicio RESTful, es por esto que todos deben estar identificados mediante una URI
y esta debe poder ser accedida desde otro nodo de la red por medio de un enlace o
link, que desencadene una operación HTTP, ya sea GET o POST, implementada por
una etiqueta <a> o una <form>; cabe anotar que la operación a utilizar se basa en el
elemento que realice en enlace y no en la representación del recurso en el servidor
[4] ejemplo un menú de navegación de un almacén de cadena el cual tenga el cual
para navegar cuenta con etiquetas <a>, estas contendrán dentro de su atributo href
el recurso al cual quieran acceder ya sea vehículos, comida, higiene y demás .
Seguridad de JAX-RS frente a ataques por inyección de código 27

¿Y QUE ES RESTFUL?

La Web está basada en varios de los principios de REST, por tanto se ha llegado a la
idea, en la comunidad de desarrollo de REST que se debe hacer una distinción de todos
los recursos basados en HTTP-XML de los servicios REST, dándoles a los últimos el
nombre RESTful, es decir son todos aquellos que cumplen fielmente los principios y
estándares presentados por Fielding, en conclusión no es más que un concepto que
cobija a todos los servicios Web que siguen al pie de la letra los fundamentos de la
arquitectura REST [23].

REST expone URIs con forma de directorios

Las URI deben mantener la estructura de los recursos que representa, generalmente en
una estructura de árbol, que es la que usan los directorios de los Sistemas Operativos, así
es posible tener raíces de las cuales se desprendan los recursos como hojas del árbol, un
ejemplo bastante familiar puede ser el path del explorador de archivos de Windows, en el
que podemos recorrer las carpetas y ver la estructura descendiente que estas manejan.
Las URI de los servicios web REST deben ser intuitivas, hasta el punto de que sean
fáciles de adivinar. Podemos ver una URI como una interfaz auto-descriptiva que necesita
de muy poca o ninguna referencia para que un desarrollador pueda comprender a lo que
apunta, y a los recursos derivados relacionados [15].

REST transfiere XML y JSON

La representación de un recurso se puede ver como una foto del recurso en el momento
que se solicita dicha representación, refleja el valor actual del recurso. Este valor se
puede representar por medio de etiquetas XML o por medio de cadenas atributo-valor en
formato JSON, esto es básicamente lo que el servicio REST le comunica al cliente.

Esto permite que el servicio sea utilizado por distintos clientes escritos en diferentes
lenguajes, corriendo en distintas plataformas y equipos. El uso de los tipos MIME y del
encabezado HTTP Accept es un mecanismo conocido como negociación de contenido, el
cual le permite a los clientes elegir qué formato de datos puedan leer, y por tanto
mantiene bajo acoplamiento de datos entre el servicio y las aplicaciones que lo consumen
[15].

[Link]. Contexto de seguridad

Al momento de crear sistemas informáticos, la seguridad debe ser un objetivo primario
desde su inicio. En la mayoría de casos, los sistemas que no tuvieron dicho objetivo ya en
 28 Seguridad de JAX-RS frente a ataques por inyección de código

la etapa de diseño, deben luego pasar por reestructuración y diversos cambios,

posiblemente con un importante costo en recursos. Los errores de código se consideran
vulnerabilidades. Otras fuentes de vulnerabilidades que pueden derivar en huecos de
seguridad son los errores conceptuales en protocolos e interacciones[24], susceptibilidad
a la falta de autenticación, autorización o el chequeo de integridad.

La seguridad de la información de una solicitud está disponible mediante la inyección de

un JAX-RS SecurityContext utilizando @Context anotación[25]. La instancia de contexto
de seguridad inyectado proporciona el equivalente de la funcionalidad disponible en
HttpServletRequest API[25]. El contexto de seguridad inyectado depende de la
implementación real de aplicaciones Jersey. Por ejemplo, para una aplicación Jersey
desplegado en un contenedor Servlet, la Jersey SecurityContext[25] encapsulará
información de un contexto de seguridad recuperada de la solicitud Servlet.

Los servicios REST se basan en la manipulación de recursos. Los recursos pueden

contener datos actualizados de forma estática o dinámica. Identificando los recursos en la
aplicación, puede hacer que el servicio resulte más útil y más fácil de desarrollar. Poder
exponer estas APIs no solo de forma interna sino al exterior, puede generar problemas de
seguridad. La inyección de código es el ataque frecuentemente usado

La forma básica de este defecto consiste en la inyección de los datos de control de plano
en el plano de datos con el fin de alterar el flujo de control del proceso.

Consecuencias:

Confidencialidad: Muchos ataques de inyección implica la divulgación de información

importante tanto en términos de sensibilidad de los datos y la utilidad de una mayor
explotación

Autenticación: En algunos casos, el código inyectable controla la autenticación; esto

puede conducir a la vulnerabilidad remota

Control de acceso: Los ataques de inyección se caracterizan por la capacidad de cambiar

de manera significativa el flujo de un proceso dado, y en algunos casos, a la ejecución de
código arbitrario.

Integridad: los ataques de inyección de datos conducen a la pérdida de integridad de los

datos en casi todos los casos como los datos de plano de control inyectados siempre es
incidental para recordar o escribir datos.

Responsabilidad: A menudo las acciones realizadas por el código de control son

inyectados no talado.
Seguridad de JAX-RS frente a ataques por inyección de código 29

[Link]. Algoritmos de ataque

Aquí se definen y se explican de forma detallada las técnicas de ataques por inyección de
código que se ejecutarán en la evaluación de seguridad de servicios Web implementados
en JAX-RS, los cuales se seleccionaron con base en una serie de criterios como la
efectividad, facilidad y amplia documentación[26].

1. Inyección XPATH:

Los ataques de inyección XPATH ocurren cuando una aplicación Web utiliza la
información que ingresa el usuario para construir una consulta XPATH para datos XML.
Un atacante puede descubrir cómo están conformados los datos XML de una aplicación
Web con el envío de sentencias formadas para tal fin, puede llegar a acceder a todos los
datos de la misma. En algunos casos el atacante puede aumentar los privilegios en la
aplicación Web si los datos se usan para la autenticación, como un archivo de usuario
basado en XML[27].

2. Inyección SQL:

Una inyección SQL se basa en insertar, como su nombre lo indica, código SQL dentro del
código ya programado en la aplicación Web, con el fin de modificar el funcionamiento
normal de esta y lograr que se ejecute en la base de datos el fragmento de código
incrustado. Normalmente este tipo de ataque es realizado con sencillas técnicas como
escapar caracteres y generando condiciones que siempre son verdaderas[28].

3. Inyección LDAP:

LDAP se refiere a Lightweight Directory Access Protocol o en español Protocolo Ligero de

Acceso a Directorio, es el encargado de las listas de control de acceso de un dominio o
red determinado. Se este tipo de inyección se ataca al sistema de validación de usuarios
para intentar cambiar los permisos de estos y hasta crear nuevos usuarios con los cuales
acceder luego a otras zonas más sensibles del dominio. Un ejemplo de acceso al sistema
para llevar a cabo estos ataques es un formulario de búsqueda de usuarios solicite el
login o identificador de usuario para mostrar algún dato de este, al igual que en la
inyección SQL se toma el contenido del campo nombre sin desinfectarlo y se introduce en
una consulta[29].

4. Inyección de comandos

Comand Injection en inglés es un tipo de ataque en el que se logra insertar comandos de

sistema mediante la aplicación que posee los permisos para tal fin. Estos comandos se
ejecutan al mismo nivel de privilegios que la aplicación y proveen al atacante una
funcionalidad similar a la de una Shell de Sistema Operativo[30]. En Java, existe un
método llamado [Link] que es usado para invocar a un nuevo proceso, la
 30 Seguridad de JAX-RS frente a ataques por inyección de código

inyección de comandos es posible si el proceso creado con el método [Link] es

una instancia del Shell como [Link], [Link] o /bin/sh ([Link], 2016).

5. Inyección JavaScript

Estas inyecciones son procesos en los cuales se pueden insertar y usar los propios
códigos JavaScript en una aplicación Web, ya sea introduciendo el código en la barra de
direcciones, o encontrando la vulnerabilidad XSS en la aplicación Web. Mediante el
lenguaje Javascript se pueden dar órdenes a una aplicación Web sin que el administrador
lo autorice para provocar daños en la aplicación, acceder a información confidencial o
tomar el control total de este[31]. Es importante aclarar que mediante ataques por
inyección de JavaScript se puede realizar un tipo de ataque derivado de este conocido
como DOM injection, o inyección de etiquetas HTML con el fin de modificar la estructura
del mismo.

6. Inyección SMTP

El Simple Mail Transfer Protocol o protocolo para transferencia simple de correo, es como
su nombre lo indica un protocolo de red utilizado para el intercambio de mensajes de
correo electrónico entre dispositivos, fue definido en el RFC 2821 y es un estándar oficial
de Internet. Una sesión SMTP consiste en comandos enviados por un cliente SMTP y las
respuestas correspondientes del SMTP del servidor para que la sesión se abra y se
intercambian los parámetros de la sesión, una sesión puede incluir cero o más
transacciones SMTP. Una transacción de SMTP se compone de tres secuencias de
comando/respuesta: MAIL, RCPT, DATA [32]. Es por medio de estos comandos que se
logra realizar el ataque, un ejemplo de inyección de comandos SMTP es:

% 0aDATA% 0afoo% 0a% 2e% 0aMAIL + DE: +% 0aRCPT + A: +% 0aDATA% 0aFrom:

+% 0aTo: +% 0AS BJETO: + prueba 0afoo% 0a% 0a% 2e% [33]

7. Inyección HQL

Hibernate Query Language por sus siglas en inglés es una derivación de SQL que
implementa el Framework ORM Hibernate para la capa de persistencia en aplicaciones
Java, si una aplicación confía ciegamente en el framework utilizado puede resultar en
consultas que aún son vulnerables. Un pequeño ejemplo de un ataque de este tipo lo
podemos ver en el siguiente código[1]:

Query HQLQuery = [Link] (“FROM accounts WHERE custID='“ +

[Link] ("id") + "'");

8. Inyección JSON

Al igual que con los ataques por inyección XPATH, los cuales inyectan código XML para
acceder a recursos de datos, también se pueden realizar inyecciones de código en
Seguridad de JAX-RS frente a ataques por inyección de código 31

formato JSON JavaScript Object Notation, con el fin de vulnerar aplicaciones que usan
tanto intercambio de mensajes como recursos de datos basados en este estándar. Un
ejemplo de un recurso de datos implementado en formato JSON es el motor de bases de
datos no relacionales MongoBD, el cual se basa en colecciones de documentos en este
formato[26].

[Link]. Tecnologías Web

HTML: Es un lenguaje que pertenece a la familia de los "lenguajes de marcado" y es
utilizado para la elaboración de páginas web. El estándar HTML lo define la W3C (World
Wide Web Consortium) y actualmente HTML se encuentra en su versión HTML5. El
lenguaje HTML sirve para describir la estructura básica de una página y organizar la
forma en que se mostrará su contenido [34]. En la Código fuente N° 16: Estructura HTML
se define la estructura del formulario de login y en la Código fuente N° 17: Estructura
HTML se define la estructura del formulario de comunicación entre Host.

JavaScript: Es un lenguaje de programación que surgió por la necesidad de ampliar las

posibilidades del HTML para así desarrollas páginas Web dinámicas, este es un lenguaje
interpretado por el navegador Web mientras es cargada la página, es un lenguaje
orientado a objetos que en la mayoría de las instrucciones que se emplean en los
programas, en realidad son llamadas a propiedades y métodos de objetos del navegador
[34].

JavaScript se puede implementar tanto internamente en la página HTML, como también

en un archivo externo. En nuestro caso usaremos ambos, el archivo externo usado es una
librería reconocida con el nombre de JQuery. Esta es una solución de buenas prácticas y
usada comúnmente en el mundo académico y empresarial, para más información
remítase a su sitio Web [Link]

En la capa de presentación se puede encontrar código JavaScript utilizado en las páginas

HTML en complemento con una técnica de programación denominada como AJAX que en
pocas palabras es una técnica usada para generar peticiones sin recargar la página y
generar contenido dinámico e interactivo, el algoritmo del código fuente N° 19 toma los
valores de las entradas de texto de los campos usuario y contraseña para generar una
petición al Web Service de autenticación, el cual retornara falso o verdadero según las
entradas generadas.

Con esta respuesta se determina si es falso permanecer en la página de login y si es

verdadero permitir el ingreso al cPanel. El código fuente N° 20 toma el host de entrada de
una caja de texto para realizar la petición a un Web Service cuya respuesta será una
prueba de comunicación a través del comando PING para definir si existe la comunicación
entre dos Host
 32 Seguridad de JAX-RS frente a ataques por inyección de código

CSS: Es un lenguaje de Diseño Web que permite crear una página web más interactiva y
más exacta para la visualización del usuario final, CSS es el acrónimo de “Cascading
Style Sheets” que significa Hojas de estilo en cascada, este lenguaje puede estar definido
dentro de la página HTML pero para buenas practicas es mejor implementarlo en un
archivo externo [34]. En la Código fuente N° 18: Estructura CSS se podrá encontrar una
porción del código que da el estilo a la página HTML.

1.7 METODOLOGÍA
Esta es la sección del documento que detalla el proceso mediante el cual se realizará la
implementación del sistema y las pruebas de seguridad que son claves para llegar a las
conclusiones objetivo de este proyecto.

1.7.1 Tipo de Estudio

En un principio es un estudio de tipo exploratorio, que tiene como objetivo la formulación
del problema, que en este caso es encontrar vulnerabilidades iniciales en el sistema, para
posibilitar una investigación más precisa y el desarrollo de un proceso de ataque que
logre vulnerar dicho sistema, esto permite desarrollar ataques de primer y segundo grado.
En esta segunda fase se convierte en un estudio de tipo descriptivo, mediante el cual se
presentarán y describirán las vulnerabilidades identificadas, de acuerdo a los indicadores
definidos para tal fin. Como resultado de este se obtiene una aplicación Web que
implemente los ataques definidos en la metodología sobre servicios Web RESTful en
JAX-RS.
Seguridad de JAX-RS frente a ataques por inyección de código 33

2. SELECCIÓN DE ALGORITMOS
La selección de los algoritmos que finalmente se desarrollarán en la aplicación Web se
realizará de acuerdo a cuatro criterios que son claves para determinar la factibilidad de
implementación. La metodología para la selección de los algoritmos que se
implementarán está basada en un método cuantitativo, en el que se asignará un peso
numérico de 1 a 25, donde 1 representa el menor y 25 el mayor peso, por último se
sumará los pesos de cada fila y se seleccionarán los 3 algoritmos con mayor peso y por
tanto más probables de ser implementados.

Los criterios de selección que se definieron son:

 Factibilidad de éxito
 Documentación
 Posicionamiento OWASP
 Probabilidad de ser explotado según la CWE

Estos criterios fueron seleccionados con base en las necesidades puntuales de este
proyecto, que son el desarrollo del prototipo de ataques y la ejecución en cuatro librerías
de JAX-RS, especificación usada en el desarrollo de servicios RESTful en aplicaciones
Java. La magnitud de los pesos se define a continuación para cada uno de los criterios en
particular.

2.1. FACTIBILIDAD DE ÉXITO

El prototipo que se desarrollará en este proyecto está enfocado en atacar servicios Web
implementados en JAX-RS, especificación de ORACLE para servicios RESTful en Java,
por tanto las aplicaciones objetivo de los ataques a realizar en este proyecto deben estar
implementadas en este lenguaje. Es por esta razón que los algoritmos seleccionados
deben ser factibles de implementarse sobre tecnologías basadas en el lenguaje Java, las
cuales ofrecen componentes de API y Framework que eliminan o mitigan algunas de las
vulnerabilidades existentes como es el caso de los ataques por inyección SQL por medio
del uso de ORM en el caso de JPA [35].

Para definir los pesos que tendrán los algoritmos de acuerdo a este criterio se tendrán en
cuenta la cantidad de mecanismos de protección que se definen para cada uno de estos
en las secciones de mitigación que ofrece la CWE para cada vulnerabilidad, esta
información está disponible en su sitio oficial y es fuente primaria de información de
prevención de ataques en empresas que manejan información confidencial importante
como EFT. Esto indica que algunos algoritmos de ataque tienen más técnicas de defensa
 34 Seguridad de JAX-RS frente a ataques por inyección de código

en su contra y por tanto son menos factibles de ser exitosos que otros que tengan pocas o
ninguna.

De acuerdo a este método, se asignará un valor de 25 al algoritmo que cuente con menor
número de técnicas de mitigación en la sección de la CWE en la que se indican estas,
siendo este el que tenga el peso más alto, posteriormente se restarán 3 puntos por cada
técnica de defensa que supere este número inicial, la fórmula de selección es la siguiente:

ni = Menor número de técnicas de mitigación.

na = Número de técnicas de mitigación del algoritmo actual.
n =. na – ni
P = Peso del algoritmo = 25 – (nx3)
Tabla 1: Selección según criterio de factibilidad de éxito

N° de técnicas de
Técnica de ataque Peso
mitigación según la CWE
Inyección XPATH 4 16
Inyección de comandos SO 5 13
Inyección SQL 8 4
Inyección Script 5 13
Inyección LDAP 2 22
Inyección SMTP 1 25
Inyección HQL 1 25
Inyección JSON 1 25

2.2. DOCUMENTACIÓN
Es de vital importancia contar con la información necesaria para implementar los
algoritmos de ataque en el prototipo, ya que estas técnicas han sido utilizadas por alguien
más y no es objetivo de este proyecto desarrollar una nueva técnica sino implementar una
existente, por tanto se definió este criterio de acuerdo a una recolección y análisis de
información indexada sobre dichas implementaciones.

La asignación de los valores cuantitativos a las técnicas de ataque en este criterio se

realizará de acuerdo a la cantidad de documentos que se encontraron en 3 fuentes de
información indexada, estas son: Elsevier - Applied Computing and Informatics, IEEE
Electronic Library (IEL) y Association for Computing Machinery (ACM). A continuación
veremos la lista de las técnicas de ataque y la cantidad de documentos indexados del
tema que se hallaron en 4 horas de búsqueda, 30 minutos por cada uno. Para más
detalles del proceso de búsqueda de documentos ver el Anexo 1. Proceso de recolección
Seguridad de JAX-RS frente a ataques por inyección de código 35

de documentos. En la Tabla 2: Resumen de resultados de la búsqueda de documentos,

se observa un resumen del proceso mencionado.

Tabla 2: Resumen de resultados de la búsqueda de documentos

N° N°
N° Docs N°
Algoritmo Docs Docs
ELSEVIER Total
IEEE ACM
Inyección SQL 14 13 3 30
Inyección XPATH 10 5 0 15
Inyección de comandos SO 10 6 0 16
Inyección Script 9 8 3 20
Inyección LDAP 3 1 0 4
Inyección HQL 0 0 0 0
Inyección JSON 1 0 0 1
Inyección SMTP 0 1 0 1

Gráfica N° 1: Resumen de resultados de la búsqueda de documentos

14
12
10
8
6
4
2
0

N° Docs IEEE N° Docs ACM N° Docs ELSEVIER

Como punto de partida, se asignará un valor de 25 para el algoritmo con mayor cantidad
de documentos indexados encontrados, dicha cantidad será el 100% correspondiente a
esos 25 puntos, a los demás se les asignará un porcentaje sobre ese número de
documentos, de acuerdo la cantidad que se encuentren de cada uno de ellos. Por ejemplo
si de un algoritmo se encuentran 100 documentos y ese es el mayor número, a este le
corresponderá el 100%, otro algoritmo del que se encuentren 70 documentos le
 36 Seguridad de JAX-RS frente a ataques por inyección de código

corresponderá el 70%, al primero se le asigna un peso de 25 y al segundo se le asigna un

peso entero aproximado que corresponda al 70% de los 25 puntos (en este caso 17.5 que
se aproxima a 18):

ni = Mayor número de documentos encontrados por cada algoritmo.

na = Número de documentos encontrados del algoritmo actual.
pct =. na / ni
P = Peso del algoritmo = 25 x pct
Tabla 3: Selección según criterio de documentación

N°
Técnica de ataque Porcentaje Peso
Documentos
Inyección SQL 30 100% 25
Inyección XPATH 15 50% 13
Inyección de comandos SO 16 53% 13
Inyección Script 20 67% 17
Inyección LDAP 4 13% 3
Inyección HQL 0 0% 0
Inyección JSON 1 3% 1
Inyección SMTP 1 3% 1

2.3. POSICIONAMIENTO OWASP

De acuerdo a los informes Top10 de la OWASP y el Top 25 de la CWE Common
Weakness Enumeration se establece un punto de referencia en cuanto al uso de
diferentes tipos de ataques por parte de entes malintencionados con el fin de vulnerar
aplicaciones. Estos informes además de alertar a los desarrolladores sobre las
vulnerabilidades de sus aplicaciones también sirven como referencia para entender el
modo de operación de los atacantes[36]. Por esto es importante que los ataques que se
simulen sobre JAX-RS estén acordes a la realidad actual.

De igual forma que la selección del algoritmo frente al criterio de factibilidad de éxito, se
asignará el valor de 25 a la técnica que ocupe el primer lugar en el posicionamiento de
OWASP y se restarán 3 a la siguiente hasta la última posición:

ni = Posición más alta en el ranking.

na = Posición en el ranking del algoritmo actual.
n =. na – ni
P = Peso del algoritmo = 25 – (nx3)
Seguridad de JAX-RS frente a ataques por inyección de código 37

Tabla 4: Selección según criterio de posicionamiento en OWASP

Técnica de ataque Posición Peso

Inyección XPATH 1 25
Inyección de comandos SO 2 22
Inyección SQL 4 16
Inyección Script 3 19
Inyección LDAP 5 13
Inyección SMTP 8 4
Inyección HQL 6 10
Inyección JSON 7 7

2.4. PROBABILIDAD DE SER EXPLOTADO SEGÚN LA CWE

La CWE Common Weakness Enumeration es una organización que periódicamente
genera informes de fallas y vulnerabilidades en las aplicaciones web y de modo similar a
la OWASP tiene un top25 de estas vulnerabilidades. Esta organización tiene una serie de
ítems para cada tipo de vulnerabilidad, entre los que se encuentra la probabilidad de ser
explotado, de acuerdo con los datos que recopilan y analizan, es este ítem el que se
usará como base para la selección de los algoritmos a implementar.

Los niveles que ofrece la CWE son: Bajo, Medio, Alto y Muy alto respectivamente; para
realizar la selección se usará la misma técnica de selección frente al criterio de
documentación, asignando un número para cada nivel, respectivamente así: Bajo = 1,
Medio = 2, Alto = 3 y Muy alto = 4; además de aproximar el valor al entero más próximo.

ni = Número que corresponde al nivel Muy alto.

na = Número que corresponde al nivel del algoritmo actual.
pct =. na / ni
P = Peso del algoritmo = 25 x pct
Tabla 5: Selección según criterio de probabilidad de ser explotado según la CWE

Nivel de probabilidad de N° correspondiente

Técnica de ataque Porcentaje Peso
explotación según la CWE al nivel
Inyección XPATH Muy alto 4 100% 25
Inyección de comandos SO Muy alto 4 100% 25
Inyección SQL Muy alto 4 100% 25
Inyección Script Alto 3 75% 19
Inyección LDAP Alto 3 75% 19
Inyección SMTP Medio 2 50% 13
 38 Seguridad de JAX-RS frente a ataques por inyección de código

Inyección HQL Bajo 1 25% 6

Inyección JSON Bajo 1 25% 6

A continuación se presentarán los datos definitivos en la Tabla 5: Selección según criterio

de probabilidad de ser explotado según la CWE, se sumarán los pesos obtenidos de
acuerdo a los criterios anteriores y se asignará en la columna total, está es la que nos
indica cuales son los tres algoritmos que se implementarán:

Tabla 6: Selección de los algoritmos a implementar

Factibilidad Posición P. de ser explotado

Algoritmo / Técnica Documentación Total
de éxito OWASP según la CWE
Inyección SQL 4 25 16 25 70
Inyección XPATH 16 13 25 25 79
Inyección de comandos 13 13 22 25 73
Inyección Script 13 17 19 19 68
Inyección LDAP 22 3 13 19 57
Inyección HQL 25 0 10 6 41
Inyección JSON 25 1 7 6 39
Inyección SMTP 25 1 4 13 43

De acuerdo a los resultados consignados en la Tabla 1: Selección según criterio de

factibilidad de éxito, concluimos que los algoritmos que se van a implementar en la
aplicación Web son:

 Inyección SQL
 Inyección XPATH
 Inyección de comandos

2.5. VALIDACION
En esta sección se describe el uso de la herramienta Vantage Point, este software cuenta
con la capacidad de acceder a cada documento completamente a través de sus términos,
los cuales son tratados como datos que aportan información relevante para los
investigadores de un tema en específico.

El objetivo de esta sección es afirmar el criterio de documentación definido anteriormente

como un atributo eficaz al momento de realizar un análisis de selección, esto debido a la
forma en la cual se recopilaron los documentos ya que el procedimiento se realizó
Seguridad de JAX-RS frente a ataques por inyección de código 39

manualmente. A continuación se describen los pasos y resultados para realizar la

comparación de resultados.

Se realizó una búsqueda usando el motor de búsqueda proporcionado por el proveedor

de esta aplicación, seguido de esto se realiza una descarga de documentos los cuales
fueron importados a Vantage Point usando un filtro de importación de registro.

Los filtros de importación fueron definidos como:

 Algoritmo
 Autores
 Título de documento
 Fecha
 Fuente
 Repositorio de descarga

Ilustración Vantage Point 1 Resultados

En la Ilustración Vantage Point 1 Resultados podemos encontrar los resultados de la

importación de documentos.
 40 Seguridad de JAX-RS frente a ataques por inyección de código

Ilustración Vantage Point 2 Algoritms

En la Ilustración Vantage Point 2 Algoritms podemos observar los algoritmos encontrados

y la cantidad de documentos que hacen referencia de los mismos.

Illustration Vantage Point 3 Pie Chart of Algorimth

Seguridad de JAX-RS frente a ataques por inyección de código 41

Al realizar la búsqueda de las tres primeras bases de datos indexadas encontramos las
referenciadas en la Illustration Vantage Point 4 Data base documents.

Illustration Vantage Point 4 Data base documents

Illustration Vantage Point 5 Chart data base documents

 42 Seguridad de JAX-RS frente a ataques por inyección de código

Con el fin de tener la información actualizada, se usó como criterio de búsqueda el año de
publicación de dicho documento, teniendo en cuenta los resultados de la Illustration
Vantage Point 6 Data documents, se tomaron como referencia los documentos
correspondientes a los años, 2014,2015 y 2016

Illustration Vantage Point 6 Data documents

Si verificamos los datos de la Ilustración Vantage Point 2 Algoritms y la Illustration

Vantage Point 4 Data base documents, podemos observar que el procedimiento manual
encontró la misma cantidad de algoritmos como lo muestra la herramienta Vantage Point,
adicionalmente a esto el procedimiento manual también referencio las mismas bases de
datos indexadas que muestra la herramienta Vantage Point.
Seguridad de JAX-RS frente a ataques por inyección de código 43

3. DEFINICIÓN DE REQUISITOS
En esta sección se definirán los requisitos que serán la base para el diseño e
implementación de la aplicación que proporcione diversas funcionalidades para realizar
ataques a servicios Web implementados en JAX-RS de acuerdo a los algoritmos
seleccionados, con el fin de realizar un análisis de vulnerabilidades de estos servicios. La
aplicación debe realizar ataques por inyección código y proporcionar resultados de la
detección de las vulnerabilidades existentes en los servicios Web implementados en JAX-
RS y desplegados en estos servidores, que se identifiquen en estos ataques.

Inicialmente se describirán los requerimientos funcionales de la aplicación y

posteriormente se definirán los requerimientos no funcionales, con el fin de tener una
perspectiva general del sistema y poder realizar un diseño fiel a las funcionalidades del
mismo.

3.1. REQUERIMIENTOS FUNCIONALES

 El prototipo contará con una interfaz gráfica en la cual podrá ingresar la URI del
servicio RESTful y ejecutar los respectivos ataques.
 El prototipo debe implementar los tres algoritmos definidos en la Tabla 1:
Selección según criterio de factibilidad de éxito y realizar los ataques de acuerdo a
la selección del usuario.
 La aplicación ejecutará estas operaciones solicitando como entradas la URI del
servicio Web y el tipo de ataque a ejecutar.
 La aplicación debe generar una vista con los resultados obtenidos, esta debe
describir las vulnerabilidades encontradas y ser de fácil comprensión por parte del
usuario.
 La aplicación debe contar con un botón de retorno en la vista de resultados que lo
dirija a la vista principal de la aplicación.

3.2. REQUERIMIENTOS NO FUNCIONALES

 La aplicación debe contar con un manual de usuario que describa de forma
detallada el funcionamiento del sistema.
 44 Seguridad de JAX-RS frente a ataques por inyección de código

4. DISEÑO DEL SISTEMA

En esta sección se definirá de forma general el diseño del sistema. Primero se definirán
los actores, posteriormente se describirán los casos de uso para realizar después el
diagrama de contexto UML que ayude a representar el diseño de forma general.

4.1 ACTORES
Con base en la definición de requisitos se identifica un único actor en la aplicación, que
podría ser el desarrollador del servicio o un profesional de seguridad informática que
tenga acceso a los servicios Web.

4.2 CASOS DE USO

4.2.1 Realizar análisis

El usuario ingresará el URI del servicio Web que se requiere analizar en un campo de
texto y seleccionará el tipo de ataque en un campo de tipo radio, por último hará clic en un
botón que dispare el proceso.

4.2.2 Escanear servicio Web

La aplicación realiza un análisis activo de los servicios Web mediante los ataques de
inyección de código de acuerdo a los parámetros ingresados por el usuario.

4.2.3 Ver resultados

El usuario podrá ver los resultados del análisis en una vista que contenga los datos de las
vulnerabilidades explotadas por el prototipo.

Ilustración 2: Diagrama de casos de uso

Seguridad de JAX-RS frente a ataques por inyección de código 45

4.3 DIAGRAMA DE CONTEXTO

A continuación se presenta un diagrama de contexto en el que se puede observar el
diseño del sistema en conjunto, los escenarios de aplicación y el prototipo de pruebas:

Ilustración 3: Diagrama de contexto

5. ARQUITECTURA DEL SISTEMA

Para el desarrollo de este prototipo se ha hecho uso del lenguaje de programación Java
en su edición estándar, el IDE eclipse y un entorno de ejecución local.
 46 Seguridad de JAX-RS frente a ataques por inyección de código

5.1. Diagrama de despliegue

En este diagrama se observa el entorno físico de la aplicación, sus conexiones y
comunicación con otros sistemas.

Ilustración 4: Diagrama de despliegue

5.2. Diagrama de componentes

En el siguiente diagrama se definen los componentes de software de la aplicación, sus
relaciones e interfaces:

Ilustración 5: Diagrama de componentes

Seguridad de JAX-RS frente a ataques por inyección de código 47

5.3. Diagrama de clases

En el siguiente diagrama se presenta la estructura de clases Java que conformará la
aplicación:

Ilustración 6: Diagrama de clases

6. DESARROLLO DEL SISTEMA

En esa sección se describe el desarrollo de PAIC (Prototipo de Ataque de Inyección de
Código), este es un software diseñado con el objetivo de realizar ataques a Web Service
implementados con JAX-RS.

6.1. CAPA DE PRESENTACIÓN

Para la implementación de la interfaz de usuario GUI se utilizó el framework Swing, este
framework provee facilidades para diseñar e implementar GUIs. Cuenta con componentes
como layout, tablas, labels, colores, marcos, cajas de textos entre otros [37].

La interfaz del prototipo está compuesta por:

1. Un label que contiene el mensaje de bienvenida

 48 Seguridad de JAX-RS frente a ataques por inyección de código

2. Una agrupación de RadioButtons para seleccionar la librería a la cual se realizara

el ataque
3. Un mensaje descriptivo de la agrupación de RadioButtons
4. Un botón que ejecutara un petición GET a la librería seleccionada
5. Un botón que ejecutara un petición POST a la librería seleccionada
6. Una caja de texto que muestra la respuesta del ataque realizado
En la Ilustración 7 Interfaz PAIC.

Ilustración 7 Interfaz PAIC

6.2. CAPA LÓGICA

Aquí se describe los eventos disparados que ejecutaran los algoritmos de inyección de
código a las implementaciones seleccionadas

Request GET: El Código fuente N° 3: Evento Click GET realiza la validación de la

implementación seleccionada con el fin de indicar la URL del recuso, seguido a este paso
se procede a disparar el ataque

Código fuente N° 3: Evento Click GET

Seguridad de JAX-RS frente a ataques por inyección de código 49

Request POST: El

Código fuente N° 4: Evento Click POST realiza la validación de la implementación

seleccionada con el fin de indicar la URL del recuso, seguido a este paso se procede a
disparar el ataque

Código fuente N° 4: Evento Click POST

 50 Seguridad de JAX-RS frente a ataques por inyección de código

Clase ¡Error! No se encuentra el origen de la referencia.

El objeto http es una instancia de la clase definida en el

, esta es la clase que realiza las peticiones al Web Service.

Código fuente N° 5: Clase HttpURLConnectionAttack

Seguridad de JAX-RS frente a ataques por inyección de código 51

El método GET implementa el Código fuente N° 6: Attack GET, el cual usa el método
shellAtack de la clase AlgoritmAttack que contiene la inyección de comandos de SO para
ejecutar en el Web Service.

Código fuente N° 6: Attack GET

El método POST implementa el Algoritmo 5 Attack POST, el cual implementa los

métodos sqlAttack y xpathAttack de la clase AlgoritmAttack que contiene la inyección de
una sentencia SQL y un ataque de búsqueda XPath que se ejecutara en el Web Service.
 52 Seguridad de JAX-RS frente a ataques por inyección de código

Código fuente N° 7: Attack POST

Clase ¡Error! No se encuentra el origen de la referencia.

El objeto attack es una instancia de la clase AlgoritmAttack, esta clase contiene los métodos
de inyección de parámetros de las peticiones para realizar el ataque, el

Código fuente N° 8: Clase AlgoritmAttack describe la estructura de la clase.

Seguridad de JAX-RS frente a ataques por inyección de código 53

Código fuente N° 8: Clase AlgoritmAttack

El Código fuente N° 9: Xpath Attack es el encargado de inyectar en las variables del

cuerpo de la peticion una tautología que resultara siempre resultara verdadera gracias a la
concatenación de la validación or 1=1.

La finalidad de este ataque es lograr el ingreso a la plataforma afectando el concepto de

autenticidad definido por la seguridad informática.

Código fuente N° 9: Xpath Attack

 54 Seguridad de JAX-RS frente a ataques por inyección de código

El Código fuente N° 10: SQL Attack será el encargado de inyectar una sentencia SQL que
rompa la cadena de inserción en una tabla y concatena la sentencia delete from table con
el fin de eliminar los registros de una tabla, adicionalmente insertara un registro que para
ambiente de pruebas ratificara que el ataque fue exitoso.

Este ataque se implementó con el fin de afectar el principio de integridad definido por la
seguridad informática, el cual indica que los datos se deben de mantener libres de
modificaciones no autorizadas.

Código fuente N° 10: SQL Attack

El Código fuente N° 11: Shell Attack será el encargado de concatenar la codificación del
carácter %20% que es un espacio en blanco y el carácter %7C que es el símbolo pipe |
seguido a esto el comando start combinado con el servicio iexplore, la ejecución de esta
sentencia tiene como finalidad iniciar el servicio de internet explorer 5 veces por cada
solicitud, ese es un servicio que consume un amplio recurso de memoria que ejecutado
múltiples veces colapsara el servidor generando denegación del servicio.

Con este ataque se afecta el principio de disponibilidad definido por la seguridad

informática.

Código fuente N° 11: Shell Attack

Seguridad de JAX-RS frente a ataques por inyección de código 55

6.3. CLIENTE
Este prototipo está completamente escrito en lenguaje de programación Java, el
desarrollo fue elaborado bajo Java Platform 7 y codificado con el IDE eclipse. Como ya se
mencionó anteriormente se utilizó Swing para el desarrollo de la interfaz de usuario.

Para ejecutar la aplicación en un ordenador, se debe de tener instalado JRE (Java

Runtime Environment), esta es la máquina virtual de java encargada de ser el
intermediario entre la aplicación desarrollada en Java y el sistema operativo.

6.4. CAPA DE NEGOCIO

El objetivo de esta sección es describir el flujo que tiene el prototipo, mostrando la
secuencia de cada método con la implementación del algoritmo de inyección,
adicionalmente describir como interactúa con los REST Services JAX-RS
Seguridad de JAX-RS frente a ataques por inyección de código 57

En el ¡Error! No se encuentra el origen de la referencia. se describe secuencialmente el orden de las actividades ejecutadas
y los algoritmos inyectados, con el fin de afectar la integridad y autenticidad del REST Service.
58 Seguridad de JAX-RS frente a ataques por inyección de código

Flujo 1 Request POST

Seguridad de JAX-RS frente a ataques por inyección de código 59
 60 Seguridad de JAX-RS frente a ataques por inyección de código

En el Flujo 2 Request GET se describe secuencialmente el orden de las actividades ejecutadas y el algoritmo inyectado, con el
fin de afectar la disponibilidad del REST Service.

Flujo 2 Request GET

Seguridad de JAX-RS frente a ataques por inyección de código 61

7. ESCENARIO DE PRUEBAS
En esta sección se define el escenario de aplicación del prototipo PAIC (Prototipo de
Ataque por Inyección de Código) teniendo en cuenta que se deben de cumplir los
siguientes objetivos:

 Autenticación de usuarios mediante una búsqueda Xpath.

 Cada vez que ingrese un usuario se debe de capturar IP y navegador desde
donde se disparó el evento.
 Integrar un módulo de la aplicación web con el intérprete de comandos usando
[Link] con el fin de llamar a comandos específicos del sistema operativo
 La aplicación debe de usar el método POST para autenticar y el método GET para
realizar operaciones de ejecución de comandos de sistema operativo.

7.1. ESCENARIO DE PRUEBAS

Teniendo en cuenta los puntos en mención el escenario de pruebas que se basa en
cPanel. Un cPanel es panel de control de hosting, es decir un administrador de cuentas
de alojamiento Web donde se puede hacer cambios a su cuenta, crear cuentas y listas de
correo, crear cuentas FTP, crear subdominios, en fin administrar el sitio de
almacenamiento con varias opciones [38]. Para implementar los algoritmos de ataque se
creó un módulo de login que usa el método POST para autenticar los usuarios en la
plataforma a través de una búsqueda Xpath, también se desarrolló un módulo de pruebas
de comunicación que se basa en generar comandos Shell como ping y tracert usados
para validar la conectividad de un punto a otro.

El entorno en que se desarrollan las pruebas está compuesto por un equipo personal
donde se ejecuta el prototipo de ataque y una plataforma de servicios de nube como
Amazon Web Services. Esta plataforma de servicios ofrece potencia de cómputo,
almacenamiento de bases de datos, entrega de contenido y otra funcionalidad para
ayudar a las empresas a escalar y crecer. Se usa esta plataforma debido a que se basa
en la esencia de REST. Posee una base de datos con todos los detalles de los productos
que vende. Cuando un usuario quiere realizar una búsqueda o acceder a la información
de determinados productos en particular, accede directamente a los recursos solicitados y
no a métodos remotos[39][19].

Los Web Services se despliegan en un servidor Tomcat, este es un contenedor de

Servlets que se utiliza para desplegar implementaciones como Java Servlets y Java
Server Pages, este desarrollo es implementado en Java por lo cual puede correr en
cualquier sistemas operativos con su respectiva máquina virtual de Java [40], aquí se
 62 Seguridad de JAX-RS frente a ataques

aprovecha esta ventaja y se hace uso de Windows Server 2012 como sistema operativo,
esto debido a que es un software comercial que soporta amplias estructuras de escritorios
virtuales lo cual trae beneficios como la centralización que aloja los entornos de escritorio
como sistema operativo, aplicaciones y datos de los usuarios en servidores remotos, esto
limita las arduos recursos como espacio, desplazamiento, personal técnico entre otros
[41].

Se desarrollan cuatro Web Services los cuales presentan la misma interfaz gráfica y usan
las anotaciones propias de JAX-RS, este es un marco de referencia que tiene como
objetivo declarar un Servicio Web a través de simples anotaciones propias de este
framework usando mapeo de objetos creados en Java implementado el protocolo HTTP
[42]. Cada servicio se desarrolla con base en de cada una de las implementaciones
definidas en el apartado [Link]. Implementaciones de JAX-RS.

7.2. DESARROLLO DEL WEB SERVICE

Los Web Services implementados están compuestos por un archivo XML llamado
[Link] el cual contiene información de la estructura de la aplicación, configuración de y
despliegue de los componentes y dependencias que conforman una aplicación [43], Este
archivo reside en el directorio WEB-INF. También se compone de una clase principal que
a través del uso de las notaciones propias por JAX-RS permitirá el consumo de sus
funciones

7.2.1. Capa modelo

Se usa como recurso de datos de información de usuarios, un archivo XML en el cual
están definidos los usuarios permitidos para el ingreso a la plataforma y el nivel de
privilegios que tiene sobre la misma.
Seguridad de JAX-RS frente a ataques por inyección de código

Código fuente N° 12: Modelo XML

En la
 64 Seguridad de JAX-RS frente a ataques

Código fuente N° 12: Modelo XML se define la estructura que tiene el archivo de
autenticación de usuarios compuesto por: nombre, apellido, nombre de usuario,
contraseña y tipo de usuario creado. También se utilizará una base de datos para
almacenar registros de la IP y navegador desde donde ingresaron a la plataforma.

Código fuente N° 13: Tabla log

La base de datos se desarrolla en PostgreSQL[44], este es un sistema de gestión de

bases de datos y para este ambiente de pruebas únicamente se crea una tabla que se
encarga de guardar estos registros, en la Código fuente N° 13: Tabla log se define la
estructura de la tabla.

Como marco de referencia para el almacenamiento de datos se implementa JPA, este es

un modelo de persistencia basado en objetos planos de Java conocidos como POJO por
sus siglas en inglés Plain Old Java Object, cuya función es mapear cada tabla de una
base de datos en una clase simple que contiene información de sus atributos y relaciones
en lenguaje JAVA [44].

Una vez definida la estructura de la tabla que se muestra a continuación a través de la

¡Error! No se encuentra el origen de la referencia.. La clase desarrollada con la
estructura definida. Cada atributo debe estar definidos como privados y contener sus
métodos Get y Set. Siempre debe de iniciar con la anotación @Entity y la llave primaria
debe de estar precedida por la anotación @Id, para lograr la implementación de esta
estructura de uso la librería [Link], está es la API que gestiona el mapeo y
persistencia de objeto / relación, los métodos usados son definidos en la

.
Seguridad de JAX-RS frente a ataques por inyección de código

Tabla 7: Librerías Persistencia

Método Descripción
Entity Se usa para indicar que esta clase es una entidad
Id Se usa para especificar un atributo como clave primaria

Se usa para especificar el nombre de una consulta,

los parámetros que recibe son de tipo String y el primero
NamedQuery
debe de ser el nombre de la consulta y el segundo
la consulta construida.

Para el acceso a datos se establece una clase externa que define como se almacenan los
datos y como tener acceso a los mismos. Primero se definen dos variables estáticas una
llamada emf la cual es de tipo EntityManagerFactory quien se encarga de gestionar todas
las entidades, la otra variable se define como em de tipo EntityManager quien es el
encargado de gestionar el un grupo de entidades.

Las variables se declaran estáticas con el fin de instanciarlas una sola vez, esto se debe a
que cada vez que se instancie un EntityManager será cargado un contexto diferente, si
esto no es controlado cada contexto generara una sobrecarga en la memoria del
dispositivo.

Como se mencionó anteriormente se realiza un control de instancia en el constructor

validando si el EntityManager es nulo este se instancia, de lo contrario se omite su
creación. También está el método record que recibe como parámetros la IP y el
navegador para almacenar. Después de ello realiza una consulta a la tabla log para tomar
el máximo Id, después de ello genera una consulta para insertar los parámetros
recolectados con anterioridad. En la Tabla 8: Librerías DAO se describe las librerías
usadas.

Código fuente N° 15: DAO Log

66 Seguridad de JAX-RS frente a ataques

Tabla 8: Librerías DAO

Método Descripción

EntityManager Es usado para interactuar con el contexto de persistencia

Se usa para interactuar con todas las entidades

EntityManagerFactory
para generar la unidad de persistencia
Persistence Se usa para instanciar la unidad de persistencia
Se utiliza para indicar que empieza la secuencia de
[Link]
transacciones con la entidad
Se usa para control de error en caso de existir un error
[Link]
revertir transacciones, de lo contrario ejecutarlas
[Link] Se usa para crear una consulta personalizada
Seguridad de JAX-RS frente a ataques por inyección de código

7.2.2. Capa de presentación

Para esta capa se usan las tecnologías de la Web mencionadas en el marco conceptual,
lenguajes como JavaScript, CSS y HTML5 para generar un diseño interactivo a la interfaz
de usuario.

Código fuente N° 16: Estructura HTML

Código fuente N° 17: Estructura HTML

Código fuente N° 18: Estructura CSS

68 Seguridad de JAX-RS frente a ataques

Código fuente N° 19: Función de login JavaScript

Seguridad de JAX-RS frente a ataques por inyección de código

Código fuente N° 20: Función test de JavaScript

7.2.3. Capa lógica

En esta capa se encapsula el control y la lógica del negocio a través de una clase
principal que implementa dos métodos. Un método utiliza el método POST para realizar la
autenticación de usuarios usando una búsqueda con XPATH en un archivo XML, en este
mismo paso, la aplicación tomara la IP y el navegador del cual fue realizada la petición
 70 Seguridad de JAX-RS frente a ataques

para guardar esta información en un log de auditoria. Otro método usa el método GET
para tomar los datos que viajan a través de la URL para realizar la prueba de
comunicación usando [Link].

En todas las aplicaciones se desarrolla una clase principal que contiene un método
público, el cual retornara un String cuyo parámetro es una cadena de texto que contiene
el nombre del host.

El inicio del método contiene el método la anotación @GET la cual indica que solo recibe
parámetros inyectados a través de la URL, la segunda línea de código usa la anotación
@Path(“”) cuyos parámetros de filtro es aceptar todo lo que venga por GET y que la ruta
finalice con la combinación de caracteres definida en la anotación @Path(“”) separada por
el símbolo ‘/’ concatenada con la secuencia de caracteres que conformaran la IP o
nombre del Host a comunicar, la tercera línea de código es @Produces la cual indica que
tipo de formato de archivo retorna, en este caso será texto plano. Dentro del método se
usa la anotación @PathParam(“host”) para las implementaciones de Jersey y RESTEasy
ya que en Restlet no funciona este método y por ende se usa la función
getRequest().getAttributes().get() cuyo parámetro final es la posición de la variable
definida previamente anotación @PatParam. Estas funciones tienen la misma operación
su objetivo es tomar el fragmento de la URL que se encuentra en la posición definida en
la anotación @PatParam con el nombre del solicitante.

Estas librerías trabajan bajo el soporte de la versión HTTP 1.1 por ello se usa la palabra
reservada switch validando que en caso de ser 1 ejecute las operaciones, de lo contrario
retorne un mensaje indicando que la versión http no es soportada. Si la versión es
soportada se usara la palabra reservada try, catch cuya funcionalidad es ejecutar todo lo
que este dentro del try, en caso de que suceda un error de ejecución saltara
automáticamente al catch donde controlara el error sucedido dentro del try. Dentro del try
se ejecutara a través de [Link] el comando ping y se concatenara con la variable
inyectada en la posición de {host} definida en la anotación @Path al ejecutar ese comand
to se realizara la conversión de tipos de datos retornados para poder devolver el mensaje
a la aplicación del cliente que tomara los datos y los mostrara al usuario

Esta clase también se compone de un método público que retorna un String cuyos
parámetros son nombre de usuario y contraseña para realizar el login.

El inicio del método contiene la anotación @POST con la cual se define que solo acepta
peticiones que vengan por el verbo POST y codificadas con el formato “application/x-
www-form-urlencoded”, seguido de esto se define la siguiente línea con la anotación
@Path() la cual indica la ruta que debe de tener la petición para que el método sea
disparado, la tercera línea de código es @Produces la cual indica que tipo de formato de
archivo retorna, en este caso será texto plano.
Seguridad de JAX-RS frente a ataques por inyección de código

Dentro del método para el caso de Jersey y RESTEasy se usa la anotación

@FormParam() la cual recibe el nombre de la variable que viene codificada dentro de la
petición, en el caso de Restlet se usa la instancia del objeto Form debido a que Restlet
usa sus propias funciones para capturar valores de las peticiones. El método también
cuenta con la combinación de la anotación @Contex y el objeto HttpServletRequest
quienes son los encargados de escuchar los encabezados de las peticiones, la anotación
@Context y el objeto SecurityContext context determinan la información de seguridad
para una solicitud para así saber información del usuario que genero la petición,
finalmente usamos @HeaderParam("user-agent"), anotación encargada de extraer
información de las variables que se encuentran en el encabezado de la petición, en este
caso se utiliza “user-agent” para capturar el navegador.

Dentro de la ejecución del método se usa la palabra reservada switch esto con el fin de
validar si existe o no soporte para la versión del protocolo HTTP. Si todas las validaciones
resultaron correctas se ejecutan las siguientes líneas de código. En la primera línea de
código se cargara el archivo XML donde se encuentran los datos de los usuarios
permitidos.

Primero tomaremos la IP de origen de la petición:

String ipAddress = [Link]();

Luego se procede a ingresar el Log de auditoria, la operación de este método se describió

en la capa modelo se encuentra la estructura de la clase.

[Link](ipAddress,userAgent);

FileInputStream file = new FileInputStream(new File("C:/[Link]"));

En la segunda línea definimos un objeto que permite obtener un analizador de árboles de

objetos DOM en un documento XML.

DocumentBuilderFactory builderFactory = [Link]();

En la tercera línea llamamos un método para método obtener una nueva instancia de un
DocumentBuilderFactory del nombre de la clase.

DocumentBuilder builder = [Link]();

En la cuarta línea llamamos un método para analizar el contenido del archivo en cuestión
como un documento XML y devuelve un nuevo objeto DOM de documentos.

Document xmlDocument = [Link](file);

En la quinta linea se instancia un objeto para poder seleccionar uno o más nodos de un
documento XML.
 72 Seguridad de JAX-RS frente a ataques

XPath xPath = [Link]().newXPath();

En la sexta línea se construye la expresión que será evaluada posteriormente.

String expression = "/USUARIOS/USUARIO[UserName='"+user+"'] and

/USUARIOS/USUARIO[Password='"+password+"']";

En la séptima línea se evalúa la expresión retornando Falso o Verdadero según los datos
de entrada

String email = [Link](expression).evaluate(xmlDocument);

De esta manera concluye la estructura de la clase principal la cual se encargara de

ejecutar funciones a partir de las rutas de peticiones generadas por el cliente.

[Link]. Jersey
Partimos con la configuración del Servlet en el archivo denominado como [Link] el cual
contiene la estructura definido en la Código fuente N° 21: [Link] Jersey.

Código fuente N° 21: [Link] Jersey

Desde la línea 8 hasta la línea 12 se configura el nombre del Servlet y la clase de la

librería a la cual ira mapeado ese nombre. De la línea 13 a la línea 16 se configura el
nombre del Servlet previamente definido, indicándole que ruta aceptara para gestionar las
peticiones. Finalmente en la línea 18 se configura el archivo [Link] que aceptara el
Seguridad de JAX-RS frente a ataques por inyección de código

Servidor por defecto al ingresar la IP del Host o el nombre de dominio seguido del nombre
de la aplicación

Jersey GET
La estructura del método GET se puede ver en Código fuente N° 22: Get Jersey

Código fuente N° 22: Get Jersey

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación}/rs/cpanel/connection/{ ip

o nombre de dominio de host a realizar prueba}
 74 Seguridad de JAX-RS frente a ataques

Jersey POST
La estructura del método POST se puede ver en Código fuente N° 23: Post Jersey 1 e
Código fuente N° 24: Post Jersey 2.

Código fuente N° 23: Post Jersey 1

Código fuente N° 24: Post Jersey 2

Seguridad de JAX-RS frente a ataques por inyección de código

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación}/rs/cpanel/ login/

Content-Type: application/x-www-form-urlencoded
user={nombre de usuario}&password={contraseña}

[Link]. RESTEasy

Partimos con la configuración del Servlet en el archivo denominado como [Link] el cual
contiene la estructura definido en la Código fuente N° 25: [Link] .
 76 Seguridad de JAX-RS frente a ataques

Código fuente N° 25: [Link] RESTEasy

Desde la línea 19 hasta la línea 22 se configura el nombre del Servlet y la clase de la

librería a la cual ira mapeado ese nombre. De la línea 23 a la línea 26 se configura el
nombre del Servlet previamente definido, indicándole que ruta aceptara para gestionar las
peticiones. Finalmente en la línea 28 se configura el archivo [Link] que aceptara el
Servidor por defecto al ingresar la IP del Host o el nombre de dominio seguido del nombre
de la aplicación.

RESTEasy GET

La estructura del método GET se puede ver en la Código fuente N° 26: Get .

Código fuente N° 26: Get RESTEasy

Seguridad de JAX-RS frente a ataques por inyección de código

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación} / communication/{ IP o

nombre de dominio de host a realizar prueba}
 78 Seguridad de JAX-RS frente a ataques

RESTEasy POST
Código fuente N° 27: Post RESTEasy 1

La estructura del método POST se puede ver en la Código fuente N° 27: Post RESTEasy
1 e Código fuente N° 28: Post RESTEasy 2

Código fuente N° 28: Post RESTEasy 2

Seguridad de JAX-RS frente a ataques por inyección de código

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación}/cPanel/login

Content-Type: application/x-www-form-urlencoded user={nombre de
usuario}&password={contraseña}

[Link]. Restlet
Se inicia con la configuración del Servlet en el archivo denominado como [Link] el cual
contiene la estructura definido a continuación:

Código fuente N° 29: [Link] Restlet

Desde la línea 7 hasta la línea 15 se configura el nombre del Servlet y la clase de la

librería a la cual ira mapeado ese nombre, en esta misma sección en la línea 12
 80 Seguridad de JAX-RS frente a ataques

indicamos la clase del proyecto que tendrá configurada las rutas permitidas y las clases a
las cuales pertenece para consumir este servicio. Esta estructura se encuentra en la
Código fuente N° 30: Restlet Route Attach, en esta clase usamos la el método
[Link] el cual se usa para enlazar la ruta de una petición a una clase del proyecto
que es la que contendrá implementados los servicios a consumir.

De la línea 16 a la línea 19 se configura el nombre del Servlet previamente definido,

indicándole que ruta aceptara para gestionar las peticiones. Finalmente en la línea 21 se
configura el archivo [Link] que aceptara el Servidor por defecto al ingresar la IP del
Host o el nombre de dominio seguido del nombre de la aplicación.

Código fuente N° 30: Restlet Route Attach

Restlet GET

La estructura del método GET se puede ver en Código fuente N° 31: Get Restlet.

Código fuente N° 31: Get Restlet

Seguridad de JAX-RS frente a ataques por inyección de código

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación} /cpanel/communication

/{ ip o nombre de dominio de host a realizar prueba}

Restlet POST

La estructura del método POST se puede ver en la Código fuente N° 32: Post Restlet 1 y
la Código fuente N° 33: Post Restlet 2.

Código fuente N° 32: Post Restlet 1

82 Seguridad de JAX-RS frente a ataques

Código fuente N° 33: Post Restlet 2

Seguridad de JAX-RS frente a ataques por inyección de código

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación}/cpanel/ login

Content-Type: application/x-www-form-urlencoded
user={nombre de usuario}&password={contraseña}

[Link]. Apache CXF

Se inicia con la configuración del Servlet en el archivo denominado como [Link].

Código fuente N° 34: CXF [Link]

 84 Seguridad de JAX-RS frente a ataques

En la Código fuente N° 34: CXF [Link] se observa de la línea 8 a la línea 18 la

configuración del Servlet, en las líneas 13 a 17 se describe el bean de configuración en el
que se define la clase a la cual estará mapeada las URL a consumir servicios, esta
estructura se encuentra reflejada en la Código fuente N° 35: CXF [Link], en este
archivo de configuración se inyecta la clase que tiene configurada las peticiones
permitidas y los recursos que puede consumir. Para poder construir esta clase usamos la
librería [Link] en la

se describen las librerías usadas

Código fuente N° 35: CXF [Link]

Seguridad de JAX-RS frente a ataques por inyección de código

Código fuente N° 36: CXF ServiceRest

 86 Seguridad de JAX-RS frente a ataques

Tabla 9: librerias service rest

Método Descripción
[Link] Usado para crear la configuración en el servidor
[Link] Usado para iniciar la configuración del servidor
[Link] Se usa para crear los puntos finales del servido
Se para retornar la misma instancia de recursos
[Link]
para cada petición

Código fuente N° 38: CXF GET

CXF GET

La Código fuente N° 38: CXF GET muestra la descripción de la clase.

Este método responde a la petición construida por la ruta:

Seguridad de JAX-RS frente a ataques por inyección de código

[Link] o nombre de dominio de host}/{nombre de la aplicación}/cxf/fs /communication /{

IP o nombre de dominio de host a realizar prueba}

CXF POST

La estructura del método POST se puede ver en la Código fuente N° 39: CXF POST 1 y la
Código fuente N° 40: CXF POST 2.

Código fuente N° 39: CXF POST 1

Código fuente N° 40: CXF POST 2

 88 Seguridad de JAX-RS frente a ataques

Este método responde a la petición construida por la ruta:

[Link] o nombre de dominio de host}/{nombre de la aplicación}/cxf/sf / login

Content-Type: application/x-www-form-urlencoded
user={nombre de usuario}&password={contraseña}

7.2.4. Capa de Despliegue

En la Ilustración 8: Despliegue implementaciones se describe el ambiente en el cual está
desplegado el escenario de pruebas. Estos componentes ya fueron previamente definidos
al inicio del escenario de pruebas.

Ilustración 8: Despliegue implementaciones

Seguridad de JAX-RS frente a ataques por inyección de código

8. EVALUACIÓN DE VULNERABILIDADES
Las vulnerabilidades son el origen de los fallos de seguridad de una aplicación. Una
vulnerabilidad en una aplicación puede ser simplemente un error, un problema en su
código o en su configuración. Es probable que las aplicaciones contengan errores, puesto
que han sido creados por seres humanos, esto es especialmente frecuente en el caso de
las aplicaciones muy complejas, como por ejemplo los sistemas empresariales, ya que
tienden a contener errores de manera exponencial. La característica que convierte un
simple fallo en una vulnerabilidad es la posibilidad de que el abuso deliberado de este
defecto pudiera llevar a un riesgo de seguridad que comprometa el sistema sobre el que
se ejecuta esa aplicación.

Se realiza una evaluación de las vulnerabilidades encontradas en las cuatro

implementaciones de JAX-RS definidas en el proyecto, además del nivel de impacto que
estas representan para la seguridad de una aplicación que se base en estas tecnologías,
específicamente el escenario de pruebas descrito anteriormente. Antes que todo se
definirá el concepto de vulnerabilidad, su identificación en un sistema informático y una
lista de posibles vulnerabilidades comunes en aplicaciones.

8.1. VULNERABILIDADES
Una vulnerabilidad es un fallo específico en la seguridad de una aplicación, puesto que no
todos los errores de programación se convierten en fallos de seguridad. Un error en un
programa puede llevar a que este no funcione correctamente o que su comportamiento no
sea el esperado, pero no todos estos tipos de problemas pueden considerarse fallos de
seguridad. La vulnerabilidad puede ser más o menos grave dependiendo de la capacidad
de un atacante de aprovecharse de estos defectos [7].

El Observatorio de la seguridad de la información que hace parte del instituto nacional de

tecnologías de la comunicación de España, define algunos parámetros que se deben
 90 Seguridad de JAX-RS frente a ataques

tener en cuenta para identificar vulnerabilidades en aplicaciones de software[7], estas se

detallan a continuación:

8.1.1. Producto afectado

Para definir una vulnerabilidad es necesario conocer los productos de software que
pueden resultar afectados a consecuencia de un ataque. Dentro de una aplicación, una
vulnerabilidad puede afectar un componente, a un grupo de estos o incluso programas
totalmente diferentes que compartan el mismo fallo. Este último puede ocurrir cuando el
componente afectado por la vulnerabilidad es utilizado por sistemas diferentes, por
ejemplo, un conjunto de aplicaciones que conforman un sistema de información
empresarial, suponiendo que varias de estas aplicaciones hacen uso de un servicio Web
que conecta con un recurso de datos, si este es el que presenta puntualmente la
vulnerabilidad, esta afectará todas estas aplicaciones y en algunos casos a todo el
sistema.

De acuerdo a esto se especifica una tabla, en la que se pueden apreciar las

vulnerabilidades encontradas en cada una de las cuatro implementaciones frente a cada
uno de los tres tipos de ataques realizados. Para este parámetro se definieron cuatro
productos posibles de afectar, estos son:
1. Servicio.
2. Componente.
3. Aplicación.
4. Servidor.

5. Tabla 10: Vulnerabilidades bajo el parámetro de productos afectados

Apache
Tipo de ataque Jersey RESTEasy Restlet
CXF
service service service service
SQL Injection component component component component
application application application application
service service service service
XPATH Injection component component component component
application application application application
service service service NA
component component component NA
Command Injection
application application application NA
server server server NA
Seguridad de JAX-RS frente a ataques por inyección de código

8.1.2. Ubicación
Una vulnerabilidad se localiza habitualmente en un componente o módulo del sistema,
debido a que, por lo general las aplicaciones se componen de varios módulos que se
comunican entre sí. Una vulnerabilidad puede encontrarse en un módulo concreto del
programa o en la configuración del entorno de despliegue, puede existir una
vulnerabilidad en un módulo de lectura de archivos PDF sin afectar a otro que procesa
otro tipo de archivos, o también si el fallo se encuentra en un componente intrínseco del
sistema, por ejemplo, puede ocurrir por si hay un fallo en el sistema operativo. Los
servicios RESTful JAX-RS también tienen componentes, ya sea una clase que
implemente el servicio o un componente de la implementación.

Bajo este parámetro se definieron como ubicaciones las diferentes partes que componen
el sistema, siendo estas los productos nombrados en el punto anterior.

Tabla 11: Vulnerabilidades bajo el parámetro de ubicación

Apache
Tipo de ataque Jersey RESTEasy Restlet
CXF
SQL Injection service service service service
XPATH Injection service service service service
Command Injection service service service NA

8.1.3. Causa
Este punto se refiere específicamente a los problemas ocasionados por componentes de
código de la aplicación, como se mencionó anteriormente a lo largo del documento, hay
técnicas de ataque basadas en errores de programación, ya sea que no se validen los
valores de una variable, los límites de la memoria, o que se olvide establecer permisos
adecuados a un recurso de datos, como también ataques basados en fallas de los
componentes externos o de la configuración del servidor. Las consecuencias de estos
fallos pueden ser de varios tipos, desde la caída del servicio por desbordamiento de
memoria hasta el acceso a información confidencial.

Las posibles causas que se definen para este parámetro son:

1. Codificación: es cuando el programador pone pocas o nulas barreras de acceso de

datos a la aplicación, como validar cadenas de entrada.
 92 Seguridad de JAX-RS frente a ataques

2. Configuración de componente interno: Configuraciones de acceso de

componentes específicos del sistema, por ejemplo, el módulo de pagos de una
tienda online.
3. Configuración de componente externo: se refiere a la configuración de
componentes de software desarrollados externamente que hagan parte de la
aplicación, como es el caso de los framework.
4. Configuración del servidor: configuraciones del servidor que puedan ser
aprovechadas por los atacantes para afectar al sistema.

Tipo de ataque Jersey RESTEasy Apache CXF Restlet

SQL Injection coding coding coding Coding
XPATH Injection coding coding coding Coding
coding coding coding NA
Command Injection server server server
NA
configuration configuration configuration

Tabla 12: Vulnerabilidades bajo el parámetro de causa

8.1.4. Impacto
Es lo que puede ocurrir al sistema en caso de que un atacante se aproveche de la
vulnerabilidad, por ejemplo, en el caso de que este logre realizar un acceso sin
autorización al sistema, se deben validar las acciones que este puede lograr allí, ya sea
robo de información confidencial o elevar permisos para realizar una modificación de la
información. El impacto puede ayudar a definir en gran medida la gravedad de la
vulnerabilidad. La ejecución de código por parte del atacante es grave, ya que el atacante
podrá podría realizar acciones sobre los componentes del sistema quedando esté en
manos de un extraño.

Para definir los tipos de impactos se tomó como referencia la clasificación de

consecuencias de la CWE, la cual define tres consecuencias comunes que traen los
ataques a las aplicaciones Web, estas son:

1. Integridad.
2. Confidencialidad.
3. Disponibilidad.
Seguridad de JAX-RS frente a ataques por inyección de código

Tabla 13: Vulnerabilidades bajo el parámetro de impacto

Tipo de ataque Jersey RESTEasy Apache CXF Restlet

SQL Injection Integrity Integrity Integrity Integrity
Integrity Integrity Integrity Integrity
XPATH Injection
Confidentiality Confidentiality Confidentiality Confidentiality
Command Injection Availability Availability Availability NA

8.2. RESULTADOS

En este proyecto se tomarán cada uno de estos parámetros como indicadores de

vulnerabilidad, para cada uno de estos se define una medida entre 0 y 1, esta será su
porcentaje de vulnerabilidad respecto a ese indicador, por último, se promediarán los
porcentajes para concluir la vulnerabilidad definitiva. Por ejemplo, suponiendo que la
vulnerabilidad de Jersey frente a XPATH injection bajo el parámetro de productos
afectados es 0.75, bajo el parámetro de ubicación es 0.5, bajo el parámetro de causas es
0.5 y bajo el parámetro de productos afectados es 0.25; se promediarán esos 4
porcentajes y el resultado es el nivel de vulnerabilidad de Jersey frente a XPATH.

A continuación, se define la fórmula que se aplicará a cada uno de las vulnerabilidades

para encontrar el nivel de estas:

n = Número de ítems posibles bajo el parámetro

ni = Número de ítems que aplican
Np = (1/n)*ni
Nt = (∑Np)/4

De acuerdo a lo anterior, los niveles de vulnerabilidad encontrados para cada una de las
implementaciones frente los tres tipos de ataque definidos, bajo los diferentes parámetros
son:

8.2.1. Producto afectado

Tabla 14: Nivel de vulnerabilidad bajo el parámetro de producto afectado

Apache
Tipo de ataque Jersey RESTEasy Restlet
CXF
SQL Injection 75% 75% 75% 75%
XPATH Injection 75% 75% 75% 75%
Command Injection 100% 100% 100% 0%
94 Seguridad de JAX-RS frente a ataques

Gráfica N° 2: Vulnerabilidad por implementación

Restlet

Apache CXF

RESTEasy

Jersey

0% 50% 100% 150% 200% 250% 300%

SQL Injection XPATH Injection Command Injection

Gráfica N° 3: Vulnerabilidad por tipo de ataque

100%
80%
60%
40% Command Injection
20% XPATH Injection
SQL Injection
0%
Jersey RESTEasy Apache Restlet
CXF

SQL Injection XPATH Injection Command Injection

8.2.2. Ubicación
Tabla 15: Nivel de vulnerabilidad bajo el parámetro de ubicación

Apache
Tipo de ataque Jersey RESTEasy Restlet
CXF
SQL Injection 25% 25% 25% 25%
XPATH Injection 25% 25% 25% 25%
Command Injection 25% 25% 25% 0%
Seguridad de JAX-RS frente a ataques por inyección de código

Gráfica N° 4: Vulnerabilidad por implementación

Restlet

Apache CXF

RESTEasy

Jersey

0% 20% 40% 60% 80%

SQL Injection XPATH Injection Command Injection

Gráfica N° 5: Vulnerabilidad por tipo de ataque

25%

20%

15%

10%
Command Injection
5% XPATH Injection
SQL Injection
0%
Jersey RESTEasy Apache CXF Restlet

SQL Injection XPATH Injection Command Injection

8.2.3. Causa
Tabla 16: Nivel de vulnerabilidad bajo el parámetro de causa

Tipo de ataque Jersey RESTEasy Apache CXF Restlet

SQL Injection 25% 25% 25% 25%
XPATH Injection 25% 25% 25% 25%
Command Injection 50% 50% 50% 0%
96 Seguridad de JAX-RS frente a ataques

Gráfica N° 6: Vulnerabilidad por implementación

Restlet

Apache CXF

RESTEasy

Jersey

0% 20% 40% 60% 80% 100% 120%

SQL Injection XPATH Injection Command Injection

Gráfica N° 7: Vulnerabilidad por tipo de ataque

50%
40%
30%
20% Command Injection
10% XPATH Injection
SQL Injection
0%
Jersey RESTEasy Apache Restlet
CXF

SQL Injection XPATH Injection Command Injection

8.2.4. Impacto
Tabla 17: Nivel de vulnerabilidad bajo el parámetro de impacto

Tipo de ataque Jersey RESTEasy Apache CXF Restlet

SQL Injection 33% 33% 33% 33%
XPATH Injection 67% 67% 67% 67%
Command Injection 33% 33% 33% 0%
Seguridad de JAX-RS frente a ataques por inyección de código

Gráfica N° 8: Vulnerabilidad por implementación

Restlet

Apache CXF

RESTEasy

Jersey

0% 20% 40% 60% 80% 100% 120% 140%

SQL Injection XPATH Injection Command Injection

Gráfica N° 9: Vulnerabilidad por tipo de ataque

80%
60%
40% Command Injection
20% XPATH Injection
SQL Injection
0%
Jersey RESTEasy Apache Restlet
CXF

SQL Injection XPATH Injection Command Injection

8.2.5. Consolidado
Por último, se crea la tabla final con los niveles de vulnerabilidad promediados por cada
una de las cuatro implementaciones frente a los ataques previamente establecidos:

Tabla 18: Nivel de vulnerabilidad final

Apache
Tipo de ataque Jersey RESTEasy Restlet
CXF
SQL Injection 40% 40% 40% 40%
XPATH Injection 48% 48% 48% 48%
Command Injection 52% 52% 52% 0%
98 Seguridad de JAX-RS frente a ataques

Gráfica N° 10: Vulnerabilidad final por implementación

160%
140%
120%
100%
80%
60%
40%
20%
0%
Jersey RESTEasy Apache CXF Restlet

SQL Injection XPATH Injection Command Injection

Gráfica N° 11: Vulnerabilidad final por tipo de ataque

Niveles de vulnerabilidad

60%

50%

40%

30%

20%

10%

0%
Jersey RESTEasy Apache CXF Restlet

SQL Injection XPATH Injection Command Injection

Gráfica N° 12: Vulnerabilidad final por implementación y tipo de ataque

Seguridad de JAX-RS frente a ataques por inyección de código

60%
50%
40%
30%
20%
10% Command Injection
0% XPATH Injection
Jersey SQL Injection
RESTEasy
Apache CXF
Restlet

SQL Injection XPATH Injection Command Injection

8.3. ANÁLISIS DE RESULTADOS

Es importante realizar un análisis de los resultados anteriores con el fin de tener un
panorama general de las vulnerabilidades encontradas en cada una de las
implementaciones atacadas, para esto sirven de apoyo las tablas y gráficas del punto
anterior, las cuales describen estos resultados a nivel general.

En la

Tabla 14: Nivel de vulnerabilidad bajo el parámetro de producto afectado, se puede

observar una mayor afectación en los productos de software frente a los ataques
mediante Command injection, esto debido a la naturaleza del ataque, puesto que, con los
comandos del sistema operativo se logra atacar al servidor que contiene la aplicación y
por tanto cualquier sistema que se encuentre allí alojado, esto hace que el nivel de
vulnerabilidad aumente para este tipo de ataque.

En cuanto a la ubicación de la vulnerabilidad, cabe destacar que para todos los tipos de
ataque la vulnerabilidad aparece en el servicio RESTful, esto es importante debido a que
estos son el objetivo de este proyecto y además son las interfaces que otorgan las
aplicaciones Web a sistemas externos, siendo un punto de acceso al sistema que puede
ser aprovechado por los atacantes para lograr sus objetivos. Esto lo podemos observar en
la Tabla 15: Nivel de vulnerabilidad bajo el parámetro de ubicación.
 100 Seguridad de JAX-RS frente a ataques

A pesar de que la principal causa de la vulnerabilidad es la falta de cuidado de los

programadores, como se presenta en Tabla 16: Nivel de vulnerabilidad bajo el parámetro
de causa, se puede observar que tanto las implementaciones como la especificación de
JAX-RS no brindan mayores utilidades de seguridad frente a estos ataques y sigue siendo
responsabilidad completa del programador implementar todos los mecanismos de defensa
que tenga al alcance.

Es un resultado importante teniendo en cuenta que según la CWE, la mayoría de estos

ataques tienen éxito debido a los pobres mecanismos de defensa que implementan los
programadores. También vale la pena resaltar que los ataques mediante Command
injection son causados en parte por la baja configuración de seguridad que tiene el
servidor, ya que este permite ejecutar comandos del sistema operativo desde una
aplicación alojada allí sin medidas de verificación de permisos de usuario.

El impacto es tal vez uno de los criterios más importantes para medir el nivel de
vulnerabilidad, puesto que es el que indica el daño real que sufre el sistema atacado. En
este caso se observa en la Tabla 17: Nivel de vulnerabilidad bajo el parámetro de impacto
que los ataques por inyección XPATH son los que generan un mayor nivel de
vulnerabilidad, esto debido a que al ser usados en sistemas de autenticación, pueden
afectar tanto la confidencialidad de la información como la integridad del sistema ya que
un usuario indebidamente autenticado puede lograr privilegios de administración y realizar
un gran daño a todo el sistema.

Aunque los ataques realizados mediante Command injection no afectan directamente la

integridad ni la confidencialidad del sistema, pueden lograr acciones graves para cualquier
tipo de negocio que haga uso de información en red, puesto que, como en este caso se
puede lograr una denegación del servicio, que en algunos casos puede ser fatal para la
operación de un servicio o producto.

En cuanto al consolidado de los resultados, se observa como a pesar de que las distintas
implementaciones tengan un comportamiento similar respecto a los ataques, Restlet
ofrece un nivel de vulnerabilidad menor frente a command injection, esto debido a que los
scripts inyectados se formatean para que hagan parte de la URI, logrando así que el
sistema interprete este código como una ruta de un recurso, denegando la solicitud y por
tanto rechazando el ataque.

Es importante resaltar esta utilidad implícita que tiene Restlet, puesto que como se
observa en la Tabla 18: Nivel de vulnerabilidad final, command injection es el ataque bajo
el que presentan menor seguridad los servicios RESTful JAX-RS. Es interesante teniendo
en cuenta que la implementación de referencia de ORACLE es Jersey.

Por último vale la pena resaltar la poca diferencia que se observa por cada uno de los
tipos de ataque por inyección de código, ya que a pesar de que la fuente puede ser la
misma, la probabilidad de éxito y el objetivo del atacante pueden variar de manera
Seguridad de JAX-RS frente a ataques por inyección de código

significativa, ya sea su intención afectar la confidencialidad, la integridad o la

disponibilidad del sistema.

9. CONCLUSIONES
Actualmente no se cuenta con un software que realice análisis de vulnerabilidades a Rest
Services implementados con JAX-RS, la aproximación a este tipo de soluciones son
herramientas que realizan pruebas de penetración de seguridad a plataformas Web.

Las evaluaciones realizadas con estas herramientas no resultan ser totalmente efectivas
ya que no están enfocadas a una implementación específica y toda evaluación se realiza
por igual sin importar su lenguaje de programación, implementaciones o framework
utilizados, por lo que en ocasiones sus resultados no son específicos o no detectan algún
nivel de vulnerabilidad.

Con el fin de realizar un aporte a las evaluaciones realizadas a REST Service

implementadas con JAX-RS, se desarrolló un prototipo que implementa inyección de
código a las peticiones que consumen estos REST Services, esto con el fin de identificar
el nivel de vulnerabilidad de API.

Durante esta investigación se determinó que los principales inconvenientes de

vulnerabilidad presentados en aplicaciones JAX-RS, son causados por la forma en la cual
es codificado su código fuente, esto se debe al desconocimiento de la API JAX-RS y del
estilo de arquitectura REST.

Otro factor que está ligado a la mala codificación del servicio, es la falta de controles
específicos como son los filtros, validaciones y las malas prácticas de programación, las
cuales logran revelar y exponer los detalles del servicio, estos son indicios que informan
al atacante las vulnerabilidades presentadas en los REST Services.

Por otro parte los niveles de vulnerabilidad que se presentan sobre las implementaciones
JAX-RS se deben también a su objetivo principal, el cual es respetar el estilo de
arquitectura REST que está basado sobre el protocolo HTTP.

De esta manera un atacante puede tener control sobre cada bit de una petición realizada
al REST Service, logrando así poder modificar el estado del recurso solicitado.

Debido a que REST es un estilo de arquitectura aplicado a sistemas distribuidos,

podemos determinar al servidor y al cliente como actores de cada petición/respuesta, este
último tiene total control sobre la representación del recurso, quien también puede
inyectar algún método que altere el funcionamiento del REST Service.

Estas inyecciones de código son posibles debido a la forma en la cual se deben de

extraer los datos, es decir a través de mensajes HTTP. Las inyecciones son realizadas a
 102 Seguridad de JAX-RS frente a ataques

través del cliente, ya que como mencionamos anteriormente, él es quien tiene control total
sobre recurso, desde la petición hasta la respuesta.

Los textos de representación XML y JSON son otra entrada de vulnerabilidad, ya que por
defecto los analizadores comunes XML y JSON de Java, contienen una configuración
insegura que no contempla protección sobre estas representaciones, permitiendo al
atacante inyectar valores que alteren la representación y flujo de los recursos.

En el caso de nuestra aplicación, se inyectaron comandos de sistema operativo,

tautologías XML y sentencias SQL modificando la semántica de las URLs solicitadas,
logrando afectar la autenticidad, disponibilidad e integridad de la información de los REST
Services.

Por otra parte se pudo determinar que la implementación Restlet genera un buen nivel de
seguridad. Esto se debe gracias a la forma propia en la cual se codifica, captura y
procesan los datos de las peticiones, logrando que no sea tan factible la inyección de
parámetros HTTP.
Seguridad de JAX-RS frente a ataques por inyección de código

10. REFERENCIAS
[1] OWASP, “OWASP,” [Link], 2015. .

[2] E. J and C. Linksource, “SOA, Web Services, And RESTful Systems.,” World, 2007.

[3] E. J. Bruno, “SOA, Web Services, and RESTful Systems,” Dr. Dobb’s J. - ProQuest
Sci. Journals, vol. 1, p. 5, 2007.

[4] C. Davis, “What if the Web Were not RESTful?,” EMC Corp., vol. 1, p. 8, 2011.

[5] R. T. Fielding, “Architectural Styles and the Design of Network-based Software

Architectures,” Building, vol. 54, p. 162, 2000.

[6] M. Little, “A Comparison of JAX-RS Implementations,” infoq/news, 2008. .

[7] Q. U. É. Son, L. A. S. Vulnerabilidades, and D. E. L. Software, “¿Qué son las

vulnerabilidades del software?,” pp. 1–11, 2014.

[8] Edward Hunt, “US Government Computer Penetration Programs and the
gImplications for Cyberwar,” IEEE Ann. Hist. Comput., vol. 34, no. undefined, pp. 4–
21, 2012.

[9] OWASP, “OWASP Zed Attack Proxy Project,” OWASP Zed Attack Proxy Proj.,
2016.

[10] A. B. L. y Andrea Alarc�n Aldana y Mauro Callejas Cuervo, “Vulnerabilidad de

Ambientes Virtuales de Aprendizaje utilizando SQLMap, RIPS, W3AF y Nessus
[Vulnerability in Virtual Learning Environments using SQLMap, RIPS, W3AF and
Nessus],” Vent. Inform�tica, vol. 0, no. 30, 2014.

[11] W. G. J. Halfond and A. Orso, “AMNESIA: Analysis and Monitoring for NEutralizing
SQL-injection Attacks,” in Proceedings of the 20th IEEE/ACM International
Conference on Automated Software Engineering, 2005, pp. 174–183.

[12] S. W. Boyd and A. D. Keromytis, “SQLrand: Preventing SQL Injection Attacks,” in

Applied Cryptography and Network Security: Second International Conference,
ACNS 2004, Yellow Mountain, China, June 8-11, 2004. Proceedings, M. Jakobsson,
M. Yung, and J. Zhou, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2004,
pp. 292–302.

[13] M. SQL, “SQL Injection,” 2011.

[14] O. and/or its Affiliates, “Building RESTful Web Services with JAX-RS,” Oracle and/or
its affiliates, 2013. .

[15] J. Evdemon, “understanding services,” in SOA in the real World, 1st ed., 2011, p.
195.

[16] H. Li, “RESTful Web Service Frameworks in Java,” Informatiz. Off. Shanghai Lixin
 104 Seguridad de JAX-RS frente a ataques

Univ. Commer. Shanghai, 201620, China, vol. 1, p. 4, 2016.

[17] N. Balani and R. Hathi, Apache CXF Web Service Development. 2009.

[18] R. W. Services, “RESTEasy JAX-RS.”

[19] I. Rest, “7 implementaciones,” pp. 130–137.

[20] A. Wink, “Apache Wink 1.1,” pp. 3–121, 2010.

[21] M. Alfonso, Cifrado de las comunicaciones digitales, de la cifra clasica al algoritmo

RSA. 2006.

[22] I. K. Center, “Protección de recursos JAX-RS,” IBM Documentation, 2015. .

[23] C. Pautasso and E. Wilde, “RESTful Web Services: Principles, Patterns, Emerging
Technologies,” Raleigh • NC • USA, vol. 1, p. 2, 2010.

[24] U. Yael, “Entorno para Experimentación de Vulnerabilidades en la Ensenanza de

Buenas Practicas de Programación.”

[25] M. Fuksa and M. Gajdo, “Securing JAX-RS RESTful services.”

[26] Cwe, “CWE - 2011 cwe/sans top 25 most dangerous software errors,” SANS Inst.,
p. 41, 2011.

[27] A. Klein, “Blind XPath Injection,” pp. 1–10, 2004.

[28] “Live Experiments depicting SQL Injection Attacks,” pp. 91–93.

[29] J. M. Alonso, R. Bordon, M. Beltran, and A. Guzman, “LDAP injection techniques,”

in Communication Systems, 2008. ICCS 2008. 11th IEEE Singapore International
Conference on, 2008, pp. 980–986.

[30] Z. Su and G. Wassermann, “The Essence of Command Injection Attacks in Web

Applications,” in Conference Record of the 33rd ACM SIGPLAN-SIGACT
Symposium on Principles of Programming Languages, 2006, pp. 372–382.

[31] B. Sullivan, “Server-side JavaScript injection,” Black Hat USA, 2011.

[32] K.-J. Lin, “SMTP-1: The First Functionalized Metalloporphyrin Molecular Sieves with
Large Channels,” Angew. Chemie Int. Ed., vol. 38, no. 18, pp. 2730–2732, 1999.

[33] B. M. Bowen, V. P. Kemerlis, P. Prabhu, A. D. Keromytis, and S. J. Stolfo,

“Automating the injection of believable decoys to detect snooping,” in Proceedings
of the third ACM conference on Wireless network security, 2010, pp. 81–86.

[34] D. Html and C. S. S. Javascript, “Índice.”

[35] E. Janot and P. Zavarsky, “Preventing SQL Injections in Online Applications : Study
, Recommendations and Java Solution Prototype Based on the SQL DOM,” 2008.
Seguridad de JAX-RS frente a ataques por inyección de código

[36] C. Commons, “OWASP Top 10 2013 Los Diez Riesgos Más Críticos en
Aplicaciones Web,” p. 22, 2013.

[37] M. Montenegro, “Interfaces gráficas con Swing Introducción,” vol. 467.

[38] E. Moreno, “Web Page Development Web Page.”

[39] “Getting Started with AWS.”

[40] J. Yances and S. Murillo, “Software Requirements Specification,” pp. 1–31, 2008.

[41] F. De Ciencias and D. Administración, “Universidad del Azuay,” no. Vdi, 2015.

[42] F. Barnsteiner and M. Theis, “2011 [ RESTful Webservices mit,” 2011.

[43] C. Servlets, “Controlling g Web Application Behavior,” 2009.

[44] “Generic Webshop System with JPA.”