Estrategia de parametrización para inyección de caracteres peligrosos [cerrado]

-2

Tengo un campo de texto de entrada para aceptar ID de correo electrónico. Si el usuario no ingresa la ID de correo electrónico, Tengo una validación del lado del cliente utilizando Java Script para mostrar un mensaje de error que lee como, "Por favor, introduzca una identificación de correo electrónico válida". El código es como,

if(EmailIdIsNull)
{
   error = "Please enter valid email id";
   //Submit this error message to the form
}

Esta forma de manejar el cheque es vulnerable a la inyección de caracteres peligrosos. Por ejemplo, uno cambió "Ingrese una identificación de correo electrónico válida" a "%22@27%3ECIMG+SRC%3D.html%22%3E"

La solución para esto fue dada como,

"If available, use structured mechanisms that automatically enforce the separation 
between data and code. These mechanisms may be able to provide the relevant quoting,
encoding and validation automatically, instead of relying on the developer to provide
this capability at every point where output is generated"

Estoy buscando una explicación de la solución anterior. Además, ¿cómo se puede aplicar una solución anterior? en mi caso con respecto a la verificación del lado del cliente de la identificación del correo electrónico?

    
pregunta Vikas V 09.08.2013 - 11:34
fuente

2 respuestas

2

En primer lugar, no debes nunca confiar en el código del lado del cliente para ningún tipo de validación. Es ridículamente trivial eludir cualquier validación en el lado del cliente.

En su lugar, debe siempre desinfectar y escapar de las entradas en el lado del servidor. Claro, puede realizar la validación del lado del cliente para garantizar una buena experiencia de usuario, pero siempre valide también en su servidor.

Supongo que la dirección de correo electrónico se escribirá en una base de datos en algún lugar. En ese caso, utilice las consultas parametrizadas en lugar del SQL dinámico. Eso te protegerá de los ataques de inyección SQL. Debería escapar de los datos al enviarlos para evitar ataques XSS. XSS y inyección de SQL hojas de trucos de prevención de OWASP es una referencia útil aquí.

    
respondido por el Ayrx 09.08.2013 - 11:42
fuente
1
Las

consultas parametrizadas o declaraciones preparadas son un ejemplo de "mecanismos que imponen automáticamente la separación entre datos y código".

El problema cuando no hay separación entre datos y código es que los datos introducidos por un usuario se pueden inyectar en el código y puede manipular la aplicación de maneras que el programador no haya pensado.

Para otros mecanismos que "proporcionan la cotización, la codificación y la validación relevantes automáticamente", puede buscar información sobre OWASP ESAPI o Java Spring Security Framework .

La recomendación de no "depender del desarrollador para proporcionar esta capacidad en cada punto donde se genera la salida" es porque si confía en un ser humano probablemente tendrá errores. Si utiliza una API centralizada que hace imposible que los programadores pierdan una validación de entrada, estará más seguro.

    
respondido por el kinunt 09.08.2013 - 12:03
fuente

Lea otras preguntas en las etiquetas