Resultados de Test a la página http://free2geek.

com

*http://free2geek.com/wp-comments-post.php

Descripción de alerta:

La técnica de ataque Path Traversal permite a un atacante acceder a los archivos, directorios y
comandos que potencialmente residen fuera del directorio raíz de documentos web. Un atacante
puede controlar una URL de tal forma que el sitio web ejecutará o mostrará la información de los
archivos que son arbitrarios en cualquier parte del servidor web. Cualquier dispositivo que se
exponga a una interfaz que se basa en HTTP es potencialmente vulnerable a un Path Traversal.

La mayoria de los sitios web prohíben el acceso de los usuarios a algún sitio específico del sistema
de los archivos, normalmente denominado directorio "raíz del documento web" o "raíz CGI". Estos
directorios poseen los archivos que estan destinados al acceso del usuario y el ejecutable que es
necesario para poder controlar la funcionalidad correcta de la aplicación web. Para poder ingresar
a los archivos o activar los comandos en cualquier zona del sistema de los archivos, los ataquesde
trayectoria de rutas van a utilizar la capacidad de las secuencias de todos los caracteres especiales.

El ataque Path Traversal más elemental utiliza la secuencia de los caracteres especiales "../" para
poder modificar la ubicación del recurso que es requerido en la URL. Aunque la gran mayoría de
los servidores web que son populares van a evitar que esta técnica se escape de la raíz del
documento web, las codificaciones que son alternativas de la secuencia "../" pueden impedir los
filtros de seguridad. These method variations include valid and invalid Unicode-encoding ("..
%u2216" or "..%c0%af") of the forward slash character, backslash characters ("..\") on Windows-
based servers, URL encoded characters "%2e%2e%2f"), and double URL encoding ("..%255c") of
the backslash character.

Inclusive si el servidor web impide de forma correcta los intentos de trayectoria en la ruta de la
URL, una aplicación web en sí misma puede ser muy vulnerable provocado por el manejo de forma
incorrecta de la entrada que fue proporcionada por el usuario. Este es un problema muy común de
las aplicaciones web que utilizan los mecanismos de plantilla o cargan algún texto estático de los
archivos. En las variaciones de los ataques, el valor del parámetro de la URL original se modifica
por el nombrede uno de los archivos de órdenes dinámicos de la aplicación web. Provocando que,
los resultados puedan mostrar el código fuente porque el archivo se interpreta como un texto en
vez de como un archivo de órdenes ejecutable. Estás técnicas muchas veces utilizan caracteres
especiales extras, como el punto (".") para poder revelar la lista del directorio de trabajo actual, o
los caracteres que son NULOS "%00 para poder evadir las verificaciones elementales de la
extensión de los archivos.

Solución de alerta:

Asuma que toda la entrada es maliciosa. Utilice una estrategia de validación de entrada "aceptar
bien conocidos", es decir, utilice alguna lista blanca de entradas aceptables que se ajuste de forma
estricta a las especificaciones. Rechace cualquier entrada que no se adapte de forma estricta a las
especificaciones, o cambielas por algo que sí lo haga. No confíe solamente en la búsqueda de
entradas maliciosas o malformadas (es decir, no confíe en una lista negra). Sin embargo, las listas
negras pueden ser muy útiles para detectar posibles ataques o diagnosticar que entradas están
tan malformadas que se deberían rechazar directamente.

Al realizar la validación de entrada, usted debe considerar todas las propiedades potencialmente
destacadas, incluida la longitud, el tipo de entrada, el rango completo de valores aceptables, las
entradas faltantes o adicionales, la sintaxis, el sentido entre los campos que se encuentran
relacionados y la conformidad con todas las reglas comerciales. Como un ejemplo de lógica de las
reglas comerciales, "bote" puede ser válido de forma sintáctica porque solo posee caracteres que
son alfanuméricos, pero no es válido si está esperando los colores como "rojo" o "azul".

Para los nombres de los archivos, utilice las listas blancas que son estrictas y que limiten el grupo
de caracteres que se van a utilizar. Si es posible, solo permita un solo carácter "." en el nombre del
archivo para poder prevenir las vulnerabilidades y rechazar los separadores de directorios como
por ejemplo "/". Utilice una lista blanca de las extensiones del archivo que sea permitida.

Advertencia: si usted intenta limpiar sus datos, tiene que hacerlo para que el resultado final no
esté en la forma en el que estos puedan ser un peligro. Un mecanismo para desinfectar puede
provcar la eliminación de caracteres como por ejemplo "." y ";" que pueden ser necesitados para
varias explociones. Un atacante puede intentar burlar al mecanismo de desinfección para que este
"limpie" los datos de una forma que puede ser muy peligrosa. Supongamos que el atacante logra
inyectar un "." dentro de un nombre de un archivo (por ejemplo, "archivo sensi.tive") y el
mecanismo que se encarga de desinfectar elimina el carácter que da como resultado que el
nombre del archivo válido sea, "archivo sensible". Si ahora suponemos que los datos de entrada
son seguros, entonces el archivo tiene la posibilidad de verse comprometido.

Las entradas se deben decodificar y canonicalizar a la representación que se encuentra

actualmente de manera interna de la aplicación antes de validarlas. Asegúrese de que su
aplicación no pueda descodificar la misma entrada dos veces. Dichos errores podrían utilizarse
para evadir los esquemas de la lista blanca ingresando entradas muy peligrosas luego de que se
hayan verificado.

Utilice alguna función de canonicalización de una ruta que fue incorporada (como realpath() en C)
la cual origina la versión canónica de la ruta de acceso, que produce la eliminación de forma
efectiva de las secuencias ".." y los enlaces que son simbólicos.

Ejecute su codigo utilizando los privilegios más bajos que se necesitan para poder realizar todas las
tareas que son necesarias. Si es posible, cree unas cuentas que se encuentren aisladas con
provilegios limitados que solo se utilizan para una sola tarea. De esta forma, un ataque que sea
exitoso no le proporcionará al atacante el acceso de forma inmediata al resto del software o su
dominio. Por ejemplo, las aplicaciones de las bases de datos muy pocas veces requieren ejecutarse
como el administrador de la base de datos, en especial en las operaciones que son cotidianas.

Cuando el grupo de los objetos que son aceptados, como nombre de los archivos o URL, es
limitado o conocido, tiene que crear una asignación de un grupo de valores de entradas que son
fijos (como ID numéricos) a los nombres de los archivos o URL que son reales, y además tiene que
rechazar todas las otras entradas.
Ejecute su código en un dominio de "cárcel" o un dominio que sea similar el cual imponga los
límites estrictos entre el proceso y el sistema operativo. Esto puede ser que restrinja de forma
efectiva a qué archivos se pueden ingresar en un directorio particular o qué comandos puede
utilizar su software.

Los ejemplos de niveles de sistema operativo incluyen el Unix chroot jail, AppArmor, and SELinux.
Normalmente, el código proporcionado puede otorgar cierta protección. Por ejemplo,
java.io.FilePermission en Java SecurityManager le permite especificar las restricciones en las
operaciones de archivos.

Esto puede que no sea la solución viable, y solo limita el impacto al sistema operativo; el resto de
tu aplicación puede estar expuesta.

*http://free2geek.com/tag/google/

Descripcion de alerta:

Remote File Include (RFI) es una técnica de ataque muy utilizada para poder explotar los
mecanismos de "inclusión dinámico de los archivos" en las aplicaciones web. Cuando las
aplicaciones web toman la entrada del usuari (URL, valor del parámetro, etc) y las cambian a los
comandos de incluir los archivos, la aplicación web puede ser engañada para incluir los archivos
remotos con un código maligno.

Casi todos los marcos de las aplicaciones web permiten la inclusión de los archivos. La inclusión de
los archivos se utiliza de forma principal para envolver un código común en archivos separados
que después se referencian en los módulos principales de la aplicación. Cuando una aplicación
web realiza referencia a un archivo de inclusión, el código que se encuentra en este archivo puede
activarse de forma implícita o explícita llamando a procedimientos específicos. Si la selección del
módulo a cargar se basa en los elementos de la solicitud de HTTP, la aplicación web podría ser muy
vulnerable a RFI.

Un atacater puede utilizar RFI para:

*Activar un código maligno en el servior: cualquier código incluidos en los archivos maliciosos
serán ejecutados por el servidor. Si el archivo incluído no es ejecutado con algún protector, el
código en los archivos incluidos se ejecutará en el contexto del uso del servidor. Esto podría
originar el compromiso completo de todo el sistema.

*La activación de códigos maliciosos en los clientes: el código malicioso del atacante tienen la
capacidad de manipular todo el contenido de la respuesta enviada al cliente. El atacante puede
incorporar un código malicioso en la respuesta que será ejecutada por el cliente (por ejemplo, que
Javascript robe las cookies de la sesión del cliente).

PHP es de forma particular muy vulnerable a los ataques de RFI ya que debido al uso masivo de
"archivos incluidos" en la programación de PHP y debido a las modificaciones del servidor el cual
está predeterminado aumentan la susceptibilidad a un ataque de RFI.

Solucion de alerta:

Fase: Arquitectura y Diseño

Cuando el grupo de objetos aceptables, como nombres de archivos o URL, es limitado o conocido,
usted debe crear una asignación de un grupo de valores de entradas fijos (como ID númericos) a
los nombres de archivos o URL reales, y rechace todas las demás entradas.

Por ejemplo, la ID 1 se podría asignar a "inbox.txt" y la ID 2 se podría asignar a "profile.txt". Las

características tales como AccessReferenceMap de ESAPI otorgan esta capacidad.

Fases: Arquitectura y Diseño; Operación

Active su código en un entorno de "cárcel" o similar que refuerce los limites estrictos establecidos
entre el proceso y el sistema operativo. Esto puede ser que restrinja de forma efectiva a qué
archivos se pueden ingresar en un directorio particular o qué comandos puede utilizar su software.

Los ejemplos de niveles de sistema operativo incluyen el Unix chroot jail, AppArmor, and SELinux.
Normalmente, el código proporcionado puede otorgar cierta protección. Por ejemplo,
java.io.FilePermission en Java SecurityManager le permite especificar las restricciones en las
operaciones de archivos.

Esto puede que no sea la solución viable, y solo limita el impacto al sistema operativo; el resto de
tu aplicación puede estar expuesta.

Usted debe tener cuidado de evitar CWE-243 y otras debilidades relacionadas con las cárceles.

Para PHP, el traductor ofrece restricciones como por ejemplo openirir abierto o modo seguro, que
pueden hacer que sea mucho más dificil para un atacante escapar de la aplicación. También debe
considerar Suhosin, una extensión de PHP reforzada, la cual incorpora varias opciones que
desactivan algunas de las funciones de PHP más peligrosas.

Fase: Implementación

Supongamos que toda la entrada es maliciosa. Utilice una estrategia de validación de entrada
"aceptar bien conocidos", es decir, utilice alguna lista blanca de entradas aceptables que se ajuste
de forma estricta a las especificaciones. Rechace cualquier entrada que no se adapte de forma
estricta a las especificaciones, o cambielas por algo que sí lo haga. No confíe solamente en la
búsqueda de entradas maliciosas o malformadas (es decir, no confíe en una lista negra). Sin
embargo, las listas negras pueden ser muy útiles para detectar posibles ataques o diagnosticar que
entradas están tan malformadas que se deberían rechazar directamente.

Al realizar la validación de entrada, usted debe considerar todas las propiedades potencialmente
destacadas, incluida la longitud, el tipo de entrada, el rango completo de valores aceptables, las
entradas faltantes o adicionales, la sintaxis, el sentido entre los campos que se encuentran
relacionados y la conformidad con todas las reglas comerciales. Como un ejemplo de lógica de
reglas comerciales, "bote" puede ser sintácticamente válido porque solo incluye caracteres
alfanuméricos, pero no es válido si está esperando colores como "rojo" o "azul". Para los nombres
de los archivos, utilice las listas blancas estrictas que limiten el grupo de caracteres que se van a
utilizar. Es factible, solo permitir un único "." carácter en el nombre del archivo para prevenir
vulnerabilidades tales como CWE-23, y excluir los separadores de directorios tales como "/" para
prevenir CWE-36. Utilice una lista blanca de las extensiones de los archivos permitidos, lo que
ayudará a prevenir a CWE-434.

Fases: Arquitectura y Diseño; Operación

Guardar biblioteca, incluir, y utilizar archivos de utilidad fuera de la raíz del documento web, si es
posible. De lo contrario, guárdelos en un directorio que se encuentre separado y utilice las
capacidades de control de acceso del servidor web para poder evitar que los atacantes los soliciten
de forma directa. Un ejercicio muy común es definir una constante fija en cada uno de los
programas de llamada, luego revisar la existencia de la constante en el archivo de
biblioteca/inclusión; si la constante no existe, entonces el archivo se solicitó de forma directa y
puede salir inmediatamente.

Esto simplifica de forma significativa la posibilidad de que un atacante pueda evadir cualquier
mecanismo de protección que se encuentre en el programa base pero no en los archivos de
inclusión. Tambien simplificará su superficie de ataque.

Fases: Arquitectura y Diseño; Implementación

Comprenda todas las zonas potenciales donde las entradas que no son confiables pueden ingresar
a su software: parámetros o argumentos, cookies, cualquier cosa que fue leída de la red, variables
de entorno, búsquedas de DNS inversas, resultado de las consultas, encabezados de la solicitudes,
elementos de URL, correos electrónicos, archivos, bases de datos y cualquier sistema que sea
externo que proporcione algunos datos a la aplicación. Recuerde que esas entradas pueden ser
obtenidas de forma indirecta por medio de llamadas API.

Muchos de los problemas de inclusión de archivos suceden porque el programador asumió que
algunas entradas no se podían cambiar, especialmente para las cookies y los componentes de la
URL.

http://free2geek.com/

Descipcion de alerta:

El encabezado X-Frame_options no está incluido en la respuesta HTTP para proteger ante ataques
'ClickJacking'.

Solución de alerta:

Los navegadores de web mas modernos apoyan la cabecera HTTP X-Frame-Options. Asegúrese
que está establecido en todas las páginas web devuelta por su sitio (si usted espera que la página
este enmarcada solo por páginas en su servidor (por ejemplo, es parte de un FRAMESET) entonces
usted querrá usar SAMEORIGIN, de otras forma si usted nunca espera que la página esté
enmarcada, debería usar DENY. ALLOW-FROM permite a sitios web específicos enmarcar la página
web en navegadores web compatibles).
http://free2geek.com/

Descripcion de alerta:

No Anti-CSRF tokens were found in a HTML submission form.

Una solicutud falsa entre sitios en un ataque que compromete y obliga a una víctima a enviar su
solicitud HTTP a un destino objetivo sin su conocimiento o intención para poder realizar una
acción como víctima. La causa oculta es la funcionalidad de la aplicación utilizando acciones de
URL/formulario que pueden ser adivinados de forma repetible. La naturaleza del ataque es que
CSRG explota la confianza que un sitio web proporciona a un usuario. Por el contrario, las cadenas
de comandos de los sitios cruzados (XSS) explotan la confianza que un usuario proporciona en un
sitio web. Al igual que XSS, los ataques CSRG no son de forma necesaria de sitios cruzados, pero
hay la posibilidad de que si pueden serlo. La falsificación de las solicitudes ente los sitios también
se conoce como CSRF, XSRG, ataques con un solo clic, montaje de sesión, diputado confundido y
navegación en alta mar.

Los ataques de CSRG son muy efectivos en varias situaciones, que incluyen:

*La victima tiene una sesión activa en el sitio de destino.

*La víctima se autoriza por medio de la autenticación HTTP en el sitio de destino.

*La víctima se encuentra en la misma red local que el sitio de destino.

CSRF se ha utilizado especialmente para poder realizar una acción contra un sitio objetivo
utilizando los privilegios de la víctima, pero se han revelado técnicas recientes para difundir
información al obtener el acceso a la respuesta. El riesgo de divulgación de información aumenta
de forma drástica cuando el sitio de destino se encuentra vulnerable a XSS, porque XSS se puede
utilizar como una plataforma para CSRF, lo que le permite al atacante que opere desde adentro de
los líites de la misma política de origen.

Solucion de alerta:

Frase: Arquitectura y Diseño

Utilice una biblioteca o marco comprobado que no acepte que ocura esta debilidad o que
proporcione construcciones que permitan que esta debilidad sea mas sencilla de evitar.

Por ejemplo, utilice el paquete anti-CSRG como el CSRGuard de OWASP.

Fase: Implementación

Asegúrese de que su aplicación esté libre de fallas de secuencias de comandos entre sitios, ya que
la mayoría de las defensas de CSRF pueden detenerse por alto por medio del uso de secuencias de
comandos manejadas por el atacante.
Fase: Arquitectura y Diseño

Origina un nonce único para cada uno de los formularios, coloque el nonce en el formularo y
confirme la independencia al obtener el formulario. Asegúrese de que el nonce no sea predecible
(CWE-330).

Usted tiene que tener en cuenta que esto puede pasar desapercibido utilizando XSS.

Identificar las operaciones que sean especialmente peligrosas. Cuando el usuario desarrolla una
operación peligrosa, envíe una solicitud de confirmación de forma separada para poder garantizar
que el usuario tenga la intención de desarrollar esa operación.

Usted tiene que tener en cuenta que esto puede pasar desapercibido utilizando XSS.

Utilice el control de gestión de la sesión de ESAPI.

Este control introduce un elemento para CSRF.

No utilice el método GET para ninguna de las solicitudes que puedan desencadenar un cambio de
estado.

Fase: Implementación

Revise que la solicitud se creó en la página esperada. Esto podría quebrar la funcionalidad
auténtica, ya que los usuarios o los representantes puede ser que hayan desactivado el envío de
Referer por motivos de privacidad.