Asignatura Datos del alumno Fecha

Seguridad en Apellidos: Vilac Salazar

Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

Actividades

Trabajo: Seguridad en AJAX

Descripción de la actividad

Realización de un trabajo para recopilar los problemas de seguridad que presenta la

tecnología WEB 2.0 AJAX y las posibles soluciones a los mismos.

Pautas de elaboración

Esta actividad sobre seguridad en aplicaciones Ajax abarca los problemas de seguridad
que tienen este tipo de aplicaciones, que caen en la categoría denominada rich internet
applications y en las posibles soluciones a los mismos. Hay que consultar cuantas
fuentes relativas al tema se considere y sintetizar la información relevante sin limitarse
a copiar el contenido de alguna de ellas.

Criterios de valoración

Se valorará (para todas las actividades):

Contenidos. Para la realización de los trabajos se deben consultar varias fuentes

para después contrastarlas, sintetizarlas y generar un trabajo y opinión
personalizados aportando ejemplos gráficos.
Estructura del documento. Debe ser planificada previamente y tener un
apartado de conclusiones y de referencias al final.
Presentación acorde con la categoría del curso.
Referencias. Se deben especificar en un apartado al final todas las fuentes
consultadas, URL’s de internet, papers, artículos o libros especificando todos los
datos de la publicación disponibles. Recalcar la obligatoriedad de la especificación
de las referencias consultadas.

Extensión máxima: 10-15 páginas (fuente Georgia 11 e interlineado 1,5).

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

INTRODUCCCIÓN
La Web 2.0 se puede definir como la tendencia en evolución de las tecnologías www y el
diseño web que apuntan a mejorar la creatividad, las comunicaciones, el intercambio
seguro de información, la colaboración y la funcionalidad de la web 1.0. A diferencia de
la naturaleza estática de Web 1.0, los sistemas Web 2.0 dependen en gran medida del
contenido generado por el usuario, de hecho, la Web 2.0 se ha descrito como la "Web
participativa". Por ejemplo, los blogs y los servicios para compartir fotos permiten a los
consumidores agregar y actualizar su propio contenido. Ejemplos de tales tecnologías
incluyen AJAX, widgets y plataformas de aplicaciones como blogs, wikis y redes
sociales.

AJAX es una tecnología utilizada para permitir comunicación asíncrona entre el

navegador y el servidor web. Con Ajax, JavaScript crea objetos XMLHTTP. Estos
objetos pueden hacer peticiones y recibir respuesta de manera asíncrona, actualizando
la pantalla conforme se reciben respuestas. El objeto JavaScript “XMLHttpRequest” es
el corazón de Ajax. Permite a JavaScript hacer peticiones por datos en segundo plano,
proporcionando más interactividad sobre la página web. Tiene un número de métodos
y propiedades, pero cinco son las más críticos para hacer su trabajo y son: open, send,
onreadystatechange, readyState y responseText.

Para la mayoría de los usuarios la seguridad web es un tema irrelevante, pues al

interactuar con la aplicación del lado del cliente no toman en cuenta lo que se está
ejecutando por debajo o en el código fuente de la misma, por tal motivo, esto se
convierte en una ventaja para los atacantes que aprovechan para realizar ataques por el
lado del cliente o directamente a los servidores de la aplicación.

A pesar de la gran ventaja que la web 2.0 presenta a las organizaciones o empresas, fue
necesario que los directores de TI y oficiales de seguridad consideren realizar con
mayor frecuencia: auditorías, pruebas de funcionalidad y se adapten a modelos de
desarrollo seguro para mitigar en gran medida la perdida de información o ataques no
autorizados.

Entre alguno de los ataques a la web 2.0 se encuentran:

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

WSDL Scanning
El Lenguaje de descripción de servicios web (WSDL) permite que un servicio web
publicite sus capacidades describiendo las operaciones y los parámetros necesarios
para acceder al servicio. WSDL a menudo se genera automáticamente, utilizando
utilidades como Java2WSDL, que toma una clase o interfaz y crea un archivo WSDL en
el que los métodos de interfaz se exponen como servicios web.
Debido a que la generación de WSDL a menudo está automatizada, los atacantes
pueden usar WSDL para obtener información sobre los servicios tanto públicos como
privados. El atacante puede escanear la interfaz WSDL para revelar información
sensible acerca de patrones de invocación, implementaciones tecnológicas subyacentes
y las vulnerabilidades asociadas. Este tipo de sondeo se lleva a cabo para realizar
ataques más graves (por ejemplo, la manipulación de parámetros, inyección maliciosa
de contenido, inyección de comandos, etc.) archivos WSDL proporcionan información
detallada sobre los puertos de servicios y enlaces disponibles para los consumidores.

Alteración de parámetros SOAP

Un atacante envía un mensaje SOAP en el que los valores del campo son distintos a los
que el servidor probablemente esperará para precipitar el comportamiento del servidor
no estándar. En un mensaje SOAP, los parámetros toman la forma de valores dentro de
elementos XML. El servidor tendrá un esquema XML que indica ciertas restricciones
en estos valores de parámetros. Por ejemplo, el servidor puede esperar que un
parámetro sea una cadena con menos de 10 caracteres, o un número menor que 100.
En un ataque de manipulación de parámetros SOAP, un atacante viola este esquema o
aprovecha la flexibilidad dentro del esquema (ejemplo, falta de un límite de caracteres)
para proporcionar parámetros que un servidor podría no esperar. Algunos ejemplos de
parámetros inesperados incluyen datos sobredimensionados, datos con diferentes tipos
de datos, inserción de metacaracteres dentro de datos y envío de datos inapropiados
contextualmente (por ejemplo, envío de un nombre de producto inexistente en un
campo de nombre de producto o uso de un número de secuencia fuera de orden). Los
resultados de este ataque pueden incluir divulgación de información, denegación de
servicio o incluso ejecución de código arbitrario.

Xpath Injection
De forma similar a la inyección SQL, los ataques de inyección de XPath ocurren cuando
un sitio web usa información proporcionada por el usuario para construir una consulta

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

XPath para datos XML. Al enviar intencionalmente información mal formada al sitio
web, un atacante puede descubrir cómo se estructuran los datos XML o acceder a datos
a los que normalmente no puede acceder. Incluso puede elevar sus privilegios en el sitio
web si los datos XML se utilizan para la autenticación (como un archivo de usuario
basado en XML). Query XML se hace con XPath, un tipo de declaración descriptiva
simple que permite que la consulta XML encuentre una información. Al igual que SQL,
puede especificar ciertos atributos para buscar patrones que coincidan. Cuando se usa
XML para un sitio web, es común aceptar alguna forma de entrada en la cadena de
consulta para identificar el contenido que se va a ubicar y mostrar en la página. Esta
entrada se debe desinfectar para verificar que no estropee la consulta XPath y devuelva
los datos incorrectos.
XPath es un lenguaje estándar; su notación / sintaxis siempre es independiente de la
implementación, lo que significa que el ataque puede ser automático. No hay dialectos
diferentes ya que tiene lugar en las solicitudes a las bases de datos SQL. Como no hay
control de acceso de nivel, es posible obtener el documento completo

Atom Injection
Una nueva característica de la" Web 2.0 ", es la facilidad para construir una mayor
capacidad de respuesta en la Web, con la utilización de los flujos XML que utilizan los
RSS y estándares Atom. Estos permiten a los usuarios y los sitios web obtener el
contenido, titulares y texto del cuerpo sin la necesidad de visitar el sitio en cuestión,
básicamente, proporcionando a los usuarios un resumen de ese contenido.

Atom injection se trata de un nuevo ataque WEB 2.0. RSS, son un medio común de
intercambio de información sobre portales y aplicaciones web, estos datos son
almacenados por las aplicaciones web y enviados al navegador del lado del cliente, se
puede inyectar JavaScript en el RSS para generar ataques en el navegador y
aplicaciones web.

DOM-Based XSS.
DOM Based XSS (o también conocido como "type-0 XSS") es un ataque XSS en el que
la carga de ataque se ejecuta como resultado de modificar el "entorno" DOM en el
navegador de la víctima utilizado por el lado del cliente original script, para que el
código del lado del cliente se ejecute de manera "inesperada". Es decir, la página en sí
(la respuesta HTTP) no cambia, pero el código del lado del cliente contenido en la

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

página se ejecuta de manera diferente debido a las modificaciones maliciosas que se

han producido en el entorno DOM. Las vulnerabilidades de scripts de sitios XSS se
producen cuando:
 Los datos entran en una aplicación web a través de una fuente no confiable. En
el caso de XSS basado en DOM, los datos se leen desde un parámetro de URL u
otro valor dentro del explorador, y se escriben en la página con código del
cliente. En el caso de XSS reflejado, la fuente no confiable suele ser una
solicitud web, mientras que en el caso de XSS persistente (también conocido
como almacenado) suele ser una base de datos u otro almacén de datos
backend.
 Los datos se incluyen en el contenido dinámico que se envía a un usuario web
sin que se validen. En el caso de XSS basado en DOM, el contenido
malintencionado se ejecuta como parte de la creación de DOM (Modelo de
objetos de documento), siempre que el explorador de la víctima analice la
página HTML.
El contenido malintencionado que se envía al explorador web a menudo adopta la
forma de un segmento de código JavaScript, pero también puede incluir código HTML,
Flash o cualquier otro tipo de código que el explorador pueda ejecutar. La variedad de
los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión de datos
privados como cookies u otra información de sesión al usuario malintencionado, re
direccionando a la víctima a un contenido web que este controla o realizar otras
operaciones malintencionadas en el equipo del usuario bajo la apariencia del sitio
vulnerable.
Ejemplo: Imaginar la siguiente página: http://www.example.com/test.html la cual
contiene el siguiente código:

<script>
document.write("<b>Current URL</b> : " + document.baseURI);
</script>

Si se envía una solicitud HTTP como esta:

http://www.example.com/test.html# <script> alerta (1) </ script>
el código JavaScript se ejecutará con la suficiente sencillez, porque la página está
escribiendo lo que sea que desee escrito en la URL de la página con la función
document.write. Si mira el origen de la página, no verá <script> alerta (1) </ script>
porque todo está sucediendo en el DOM y hecho por el código JavaScript ejecutado.

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

Después de que el código malicioso se ejecuta por página, puede aprovechar esta
vulnerabilidad de scripts entre sitios basada en DOM para robar las cookies del usuario
o cambiar el comportamiento de la página como desee.
A continuación, se muestra una lista de fuentes y sumideros que generalmente se
dirigen a los ataques DOM XSS, tomando en consideración que no es una lista
completa:

Codigos populares
- document.URL
- document.documentURI
- location.href
- location.search
- location.*
- window.name
- document.referrer

Sinks populares:
- HTML Modification sinks
 document.write
 (element).innerHTML
- HTML modification to behaviour change
 (element).src (in certain elements)
- Execution Related sinks
 eval
 setTimout / setInterval
 execScript

AJAX (Asynchronous Javascript) and XML

Es una técnica que permite presentar la información con CSS y DOM. Esta técnica
permite crear aplicaciones interactivas, las cuales se ejecutan en el lado del
cliente, en el navegador. El funcionamiento de AJAX es sencillo, mientras la
aplicación se ejecuta en el navegador del cliente, la comunicación se lleva a cabo de
manera asíncrona en segundo plano con el servidor. Esto permite crear el efecto de que
el sitio web va cambiando en función de las necesidades, por la actualización de la
información en el servidor, el cual podría ser debido a otras acciones del cliente. Sin

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

embargo esta característica exige un mayor grado de seguridad ya que la comunicación

de manera asíncrona entre el cliente y el servidor tiende a estar hecho de código poco
seguro, para que la información no se vea comprometida todo el tráfico debe ser
debidamente comprobado.
La probabilidad y exposición de ataque en el lado del cliente es grande, la revelación
de la lógica de la aplicación hace que los posibles atacantes conozcan parte del código
ya que reside en esta parte permitiéndoles estudiar e inferir de cierto modo la lógica de
esta. El gran número de líneas de código y su dificultad para revisarlas hace que la
revisión de las aplicaciones multiplique su dificultad aumentando la vulnerabilidad de
la aplicación, así como también su auditoria.
Ajax como técnica novedosa es utilizada por un sin número de programadores para
brindar una experiencia similar a trabajar en “local”, sin embargo y sumado a lo
anteriormente mencionado tenemos unas características de seguridad que no han sido
solventadas en su totalidad, tales como:
- Al existir más “inputs” hay más puntos que proteger
- Las funciones internas se encuentran expuestas
- No contiene mecanismos de codificación bien definidos cuando un cliente accede a
determinados recursos
- No es muy seguro a la hora de proteger la información de sesiones y
autenticaciones

RIA thick client binary manipulation

Las aplicaciones de Internet enriquecidas (RIA) utilizan características de interfaz de
usuario muy ricas como Flash, controles ActiveX o Applets como sus principales
interfaces para las aplicaciones web. Hay algunos problemas de seguridad con este
marco. Uno de los principales problemas es con la gestión de sesión, ya que se ejecuta
en el navegador y comparte la misma sesión. Al mismo tiempo, dado que todo el
componente binario se descarga a la ubicación del cliente, un atacante puede realizar
una ingeniería inversa del archivo binario y descompilar el código. Es posible parchear
estos binarios y eludir parte de la lógica de autenticación contenida en el código.

XML poisoning
El tráfico XML va y viene entre el servidor y el navegador en muchas de las aplicaciones
WEB 2.0. Las aplicaciones web consumen bloques XML provenientes de clientes AJAX,
lo cual posibilita envenenar este bloque XML. No es raro que la técnica aplique cargas

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

útiles recursivas a nodos XML de producción similar varias veces. Si el manejo del
motor es pobre, esto puede provocar la denegación de servicios en el servidor. Muchos
atacantes también producen documentos XML con formato incorrecto que pueden
interrumpir la lógica dependiendo de los mecanismos de análisis utilizados en el
servidor. Hay dos tipos de mecanismos de análisis disponibles en el lado del servidor:
SAX y DOM. Este mismo vector de ataque también se usa con los servicios web, ya que
consumen mensajes SOAP y los mensajes SOAP no son más que mensajes XML.

Un atacante corrompe o modifica el contenido de la información del esquema XML

pasado entre un cliente y un servidor con el fin de socavar la seguridad del objetivo. Los
esquemas XML proporcionan la estructura y las definiciones de contenido para
documentos XML. La intoxicación por esquema es la capacidad de manipular un
esquema, ya sea reemplazándolo o modificándolo para comprometer los programas
que procesan documentos que usan este esquema. Los posibles ataques son ataques de
denegación de servicio al modificar el esquema para que no contenga la información
requerida para su posterior procesamiento. Por ejemplo, el esquema inalterado puede
requerir un atributo @name en todos los documentos enviados. Si el atacante elimina
este atributo del esquema, los documentos creados con la nueva gramática pueden
carecer de este campo, lo que puede hacer que la aplicación de procesamiento ingrese
un estado inesperado o registre datos incompletos. Además, la manipulación de los
tipos de datos descritos en el esquema puede afectar los resultados de los cálculos
realizados por el lector de documentos. Por ejemplo, un campo flotante podría
cambiarse a un campo int. Finalmente, el atacante puede cambiar la codificación
definida en el esquema para ciertos campos, permitiendo que el contenido eluda los
filtros que escapan cadenas peligrosas.

Malicious AJAX code execution

Las llamadas de AJAX son muy silenciosas y los usuarios finales no podrían determinar
si el navegador realiza o no llamadas silenciosas utilizando el objeto
XMLHTTPRequest. Cuando el navegador realiza una llamada AJAX a cualquier sitio
web, reproduce las cookies para cada solicitud. Esto puede conducir a posibles
oportunidades de compromiso. Por ejemplo, John inició sesión en su banco y se
autenticó en el servidor. Después de completar el proceso de autenticación, obtiene una
cookie de sesión. La página de su banco tiene mucha información crítica. Ahora explora
otras páginas mientras aún está conectado a la página web de la cuenta de su banco y

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

aterriza en la página web de un atacante. En esta página, el atacante ha escrito un

código silencioso AJAX que realiza llamadas de fondo a su banco sin el consentimiento
de John, obtiene información crítica de las páginas y envía esta información al sitio web
del atacante. Esto conduce a una brecha de seguridad y una fuga de información
confidencial.

Same Origin Policy (política de origen)

Same Origin Policy es una característica de seguridad que se encuentra en la ejecución
de JavaScript en los navegadores, así como en otras tecnologías utilizadas en un
navegador, por ejemplo, Flash. Básicamente le permite hacer peticiones a páginas
dentro del mismo sitio / dominio, mientras que le impide hacer peticiones a páginas en
un dominio diferente, otro subdominio o por medio de un protocolo diferente. Esta
política de seguridad, nos va a evita muchos ataques desde fuera pero también supone
un problema para los desarrolladores debido a que limita los recursos a los que desean
acceder.

POSIBLES SOLUCIONES:

Inyección XPATH
Al igual que las técnicas para evitar la inyección SQL, se debe utilizar una interfaz
XPath parametrizada, si hay una disponible, o escapar de la entrada del usuario para
que sea seguro incluirla en una consulta construida dinámicamente. Si está utilizando
comillas para finalizar la entrada que no es de confianza en una consulta XPath
construida dinámicamente, entonces necesita escapar esa cita en la entrada no
confiable para asegurarse de que los datos no confiables no intenten salir del contexto
citado. En el siguiente ejemplo, las comillas simples (') se utilizan para finalizar los
parámetros de nombre de usuario y contraseña. Por lo tanto, debemos reemplazar
cualquier 'caracteres en esta entrada con la versión codificada en XML de ese carácter,
que es "& apos;"

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

Otra opción de mitigación más segura es usar una consulta XPath precompilada. Las
consultas XPath precompiladas ya están preestablecidas antes de que se ejecute el
programa, en lugar de crearse sobre la marcha después de que la entrada del usuario se
haya agregado a la cadena.

DOM Cross-site
La mejor forma de arreglar scripts entre sitios basados en DOM es usar el método de
salida correcto (sink). Por ejemplo, si desea utilizar la entrada del usuario para escribir
en un elemento <div>, no use innerHtml, en su lugar use innerText/textContent.
Esto resolverá el problema, y es la forma correcta de remediar las vulnerabilidades XSS
basadas en DOM.

Siempre es una mala idea usar una entrada controlada por el usuario en fuentes
peligrosas como eval. El 99% de las veces es una indicación de mala o floja práctica de
programación, así que simplemente no lo hagas en lugar de tratar de desinfectar la
entrada.

Finalmente, para solucionar el problema en nuestro código inicial, en lugar de intentar

codificar la salida correctamente, lo cual es una molestia y puede fallar fácilmente,
simplemente usaríamos element.textContent para escribirlo en un contenido como
este:
<b>Current URL:</b> <span id="contentholder"></span>

<script>
document.getElementById("contentholder").textContent =
document.baseURI;
</script>

Otras medidas de seguridad a tomar en cuenta son:

 El código de Javascript se debe ejecutar mediante el uso de una sandbox, con lo
que todo lo malicioso que se intente ejecutar queda aislado y sin acceso a los
recursos de interés de la máquina atacada.
 No establecer conexiones con sitios diferentes del nombre de dominio del que se
ha obtenido el script de Javascript. De este modo se puede proteger de
problemas de seguridad y esta medida se denomina CORS, Cross-Origin
Resource Sharing.

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

 Los ficheros Javascript que se han obtenido desde un sitio en concreto no deben
poder acceder a propiedades de otro sitio.
 Validación de todos los campos de entrada y comprobación siempre en el lado
del servidor, de otra manera cualquier acción que se valide en el cliente puede
ser manipulada, por ejemplo, mediante el uso de un proxy.
 Implantar controles de seguridad como pueden ser autenticación, autorización,
e incluso registro de operaciones o logging, siempre en el lado del servidor.
 Utilizar métodos POST en vez de métodos GET.
 Se debe tener en cuenta los ataques clásicos como SQLi, XSS y XSRF, los cuales
podrán ser solventados mediante un filtrado correcto o utilización de tokens
correctamente en el caso del XSRF.
 No almacenar jamás datos sensibles o confidenciales en el lado del cliente, este
hecho haría que obtenerlos por un atacante fuera algo potencialmente sencillo.
 Utilización de métodos criptográficos para transmitir datos sensibles o
confidenciales entre el cliente y el servidor.
 La lógica de negocio debe tener el principio de mínima exposición y encontrarse
siempre en el lado del servidor.
 Toda petición realizada con AJAX y que acceda a recursos protegidos deberán
encontrarse autenticadas.

CONCLUSIONES:
- Las auditorias y el uso de S-SDLC es algo completamente necesario en las
empresas para minimizar la ocurrencia de las posibles amenazas que se han
expuesto inicialmente.
- El uso de AJAX en aplicaciones web ha generado un importante cambio en la
forma de percibir servicios y recursos especialmente en el lado de cliente, pero
también ha creado brechas de seguridad que deben ser corregidos para
garantizar la continuidad del servicio. Todo esto requiere de mayor seguridad
por parte de los desarrolladores y de generar documentación detallada que
permita llevar de manera ordenada y planificada las aplicaciones web para
evitar fallas de seguridad.
- La concientización a los usuarios sobre la seguridad en la web a través de
protocolos seguros (SSL) se está haciendo cada vez mayor e importante para las
empresas, pues a medida que protege sus servicios, ofrece mayor seguridad,
confiabilidad e integridad a sus clientes.

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

- Al ser el cliente el que puede enviar varias entradas arbitrarias hacia la

aplicación del servidor es necesario considerar la regla de mínimos privilegios,
es decir, la aplicación debe asumir que todas las entradas son maliciosas y que
se debe tomar las medidas de seguridad necesarias para que los atacantes no
puedan utilizar dichas entradas para comprometer el servicio.
- La mayoría de ataques contra aplicaciones web incluyen el envío de entradas
hacia el servidor para causar algún evento no esperado o deseado por el
diseñador de la aplicación.
- Las amenazas y ataques en internet se caracterizan por el robo de información,
vulnerabilidad de datos, desarrollo de código malicioso, cuyo objetivo principal
es apoderarse de información confidencial y lograr beneficios económicos de
organizaciones específicas.

Webgrafía:
 https://capec.mitre.org/data/definitions/95.html
 https://capec.mitre.org/data/definitions/280.html
 https://www.owasp.org/index.php/XPATH_Injection
 http://www.cgisecurity.com/rss.html
 https://www.owasp.org/index.php/DOM_Based_XSS
 https://www.helpnetsecurity.com/2006/10/09/top-10-web-20-attack-vectors/
 https://go-gaga-over-testing.blogspot.com/2010/10/web-20-security-testing-
approach-make.html
 https://www.netsparker.com/blog/web-security/dom-based-cross-site-
scripting-vulnerability/
 http://www.jquery-tutorial.net/ajax/same-origin-policy/
 http://librosweb.es/libro/ajax/capitulo_7/seguridad.html
 http://sedici.unlp.edu.ar/bitstream/handle/10915/21581/1927+-
+Seguridad+de+aplicaciones+web+vulnerabilidades+en+los+controles+de+ac
ceso.pdf?sequence=1
 https://www.pcworld.es/articulos/boletin-de-noticias/las-nuevas-amenazas-a-
la-seguridad-en-la-web-20-510347/

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)

 Asignatura Datos del alumno Fecha
Seguridad en Apellidos: Vilac Salazar
Aplicaciones Online 04/04/2018
y Bases de Datos Nombre: Janny David

TEMA 1 – Actividades © Universidad Internacional de La Rioja (UNIR)