Realizar validación de entrada significa verificar su entrada para asegurarse de que pueda procesarla. La parte difícil es que al validarlo, ya estás haciendo un procesamiento menor y eso puede crear una vulnerabilidad oculta.
El primer paso suele ser validar la longitud de la entrada. La mayoría de las entradas aterrizarán temporalmente en un búfer finito. Asegúrese de que la cantidad de entrada que copie en el búfer no exceda la longitud del búfer; si hay demasiada entrada y no hay suficiente búfer, esto puede crear un problema clásico de "desbordamiento de búfer"; explotar estos es un elemento básico de los hackers.
El siguiente paso es asegurarse de que los datos estén en el formato que espera. Si está esperando un número, asegúrese de que los bytes contengan solo dígitos y símbolos de números permitidos, como más, menos, separador, punto decimal, símbolo de moneda, etc. Tenga en cuenta que estos son específicos del lugar: en EE. UU., Un millón de dólares podría ingresarse como 1,000,000.00 , mientras que en Alemania se podría ingresar un millón de euros como 1.000.000,00 . Si está esperando caracteres y números alfanuméricos, use una "lista blanca" para aceptar solo los caracteres que espera. Es más seguro confiar en una lista blanca de caracteres buenos que en una lista negra de caracteres malos; su lista negra puede mantenerlo seguro con su configuración a partir de hoy, pero digamos que alguien en el futuro reemplaza su base de datos con una base de datos diferente. Es posible que uno de los caracteres inesperados permita una inyección de SQL. Lo mismo ocurre con las secuencias de comandos y HTML.
Tenga en cuenta que si revierte estas comprobaciones y prueba caracteres especiales antes de verificar la longitud de entrada, su código de validación podría ser vulnerable a un desbordamiento de búfer. Es importante hacerlas en el orden que te mantiene más seguro.
Por lo tanto, el siguiente paso es codificar adecuadamente la entrada. Por ejemplo, si va a aceptar < y > y coloca los resultados en una página web, probablemente querrá asegurarse de que está codificando los símbolos en HTML para que no cree un agujero inadvertidamente. donde un atacante puede plantar un <script>attack!</script> en la página de salida.
También se recomienda intentar proteger contra las inyecciones SQL aquí (proteger a alguien que ingresa algo malo como ' OR 1=1;DROP TABLE STUDENTS-- , pero es un arma de doble filo, ya que no garantiza completamente la protección. Puede intentar evitar esto colocando una verificación de validación contra la aceptación del carácter de apóstrofo. La siguiente línea de defensa debe estar en el código que se relaciona con SQL, y ese código debe ser responsable de ejecutar las consultas de forma segura (utilizando consultas SQL parametrizadas, ORM u otra estrategia defensiva). Puede hacer una prueba de escritura de su entrada contra el ataque de inyección de SQL anterior y no encontrar una falla porque solo conoce el tipo de ataque de inyección. Pero supongamos que el atacante descubre una nueva vía de ataque y trata de usar la codificación HTML para obtener Alrededor de su cheque, y resulta que olvidó probar y / o desinfectar ese tipo de entrada. Aún podría ser vulnerable a menos que tenga cuidado con la codificación SQL. Este es un pequeño ejemplo de cómo una defensa en La estrategia de profundidad puede ayudarte a mantenerte seguro.