archived-doc-es/reference/mongo/security.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- EN-Revision: 565e478d69a9d0c217eda773c77ca823423adf21 Maintainer: seros Status: ready -->
<!-- Reviewed: no -->

<chapter xml:id="mongo.security" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
 <title>Seguridad</title>
 
 <section>
  <title>Ataques de Inyección de Petición</title>
  <para>
   Al pasar parámetros <literal>$_GET</literal> (o <literal>$_POST</literal>)
   a una consulta, se ha de asegurar de que están convertidos a string.
   Un usuario puede insertar un array asociativo en peticiones GET y POST, lo que
   provocaría consultas $ no deseadas.
  </para>
  
  <para>
   Un ejemplo aparentemente inofensivo: supongamos que estamos buscando información de un usuario
   con la petición <emphasis>http://www.example.com?username=bob</emphasis>.
   La aplicación realiza la consulta
   <literal>$collection->find(array("username" => $_GET['username']))</literal>.
  </para>
  
  <para>
   Alguien podría alterarlo realizando una consulta a
   <emphasis>http://www.example.com?username[$ne]=foo</emphasis>, con lo que PHP
   lo convertirá automáticamente a un array asociativo, creando la consulta
   <literal>$collection->find(array("username" => array('$ne' => "foo")))</literal>,
   que devolverá todos los usuarios con nombre distinto de "foo" (probablemente, todos).
  </para>
  
  <para>
   Es sencillo defenderse de un ataque como éste: hay que asegurarse de que los parámetros
   $_GET y $_POST son del tipo demandado antes de enviarlos a la base de datos
   (en este caso, se han de convertir a string).
  </para>
  
  <para>
   Tenga en cuenta que este tipo de ataque se puede usar con cualquier interacción con una base de datos
   que localice documentos, incluyendo actualizaciones, busquedas con modificación, y
   eliminaciones.
  </para>
  
  <para>
   Gracias a <link xlink:href="&url.mongodb.injection;">Phil</link> por apuntar esto.
  </para>
  
  <para>
   Para más información sobre ataques tipo inyección SQL con MongoDB revise
   <link xlink:href="&url.mongodb.dochub.security;">la documentación principal</link>.
  </para>
 </section>
 
 <section>
  <title>Ataques de Inyección de Código</title>
  <para>
   Si se está usando JavaScript, debemos asegurarnos que cualquier variable que cruce
   los límites PHP-JavaScript se pasa en el campo <literal>scope</literal> de
   <classname>MongoCode</classname>, y no interpolado en el código JavaScript.
   Esto sucede al llamar a <function>MongoDB::execute</function>, consultas
   <literal>$where</literal>, MapReduces, agrupaciones, y cualquier otra situación en que
   se proporcione código JavaScript a la base de datos.
  </para>
  <note>
   <para>
    MapReduce ignora el campo <literal>scope</literal> de
    <classname>MongoCode</classname>, pero hay una opción <literal>scope</literal>
    disponible en el comando que puede utilizarse en su lugar.
   </para>
  </note>
  <para>
   Por ejemplo, supongamos que tenemos un código JavaScript para saludar a los usuarios
   en los registros de la base de datos. Podríamos:
  </para>
  <programlisting role="php">
<![CDATA[
<?php

// ¡no haga esto!

$username = $_POST['username'];
$db->execute("print('Hola, $username!');");

?>
]]>
  </programlisting>
  <para>
   Pero, ¿qué ocurriría si un usuario malicioso metiera código JavaScript?
  </para>
  <programlisting role="php">
<![CDATA[
<?php

// ¡no haga esto!

// $username tiene como valor "'); db.users.drop(); print('"
$db->execute("print('Hola, $username!');");

?>
]]>
  </programlisting>
  <para>
   Ahora MongoDB ejecuta el código JavaScript
   <literal>"print('Hola, '); db.users.drop(); print('!');"</literal>.
   Este ataque es fácil de evitar: utilice <literal>scope</literal> al
   pasar variables de PHP a Javascript:
  </para>
  <programlisting role="php">
<![CDATA[
<?php

$scope = array("user" => $username);
$db->execute(new MongoCode("print('Hello, '+user+'!');", $scope));

?>
]]>
  </programlisting>
  <para>
   Esto añade la variable <literal>user</literal> al ámbito de JavaScript. Si ahora
   alguien quisiera añadir código malicioso, MongoDB imprimiría, sin causar daños, 
   <literal>Hello, '); db.dropDatabase(); print('!</literal>.
  </para>
  
  <para>
   El uso de <literal>scope</literal> ayuda a prevenir que se ejecutene en la base
   de datos entradas maliciosas. Sin embargo, debe asegurarse de que su código no
   cambie y ejecute los datos de entrada. Por ejemplo, nunca utilice la función
   <literal>eval</literal> de JavaScript con los datos de entrada de un usuario:
  </para>
  <programlisting role="php">
<![CDATA[
<?php

// ¡no haga esto!

// $jsShellInput es "db.users.drop();"
$scope = array("input" => $jsShellInput);
$db->execute(new MongoCode("eval(input);", $scope));

?>
]]>
  </programlisting>
  <para>
   Use siempre <literal>scope</literal> y nunca permita que la base de datos ejecute
   como código los datos de entrada del usuario.
  </para>
 </section>
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->