Manipulación de parámetros
Last updated
Last updated
https://infosecwriteups.com/what-is-parameter-tampering-5b1beb12c5ba
La manipulación de parámetros implica alterar los parámetros de URL para recuperar información que, de otro modo, no estaría disponible para el usuario. Los riesgos de la explotación dependen de qué parámetro se modifica y el método por el cual se envía al servidor de aplicaciones web. Los ataques de manipulación de parámetros se pueden utilizar para lograr una serie de objetivos, incluida la divulgación de archivos por encima de la raíz web, la extracción de información de una base de datos y la ejecución de comandos arbitrarios a nivel del sistema operativo. Las recomendaciones incluyen la adopción de técnicas de programación seguras para garantizar que una aplicación solo acepte los datos esperados.
El impacto de esta vulnerabilidad en particular depende de qué parámetro se manipula y cómo se envía al servidor de aplicaciones. Como mínimo, es probable que un atacante pueda obtener información útil para orquestar ataques adicionales y más dañinos. Sin embargo, no está fuera del ámbito de la posibilidad, o incluso de la probabilidad, que esta vulnerabilidad pueda utilizarse para tomar el control completo del sistema. Los valores que se pueden modificar incluyen:
Cadenas de consulta: las aplicaciones web a menudo usan cadenas de consulta como un método simple para pasar datos desde el cliente y el servidor. Las cadenas de consulta son una forma de agregar llamadas de datos a un hipervínculo y luego recuperar esa información en la página vinculada cuando se muestra. Mediante la manipulación de cadenas de consulta, un atacante puede robar fácilmente información de una base de datos, conocer detalles sobre la arquitectura de su aplicación web o posiblemente ejecutar comandos en su servidor web.
Publicar datos: dado que manipular una cadena de consulta es tan fácil como escribir texto en la barra de direcciones de un navegador, muchas aplicaciones web se basan en el método POST junto con el uso de formularios en lugar de GET para pasar datos entre páginas. Dado que los navegadores normalmente no muestran datos POST, algunos programadores se engañan pensando que es difícil o imposible cambiar los datos, cuando en realidad es todo lo contrario.
Encabezados: tanto las solicitudes como las respuestas HTTP usan encabezados para entregar información sobre el mensaje HTTP. Es posible que un desarrollador no considere los encabezados HTTP como áreas de entrada, aunque muchas aplicaciones web registrarán encabezados como "referente" o "agente de usuario" en una base de datos para estadísticas de tráfico.
Cookies: muchas aplicaciones web utilizan cookies para guardar información (por ejemplo, ID de usuario y marcas de tiempo) en la máquina del cliente. Al cambiar estos valores o envenenar la cookie, los usuarios maliciosos pueden obtener acceso a las cuentas y la información de otros usuarios. Además, los atacantes también pueden robar la cookie de un usuario y obtener acceso directo a la cuenta del usuario, evitando la necesidad de ingresar una identificación y contraseña u otra forma de autenticación.
Para desarrollo:
Este problema surge de una validación incorrecta de los caracteres aceptados por la aplicación. Cada vez que se pasa un parámetro a una página web generada dinámicamente, se debe suponer que los datos podrían tener un formato incorrecto. La aplicación debe contener suficiente lógica para manejar la situación de que un parámetro no se pase o se pase incorrectamente. Tenga en cuenta cómo se envían los datos, como resultado de un GET o POST. Las cookies deben tratarse de la misma manera que los parámetros al desarrollar un código seguro y estable. Las siguientes recomendaciones le ayudarán a asegurarse de que está entregando aplicaciones web seguras.
Defina estrictamente el tipo de datos: defina estrictamente el tipo de datos (por ejemplo, una cadena, un carácter alfanumérico, etc.) que aceptará la aplicación. Valide la entrada de caracteres incorrectos. Adopta la filosofía de usar lo bueno en lugar de lo malo. Defina el conjunto de caracteres permitido. Por ejemplo, si un campo va a recibir un número, solo permita que ese campo acepte números. Defina las longitudes de datos máxima y mínima para lo que aceptará la aplicación.
No se pasa el parámetro: si se espera que un parámetro se pase a una página web dinámica y se omite, la aplicación debe proporcionar un mensaje de error aceptable al usuario. Además, NUNCA asuma que se está pasando un parámetro antes de usarlo en una aplicación.
Parámetro de formato incorrecto: nunca se debe suponer que un parámetro tiene un formato válido. Esto es especialmente cierto si el parámetro se pasa a una base de datos SQL. Cualquier cadena que se pase directamente a una base de datos sin verificar primero el formato correcto puede ser un riesgo importante para la seguridad. Además, solo porque un parámetro normalmente se proporciona mediante un cuadro combinado o un campo oculto, no asuma que el formato es correcto. Un pirata informático intentará alterar estos parámetros primero si intenta ingresar a su sitio.
Permitir que los nombres de archivo se pasen a través de un nombre de archivo: si se usa un parámetro para determinar qué archivo procesar de alguna manera, nunca permita que se use el nombre de archivo antes de que se verifique que es válido. Específicamente, debe probar la existencia de caracteres que indiquen el recorrido del directorio, como …/, c:\ y /.
Almacenamiento de datos críticos en parámetros ocultos: Muchos programadores cometen el error de almacenar datos críticos en un parámetro oculto o cookie. Suponen que, dado que el usuario no lo ve, es un buen lugar para almacenar datos como el precio, el número de pedido, etc. Tanto los parámetros ocultos como las cookies pueden manipularse y devolverse al servidor, por lo que nunca suponga que el cliente le devolvió lo que usted establecido a través de un parámetro oculto o cookie.
Para operaciones de seguridad:
Los problemas que surjan de la manipulación de parámetros deberán corregirse en última instancia en el código de la aplicación.
Para control de calidad:
Por razones de seguridad, es importante probar la aplicación web no solo como un usuario normal, sino también como uno malicioso. Las pruebas manuales simples pueden incluir cambiar los valores de los parámetros numéricos de forma secuencial, modificar los valores de las cookies o incluir letras en los parámetros numéricos para ver cómo responde la aplicación. Esta evaluación evaluará minuciosamente los parámetros de susceptibilidad a la manipulación.
Para desarrollo:
Este problema surge de una validación incorrecta de los caracteres aceptados por la aplicación. Cada vez que se pasa un parámetro a una página web generada dinámicamente, se debe suponer que los datos podrían tener un formato incorrecto. La aplicación debe contener suficiente lógica para manejar la situación de que un parámetro no se pase o se pase incorrectamente. Tenga en cuenta cómo se envían los datos, como resultado de un GET o POST. Las cookies deben tratarse de la misma manera que los parámetros al desarrollar un código seguro y estable. Las siguientes recomendaciones le ayudarán a asegurarse de que está entregando aplicaciones web seguras.
Defina estrictamente el tipo de datos: defina estrictamente el tipo de datos (por ejemplo, una cadena, un carácter alfanumérico, etc.) que aceptará la aplicación. Valide la entrada de caracteres incorrectos. Adopta la filosofía de usar lo bueno en lugar de lo malo. Defina el conjunto de caracteres permitido. Por ejemplo, si un campo va a recibir un número, solo permita que ese campo acepte números. Defina las longitudes de datos máxima y mínima para lo que aceptará la aplicación.
No se pasa el parámetro: si se espera que un parámetro se pase a una página web dinámica y se omite, la aplicación debe proporcionar un mensaje de error aceptable al usuario. Además, NUNCA asuma que se está pasando un parámetro antes de usarlo en una aplicación.
Parámetro de formato incorrecto: nunca se debe suponer que un parámetro tiene un formato válido. Esto es especialmente cierto si el parámetro se pasa a una base de datos SQL. Cualquier cadena que se pase directamente a una base de datos sin verificar primero el formato correcto puede ser un riesgo importante para la seguridad. Además, solo porque un parámetro normalmente se proporciona mediante un cuadro combinado o un campo oculto, no asuma que el formato es correcto. Un pirata informático intentará alterar estos parámetros primero si intenta ingresar a su sitio.
Permitir que los nombres de archivo se pasen a través de un nombre de archivo: si se usa un parámetro para determinar qué archivo procesar de alguna manera, nunca permita que se use el nombre de archivo antes de que se verifique que es válido. Específicamente, debe probar la existencia de caracteres que indiquen el recorrido del directorio, como …/, c:\ y /.
Almacenamiento de datos críticos en parámetros ocultos: Muchos programadores cometen el error de almacenar datos críticos en un parámetro oculto o cookie. Suponen que, dado que el usuario no lo ve, es un buen lugar para almacenar datos como el precio, el número de pedido, etc. Tanto los parámetros ocultos como las cookies pueden manipularse y devolverse al servidor, por lo que nunca suponga que el cliente le devolvió lo que usted establecido a través de un parámetro oculto o cookie.
Para operaciones de seguridad:
Los problemas que surjan de la manipulación de parámetros deberán corregirse en última instancia en el código de la aplicación.
Para control de calidad:
Por razones de seguridad, es importante probar la aplicación web no solo como un usuario normal, sino también como uno malicioso. Las pruebas manuales simples pueden incluir cambiar los valores de los parámetros numéricos de forma secuencial, modificar los valores de las cookies o incluir letras en los parámetros numéricos para ver cómo responde la aplicación. Esta evaluación evaluará minuciosamente los parámetros de susceptibilidad a la manipulación.