[WP] SQLi || XSS. Resumen

El tema del día de hoy en el grupo de Whatsapp es: SQLi || XSS
Podéis dejar aportes o documentación en este post.

Saludos
Gabriela

---

---

---

Resumen. Gracias a los aportes de @No tienes permitido ver los links. Registrarse o Entrar a mi cuenta  podemos sintetizar que en este post encontrarás:

-Un marco teórico mínimo de los ataques SQLi y algunos ejemplos prácticos.
-Funcionamiento y vulnerabilidad de SQLi.

-Ataque XSS. Conceptos teóricos: qué y cómo funcionan. Consejos para evitarlos o mitigarlos.

-Documentación.

Detección de ataques de inyección de SQL y de secuencias de comandos entre sitios

Introducción

En los últimos años, los ataques contra la capa de aplicación web han requerido una mayor atención por parte de los profesionales de seguridad. Esto se debe a que no importa cuán fuertes sean tus conjuntos de reglas de firewall o cuán diligente sea tu mecanismo de revisión, si tus desarrolladores de aplicaciones Web no han seguido prácticas seguras de codificación, los atacantes entrarán directamente a tus sistemas a través del puerto 80. Las dos principales técnicas de ataque Han sido ampliamente utilizados son los ataques SQL Injection [ref 1] y Cross Site Scripting [ref 2]. SQL Injection se refiere a la técnica de insertar meta-caracteres SQL y comandos en campos de entrada basados ​​en Web para manipular la ejecución de las consultas SQL de back-end. Se trata de ataques dirigidos principalmente contra el servidor Web de otra organización. Los ataques de Cross Site Scripting funcionan incrustando etiquetas de scripts en URLs y atrayendo a usuarios desprevenidos para hacer clic en ellos, asegurándose de que el Javascript malicioso se ejecute en la máquina de la víctima. Estos ataques aprovechan la confianza entre el usuario y el servidor y el hecho de que no hay validación de entrada / salida en el servidor para rechazar caracteres Javascript.

En este artículo se describen técnicas para detectar ataques SQL Injection y Cross Site Scripting (CSS) contra sus redes. Ha habido mucha discusión sobre estas dos categorías de ataques basados ​​en Web sobre cómo llevarlos a cabo, su impacto y cómo prevenir estos ataques usando mejores prácticas de codificación y diseño. Sin embargo, no hay suficiente discusión sobre cómo estos ataques pueden ser detectados. Tomamos el popular IDS de código abierto Snort [ref 3], y componemos reglas de expresión regular basada en la detección de estos ataques. Incidentalmente, el conjunto de reglas por defecto en Snort contiene firmas para detectar secuencias de comandos entre sitios, pero éstas pueden evadirse fácilmente. La mayoría de ellos pueden ser eludidos mediante el uso de valores hexadecimales de cadenas como% 3C% 73% 63% 72% 69% 70% 74% 3E en lugar de <script>.

Hemos escrito múltiples reglas para detectar el mismo ataque dependiendo del nivel de paranoia de la organización. Si desea detectar todos y cada uno de los posibles ataques de Inyección de SQL, entonces simplemente tendrá que prestar atención a cualquier ocurrencia de meta-caracteres SQL, como la comilla simple, el punto y coma o el doble guión. Del mismo modo, una forma paranoica de comprobar los ataques CSS sería simplemente mirar hacia fuera para los corchetes angulados que significan una etiqueta HTML. Pero estas firmas pueden resultar en un alto número de falsos positivos. Para evitar esto, las firmas pueden modificarse para que sean precisas, sin embargo, no producen demasiados falsos positivos.

Cada una de estas firmas puede usarse con o sin otros verbos en una firma de Snort usando la palabra clave pcre [ref 4]. Estas firmas también se pueden usar con una utilidad como grep para pasar por los registros del servidor Web. Pero la advertencia es que la entrada de usuario está disponible en los registros del servidor Web sólo si la aplicación utiliza solicitudes GET. Los datos sobre solicitudes POST no están disponibles en los registros del servidor Web.

Expressiones regulares para la inyección de SQL

Un punto importante a tener en cuenta al elegir su expresión regular (s) para detectar ataques de inyección de SQL es que un atacante puede inyectar SQL en la entrada tomada de un formulario, así como a través de los campos de una cookie. Su lógica de validación de entrada debe considerar cada tipo de entrada que se origina desde el usuario - ya sea campos de formulario o información de cookies - como sospechoso. También si descubre demasiadas alertas procedentes de una firma que busca una comilla simple o un punto y coma, puede ser que uno o más de estos caracteres sean entradas válidas en las cookies creadas por su aplicación web. Por lo tanto, tendrá que evaluar cada una de estas firmas para su aplicación web en particular.

Como se mencionó anteriormente, una expresión regular trivial para detectar ataques de inyección SQL es observar los meta-caracteres específicos de SQL, como el single-quote (') o el doble guión (-). Con el fin de detectar estos caracteres y sus equivalentes hex, la siguiente expresión regular puede ser utilizado:

Regex for detection of SQL meta-characters
/(\%27)|(\')|(\-\-)|(\%23)|(#)/ix

Explanation:
We first detect either the hex equivalent of the single-quote, the single-quote itself or the presence of the double-dash. These are SQL characters for MS SQL Server and Oracle, which denote the beginning of a comment, and everything that follows is ignored. Additionally, if you're using MySQL, you need to check for presence of the '#' or its hex-equivalent. Note that we do not need to check for the hex-equivalent of the double-dash, because it is not an HTML meta-character and will not be encoded by the browser. Also, if an attacker tries to manually modify the double-dash to its hex value of %2D (using a proxy like Achilles [ref 5]), the SQL Injection attack fails.

The above regular expression would be added into a new Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(\')|(\-\-)|(%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5;)

In this case, the uricontent keyword has the value ".pl", because in our test environment, the CGI scripts are written in Perl. Depending upon your particular application, this value may be either ".php", or ".asp", or ".jsp", etc. From this point onwards, we do not show the corresponding Snort rule, but instead only the regular expressions that are to be used for creating these rules. From the regular expressions you can easily create more Snort rules.

In the previous regular expression, we detect the double-dash because there may be situations where SQL injection is possible even without the single-quote [ref 6]. Take, for instance, an SQL query which has the where clause containing only numeric values. Something like:

select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number

In this case, the attacker may execute an additional SQL query, by supplying an input like:

3; insert values into some_other_table

Finally, pcre modifiers 'i' and 'x' are used in order to match without case sensitivity and to ignore whitespaces, respectively.

The above signature could be additionally expanded to detect the occurrence of the semi-colon as well. However, the semi-colon has a tendency to occur as part of normal HTTP traffic. In order to reduce the false positives from this, and also from any normal occurrence of the single-quote and double-dash, the above signature could be modified to first detect the occurrence of the = sign. User input will usually occur as a GET or a POST request, where the input fields will be reflected as:

username=some_user_supplied_value&password=some_user_supplied_value

Therefore, the SQL injection attempt would result in user input being preceded by a = sign or its hex equivalent.

Regex modificado para la detección de meta-caracteres SQL
(\% 3B) | (\)) / i (\% 3)

Explicación:
Esta firma busca primero el signo = o su equivalente hexadecimal (% 3D). A continuación, admite cero o más no caracteres de nueva línea y, a continuación, comprueba para la comilla simple, el doble guión o el punto y coma.

Regex para ataque típico de inyección de SQL
/ \ W * ((\% 27) | (\ ')) / (%%))

Explicación:
\ W * - cero o más caracteres alfanuméricos o subrayados
(\% 27) | \ '- la cita única omnipresente o su equivalente hexadecimal
(\% 6F) | o | (\% 4F)) (\% 72) | r | (\% 52) - la palabra 'o' con varias combinaciones de sus equivalentes de mayúsculas y minúsculas.

El uso de la consulta SQL 'union' también es común en los ataques de Inyección de SQL contra una variedad de bases de datos. Si la expresión regular anterior que sólo detecta los caracteres meta de una sola cotización u otros meta SQL da como resultado demasiados positivos falsos, puede modificar adicionalmente la consulta para comprobar específicamente la comilla única y la palabra clave 'unión'. Esto también se puede extender a otras palabras clave de SQL como 'select', 'insert', 'update', 'delete', etc.

Regex para detectar SQL Injection con la palabra clave UNION

/ ((\% 27) | (\ ')) union / ix
(\% 27) | (\ ') - la comilla simple y su equivalente hexadecimal
Union - la palabra clave union

Se pueden escribir expresiones similares para otras consultas SQL, tales como> seleccionar, insertar, actualizar, eliminar, omitir, etc.

Si, en esta etapa, el atacante ha descubierto que la aplicación Web es vulnerable a la inyección de SQL, intentará explotarla. Si se da cuenta de que la base de datos de back-end está en un servidor MS SQL, normalmente intentará ejecutar uno de los muchos procedimientos almacenados almacenados y extendidos. Estos procedimientos comienzan con las letras 'sp' o 'xp' respectivamente. Normalmente, intentaría ejecutar el procedimiento extendido 'xp_cmdshell', que permite la ejecución de comandos de shell de Windows a través de SQL Server. Los derechos de acceso con los que se ejecutarán estos comandos son los de la cuenta con la que se ejecuta SQL Server, normalmente Sistema local. Como alternativa, también puede intentar modificar el registro utilizando procedimientos como xp_regread, xp_regwrite, etc.

Cómo funciona SQL Injection, seguro eres vulnerable

Las vulnerabilidades más comunes en aplicaciones web según la OWASP (Open Web Application Security Project) son las de tipo inyección, a través de estas un usuario malintencionado puede enviar comandos o consultas con el fin de obtener datos o realizar ciertas acciones.

SQL Injection es una vulnerabilidad que permite a un atacante realizar consultas a una base de datos, se vale de un incorrecto filtrado de la información que se pasa a través de los campos y/o variables que usa un sitio web, es por lo general usada para extraer credenciales y realizar accesos ilegítimos, práctica un tanto neófita, ya que un fallo de este tipo puede llegar a permitir ejecución de comandos en el servidor, subida y lectura de archivos, o peor aún, la alteración total de los datos almacenados.

Una vulnerabilidad de tipo SQL Injection puede ser explotada tanto a través del método GET como del método POST. La práctica más común es hacerlo a través del primero, sin embargo hacerlo a través del método POST puede llegar a devolver los mismos resultados. En el mundo de la seguridad informática quienes descubren o investigan vulnerabilidades suelen hacer scripts que automatizan la explotación de las mismas, para el caso de SQL Injection las más comunes son:

    Sqlmap: Tal vez la más famosa, desarrollada en python por Bernardo Damele y Miroslav Stampar.
    Havij: Desarrollada por la empresa ITSecTeam.
    SqlNinja: Desarrollada en Perl, usada para explotar aplicaciones web que usan como back-end a Microsoft Sql Server.

Cómo es un ataque a una aplicación web vulnerable

Vamos a realizar un ataque a una aplicación web vulnerable, la forma más común de encontrar errores es a través del uso de una comilla (caracter de escape) en un input, para este caso una variable que se envía por GET:



l probar poner la comilla junto al parámetro que se está enviando a la base de datos y ejecutarse la consulta deforme tenemos como resultado un error de sintaxis SQL, lo que nos está indicando la no validación de la sentencia y por tanto la vulnerabilidad.



Para explotarla usaremos Sqlmap ya que el proceso manual puede llegar a convertirse en algo tedioso y en ocasiones muy prolongado. Para usar esta herramienta debemos tener instalado Python, en nuestro caso estamos trabajando sobre Bugtraq 2, una distribución de seguridad informática que tiene instalado por defecto lo que necesitamos.

Lo primero que haremos es pedirle a sqlmap que nos revele qué bases de datos la aplicación web está usando a través del comando --dbs, no sin antes indicarle a través de -u la url con el parámetro vulnerable:

Código :

python sqlmap.py -u "http://192.168.1.37/cat.php?id=1" --dbs

Una vez tenemos la base de datos necesitamos saber qué tablas tiene:

Código :

python sqlmap.py -u "http://192.168.1.37/cat.php?id=1" -D photoblog --tables

Y en el árbol descendente lo siguiente son las columnas:

Código :

python sqlmap.py -u "http://192.168.1.37/cat.php?id=1" -D photoblog -T users --columns

Y la línea que nos dará las credenciales de los "users" registrados:

Código :

python sqlmap.py -u "http://192.168.1.37/cat.php?id=1" -D photoblog -T users -C login,password --dump

Sqlmap detecta que al hacer el dump las "password" están encriptadas en MD5 por lo que propone descifrar, aceptamos que lo haga y voila!


Accedemos a la sección "admin" de nuestra aplicación y nos encontramos un upload de imágenes, probamos subiendo una shell PHP que nos pueda dar acceso al servidor y permita ejecutar comandos, listar directorios y archivos e incluso hacer escalaciones de privilegios o ataques Symlink.




Se ha bypasseado el filtro, ahora solo resta ir al index del sitio, buscar el link de la shell en el código y acceder:


pwned!, con tan solo explorar las opciones nos daremos cuenta de lo que podemos hacer en el servidor:



Fuente No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Que Es Ataque XSS

¿Cómo funciona un XSS?

En primer lugar es importante tener en cuenta que con esta vulnerabilidad, los atacantes explotan la confianza que un usuario tiene en un sitio en particular, y esto nos da una dimensión del impacto que puede tener.

Este tipo de vulnerabilidad puede ser explotada de dos maneras: de forma reflejada y de forma almacenada. A continuación, haré una breve explicación de cada una.

    Reflejada

Consiste en modificar valores que la aplicación web usa para pasar variables entre dos páginas. Un clásico ejemplo de esto es hacer que a través de un buscador se ejecute un mensaje de alerta en JavaScript. Con XSS reflejado, el atacante podría robar las cookies para luego robar la identidad, pero para esto, debe lograr que su víctima ejecute un determinado comando dentro de su dirección web.

Para esto, los cibercriminales suelen enviar correos engañosos para que sus víctimas hagan clic en un enlace disfrazado y así se produzca el robo.

    Almacenada

Consiste en insertar código HTML (programación web) peligroso en sitios que lo permitan; de esta forma quedará visible a los usuarios que ingresen en el sitio modificado.
¿Qué significa que un sitio web es vulnerable a XSS?

Si un sitio web contiene esta vulnerabilidad, un atacante puede realizar diversos tipos de ataques basándose en la confianza que inspira la plataforma en el usuario. Desde redirigir a otro sitio para robar información mediante phishing, hasta hacer que se descargue alguna amenaza y se ejecute en el sistema.

En última instancia, un Cross-site Scripting puede volver peligroso para sus usuarios a un sitio legítimo.
¿Por qué o como se produce esta vulnerabilidad?

Normalmente se debe a la falta o poca frecuencia de los controles necesarios en el sitio, pensados para evitar la ejecución de comandos desde la misma página web. A raíz de esto, un ciberdelincuente puede lograr ejecutar scripts (pequeños programas) en lenguajes como Java Script o HTML, entre otros.

Los scripts son una serie de instrucciones a ejecutar, que pueden estar programados en Java, HTML o cualquier otro lenguaje siempre y cuando el entorno donde se vaya a ejecutar sea compatible. Si bien el uso de scripts ayuda a automatizar muchas tareas a los administradores, también son utilizados por atacantes para automatizar sus ataques, haciendo que estos pequeños programas trabajen por sí solos robando información cuando la víctima accede al sitio vulnerado.
XSS en la práctica

Para comprender cómo funciona, lo trasladaremos a una situación que puede ser cotidiana a modo de ejemplo. Suponemos el siguiente escenario:

    Por un lado, el servidor "A" que pertenece a "mibanco.com", el cual es vulnerable a XSS
    Por el otro lado, un atacante que consigue inyectar código malicioso en "mibanco.com" mediante la explotación de XSS. El código que inyecta hace que, una vez que el usuario accede, sea enviado a otro sitio web exactamente igual a "mibanco.com"
    El usuario víctima accede desde su navegador a "mibanco.com"; sin embargo, al ejecutar el código malicioso inyectado por el atacante (sin saberlo), estará registrando sus datos en sitio clon del original. Por supuesto que esto compromete por completo su información financiera

Este solo es un ejemplo de una de las consecuencias de esta falta de controles, aunque también podría pasar que el sitio descargue malware o algún tipo de exploit que se aproveche de alguna vulnerabilidad en el sistema de su víctima, para lograr obtener acceso a su equipo personal.
¿Cómo puedes evitar ser víctima de XSS?

En primer lugar es fundamental, como siempre mencionamos, que cuentes con una solución de seguridad instalada y actualizada. Esto es importante ya que ante la ejecución de alguna aplicación maliciosa sin tu consentimiento, tal como malware o exploits, automáticamente será bloqueada.

Además, si se trata de una redirección a algún sitio de phishing, se cuenta con la protección del antivirus y el bloqueo proactivo por parte de los navegadores.

En segundo lugar, es muy importante que estés siempre atento a dónde ingresas: siempre es bueno mirar la dirección URL a la que se está accediendo. Ya hemos visto ejemplos de esto, como por ejemplo las redirecciones de Facebook, que pueden ser aprovechadas por atacantes, si no se tienen en cuenta algunos consejos, como ya hemos visto anteriormente, aquí dejamos 7 consejos para todos aquellos que les guste explorar Internet.

Por otro lado, existen complementos para los navegadores que se encarga de bloquear estos scripts en sitios web. Uno de ellos es NoScript, que permite realizar configuraciones personalizadas (y es gratuito).

Finalmente, nunca es una mala opción utilizar navegadores alternativos, quizás no tan populares, como Opera, Comodo o Chromium, entre otros. De esta forma, si un atacante lanza un ataque que intenta explotar alguna vulnerabilidad en uno de los navegadores más conocidos a través de un exploit, al no cumplirse las condiciones para la explotación exitosa de la vulnerabilidad, esto denegará el acceso al sistema.

A veces algunas de estas vulnerabilidades exceden a los usuarios, ya que puede tratarse de un problema que no se resuelve instalando actualizaciones en el equipo. Por otra parte, para resolver este tipo de cuestiones, es necesario que el administrador del sitio agregue los controles necesarios, para que nada pueda ser modificado por un tercero.

Fuente:No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

¿Qué es y cómo opera un ataque de Cross-Site Scripting (XSS)?



    Definición
    Tipos de ataques
    Consideraciones
    PDF XSS
    XSRF

Definición

XSS es un ataque de inyección de código malicioso para su posterior ejecución que puede realizarse a sitios web, aplicaciones locales e incluso al propio navegador.

Sucede cuando un usuario mal intencionado envía código malicioso a la aplicación web y se coloca en forma de un hipervínculo para conducir al usuario a otro sitio web, mensajería instantánea o un correo electrónico. Así mismo, puede provocar una negación de servicio (DDos).




Generalmente, si el código malicioso se encuentra en forma de hipervínculo es codificado en HEX (basado en el sistema de numeración hexadecimal, base 16) o algún otro, así cuando el usuario lo vea, no le parecerá sospechoso. De esta manera, los datos ingresados por el usuario son enviados a otro sitio, cuya pantalla es muy similar al sitio web original.

De esta manera, es posible secuestrar una sesión, robar cookies y cambiar la configuración de una cuenta de usuario.

Tipos de ataques

Las diversas variantes de esta vulnerabilidad pueden dividirse en dos grandes grupos: el primero se conoce como XSS persistente o directo y el segundo como XSS reflejado o indirecto.

Directo o persistente. Consiste en invadir código HTML mediante la inclusión de etiquetas <script> y <frame> en sitios que lo permiten.

Local. Es una de las variantes del XSS directo, uno de sus objetivos consiste en explotar las vulnerabilidades del mismo código fuente o página web. Esas vulnerabilidades son resultado del uso indebido del DOM (Modelo de Objetos del Documento, es un conjunto estandarizado de objetos para representar páginas web) con JavaScript, lo cual permite abrir otra página web con código malicioso JavaScript incrustado, afectando el código de la primera página en el sistema local. Cuando el XSS es local, ningún código malicioso es enviado al servidor. El funcionamiento toma lugar completamente en la máquina del cliente, pero modifica la página proporcionada por el sitio web antes de que sea interpretada por el navegador para que se comporte como si se realizara la carga maliciosa en el cliente desde el servidor. Esto significa que la protección del lado del servidor que filtra el código malicioso no funciona en este tipo de vulnerabilidad.

Indirecto o reflejado. Funciona modificando valores que la aplicación web pasa de una página a otra, sin emplear sesiones. Sucede cuando se envía un mensaje o ruta en una URL, una cookie o en la cabecera HTTP (pudiendo extenderse al DOM del navegador).

Consideraciones

Como desarrollador

La aplicación web que se desee implementar debe contar con un buen diseño. Posteriormente, se deben realizar diversos tipos de pruebas antes de su liberación, para detectar posibles fallos y  huecos de seguridad, mediante el empleo de alguna herramienta automatizada. También, es conveniente proporcionar mantenimiento a la aplicación y estar actualizado en las versiones de las herramientas que se emplean para su puesta en marcha.

Algunas recomendaciones para mitigar el problema, son:

Emplear librerías verificadas o algún framework que ayude a disminuir el inconveniente. Por ejemplo: la librería anti-XSS de Microsoft, el módulo ESAPI de codificación de OWASP, Apache Wicket, entre otros.

Entender el contexto en el cual los datos serán usados y la codificación de los mismos, este aspecto es importante cuando se envían datos de un componente a otro de la aplicación o cuando se deben enviar a otra aplicación.

Conocer todas las áreas potenciales donde las entradas no verificadas pueden acceder al software: parámetros o argumentos, cookies, información de la red, variables de entorno, resultados de consultas, búsqueda de DNS reversible, peticiones enviadas en las cabeceras, componentes de la URL, correos electrónicos, archivos, nombres de archivo, bases de datos o algún sistema externo que proporcione información a la aplicación.

Las validaciones de datos de entrada, deben realizarse siempre del lado del servidor, no sólo en el lado del cliente. Los atacantes pueden evitar la validación realizada del lado del cliente modificando valores antes de realizar verificaciones o remover por completo esta validación.

En caso de ser posible, emplear mecanismos automatizados para separar cuidadosamente los datos del código fuente: revisión de comillas, codificación y validación automática que muchas veces se escapan al desarrollador.

Por cada página web generada, se recomienda emplear una codificación determinada de caracteres, ya que si no se especifica, el navegador puede dar un trato diferente a ciertas secuencias de caracteres especiales, permitiendo la apertura del cliente a posibles ataques.

Para mitigar el problema de ataque contra el uso de cookies, es conveniente indicar que tiene el formato de HttpOnly. En los navegadores que lo soportan, puede prevenirse que la cookie sea usada por scripts maliciosos desde el lado del cliente.

Se debe emplear una estrategia de validación de las entradas: rechazar aquellas que no cumplan con lo especificado, limpiar las que sean necesarias. Al validar, considérense  las características de cada entrada: longitud, tipo de dato, rango de valores aceptados, entradas perdidas o adicionales, sintaxis, consistencia con otras entradas proporcionadas y seguimiento de las reglas del negocio.

Cuando se construyan páginas web de forma dinámica (generadas de acuerdo a las entradas o solicitudes de los usuarios), es recomendable usar listas blancas estrictas. Todas las entradas deben ser limpiadas y validadas, incluidos cookies, campos ocultos, cabeceras y la propia dirección.

Cuando una cantidad aceptable de objetos, como nombres de archivo o URL es limitada o conocida, es conveniente crear una conjunto de asignaciones de valores de entrada fijo a los nombres de archivo o URL y rechazar todos los demás.

Se recomienda usar un firewall de aplicaciones capaz de detectar ataques cuando el código se genere dinámicamente, como medida de prevención, debe complementarse con otras para proporcionar defensa en profundidad.

Como Administrador de Bases de Datos

Así como el desarrollador debe validar las entradas proporcionadas por parte del usuario, el encargado de diseñar e implementar la base de datos debe considerar la seguridad de la misma, pues en ella se guarda la información proporcionada por los usuarios y es manipulada mediante la aplicación web. Los datos que serán almacenados, también pueden ser validados mediante el uso de constraints  (restricciones aplicables a los objetos de una base de datos: unique, default, not null, check) que restringen la entrada para cada campo.

PDF XSS

Es una vulnerabilidad ampliamente usada para afectar el Acrobat Reader de Adobe. En este caso, si se abusa de las características para abrir archivos en Acrobat, un sitio bien protegido se vuelve vulnerable a un ataque de tipo XSS si da alojamiento a documentos en formato PDF.

Esto afecta seriamente, a menos que se actualice el Reader o se cambie la forma en que el navegador maneja dichos documentos.

Una manera de combatirlo, si se cuenta con el servidor de aplicaciones web Apache, es llevar a cabo la correcta configuración de ModSecurity, ya que cuenta con directivas de protección para archivos en formato PDF.

XSRF

Un ataque Cross-Site Request Forgery (XSRF ó también CSRF) explota la confianza que un usuario tiene hacia las entradas proporcionadas por un sitio.

Por ejemplo: un usuario se encuentra autenticado y navegando en un sitio, en ese momento un atacante obtiene el control de su navegador, con él realiza una solicitud a una tarea de una URL válida del sitio, por lo que el atacante tendrá acceso como si fuera el usuario previamente registrado.

Distintivamente, un atacante intercalará código HTML o JavaScript malicioso en un correo o en una tarea específica accesible desde una URL, que se ejecuta ya sea directamente o empleando un error de tipo XSS. También, es posible realizar inyección a través de lenguajes como el BBCode. Este tipo de ataques son difíciles de detectar.

Muchas de las funcionalidades de un sitio web son susceptibles de uso durante un ataque XSRF. Esto incluye información enviada tanto por GET como por POST.

También puede usarse como vector para explotar vulnerabilidades de tipo XSS en una aplicación. Ejemplos de ello son: una vulnerabilidad de tipo XSS en un foro donde un atacante puede obligar al usuario a publicar –sin que éste se dé cuenta- un gusano informático. Un atacante puede también usar XSRF para transmitir un ataque a algún sitio de su elección, así como realizar un DDos.

Sin embargo, las formas más comunes de realizar este tipo de ataque consisten en usar la etiqueta HTML o el objeto JavaScript empleados para imágenes. Distintivamente, el atacante infiltrará un email o sitio web en ellos, así cuando el usuario cargue la página o el correo electrónico, también estará realizando la petición a la URL que haya colocado el atacante.

Un atacante puede instalar su script dentro de un documento de Word, un archivo de flash, un clip de video, redifusión web RSS o Atom, o algún otro tipo de formato que pueda alojar el script.

Si un sitio web permite ejecutar sus funciones empleando una URL estática o peticiones POST, es posible que sea vulnerable, si la función se lleva a cabo mediante la petición GET, el riesgo es mayor. Si se realizan las mismas funciones,  de la misma forma repetidamente, entonces la aplicación puede ser vulnerable.

Un ataque XSRF no puede evitarse mediante la verificación del referer de las cabeceras de la petición realizada, ya que puede "limpiarse" o modificarse mediante algún tipo de filtro. Las cabeceras pueden falsearse usando XMLHTTP, por ejemplo.

Una de las soluciones más conocidas, consiste en adjuntar un token no predecible y cambiante a cada petición. Es importante que el estado de éste vaya asociado con la sesión del usuario, de otra manera un atacante puede adjuntar su propio token válido y emplearlo en su beneficio. Adicionalmente, al ligarlo a la sesión del usuario es importante limitar el periodo durante el cual será válido.

Referencias.


   No tienes permitido ver los links. Registrarse o Entrar a mi cuenta