Entradas y salidas
El punto débil de seguridad más frecuente de las aplicaciones de hoy en día es no procesar correctamente los datos recibidos de orígenes externos, especialmente las entradas de usuario. Debe examinar detenidamente cualquier entrada para asegurarse de que se haya validado antes de usarla. No analizar las entradas de usuario en búsqueda de posibles ataques puede provocar la pérdida o la exposición de los datos, la elevación de los privilegios o, incluso, la ejecución de código malintencionado en los equipos de otros usuarios.
Lo peor de todo es que esta situación se puede evitar fácilmente. En esta unidad se explica cómo tratar los datos cuando se reciben, cuando se muestran en pantalla y cuando se almacenan para su uso posterior.
¿Por qué es necesario validar los datos de entrada?
Imagine que va a compilar una interfaz para que un usuario pueda crear una cuenta en su sitio web. Nuestro perfil de datos incluye el nombre, el correo electrónico y un alias que se mostrará a los usuarios que visiten el sitio. ¿Qué ocurre si un nuevo usuario crea un perfil y escribe un alias que incluye algunos comandos SQL? Por ejemplo, ¿qué ocurre si un usuario malintencionado escribe un texto parecido a este extracto?:
Eve'); DROP TABLE Users;--
Si insertamos este valor sin más en una base de datos, podría modificar la instrucción SQL para ejecutar comandos que seguro que no queremos ejecutar. Este ejemplo se conoce como un ataque por "inyección de código SQL" y es uno de los muchos tipos de vulnerabilidades que se pueden dar cuando no se administran correctamente las entradas de usuario. ¿Qué se puede hacer para corregir esta situación? Esta unidad le enseñará cuándo validar los datos de entrada, cómo codificar la salida y cómo crear consultas parametrizadas (que solucionan la vulnerabilidad de seguridad anterior). Estas son las tres técnicas de defensa principales frente a entradas malintencionadas que se inserten en las aplicaciones.
¿Cuándo hay que validar los datos de entrada?
La respuesta es siempre. Se deben validar todos los datos de entrada de la aplicación. Esto incluye los parámetros en la dirección URL, las entradas de usuario, los datos de la base de datos, los datos de una API y todo lo que se pase que un usuario pudiera manipular potencialmente. Use siempre listas de permitidos para aceptar solo datos de entrada "buenos conocidos", en lugar de listas de bloqueados (que buscan específicamente datos de entrada incorrectos), porque es imposible crear una lista completa con todos los datos de entrada potencialmente peligrosos. Realice esta tarea en el servidor, no en el lado cliente (o además del lado cliente) para asegurarse de que sus defensas no se puedan evitar. Trate TODOS los datos como de no confianza para protegerse de la mayoría de las vulnerabilidades de aplicación web.
Si usa ASP.NET, el marco de trabajo proporciona una excelente compatibilidad para validar los datos de entrada en el lado de servidor y de cliente.
Si usa otro marco web, existen algunas técnicas excelentes para realizar la validación de los datos de entrada en la hoja de referencia de validación de datos de entrada de OWASP.
Use siempre consultas parametrizadas
Las bases de datos SQL se usan normalmente para almacenar datos; por ejemplo, la aplicación podría almacenar información de perfil de usuario en una base de datos. No debe crear nunca consultas insertadas SQL o de otras bases de datos en el código mediante entradas de usuario sin formato ni enviarlas directamente a la base de datos; este comportamiento es una receta segura para el desastre, como hemos visto anteriormente.
Por ejemplo, no cree código como el siguiente ejemplo insertado de SQL:
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
Aquí se concatenan cadenas de texto para crear la consulta, se toma las entradas de usuario y se genera una consulta SQL dinámica para buscar el usuario. De nuevo, si un usuario malintencionado se diera cuenta de que estamos haciendo esto, o solo estuviera probando diferentes estilos de datos de entrada para ver si se ha producido una vulnerabilidad, podríamos terminar con un desastre importante. En su lugar, use instrucciones SQL parametrizadas o procedimientos almacenados como este:
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
Con este método puede invocar el procedimiento desde el código de forma segura, y pasarlo a la cadena userName sin preocuparse por que se pueda tratar como parte de la instrucción SQL.
Codifique siempre los datos de salida
Todos los datos de salida que presente visualmente o en un documento deberán codificarse e incluir caracteres de escape. Esto puede protegerle en caso de que se haya perdido algo durante el saneamiento o de que el código genere accidentalmente algo que se pueda usar de forma malintencionada. Este principio de diseño permite asegurarse de que todo se muestra como salida y que no se interpreta involuntariamente como elementos ejecutables, que es en lo que consiste otra técnica de ataque común conocida como "scripting entre sitios" (XSS).
Como la prevención de XSS es un requisito de aplicación común, esta técnica de seguridad es otro aspecto del que ASP.NET se encargará de forma automática. De forma predeterminada, todos los datos de salida ya están codificados. Si usa otro marco web, puede comprobar las opciones de codificación de salida en los sitios web con la hoja de referencia rápida de prevención de XSS de OWASP.
Resumen
Sanear y validar las entradas es un requisito necesario para asegurarse de que sean válidas y seguras de usar y almacenar. Los marcos web más modernos ofrecen características integradas que pueden automatizar parte de este trabajo. Revise la documentación de su marco preferido y vea qué características ofrece. Mientras que las aplicaciones web son el lugar más común donde esto ocurre, tenga en cuenta que otros tipos de aplicaciones pueden ser igualmente vulnerables. No crea que, simplemente porque su nueva aplicación sea una aplicación de escritorio, será segura. Aun así deberá administrar correctamente los datos de entrada del usuario para asegurarse de que alguien no usa la aplicación para dañar los datos o la reputación de su empresa.