Protección contra consultas sintéticas

5

Nota: Uno, no estoy seguro de si las consultas sintéticas son la palabra correcta para el riesgo del que estoy hablando. En segundo lugar, aunque estoy considerando el modelo de 3 niveles de aplicaciones, las respuestas generales son bienvenidas en situaciones cliente-servidor donde no es posible la validación del lado del servidor.

Actualmente tengo una página donde haces ciertos cálculos utilizando lo que se llama DHTML. Este cálculo genera una cadena que no tiene un patrón particular como tal. Esta cadena se envía a un script del lado del servidor utilizando AJAX.

Cualquier persona con capacitación básica en estas tecnologías puede leer el código y darse cuenta de que la consulta se envía, es algo como esto:

 http://domain.com/script.php?var=theStringSoGenerated

Con la esperanza de explotar un posible defecto, un hacker escribe en su navegador:

 http://domain.com/script.php?var=aCompletelyRandomString

Lo hace unas cuantas veces y no ve beneficios evidentes y se cierra, pero en el nivel medio, el script PHP, totalmente indefenso sin una posible validación, actualiza e inserta la cadena aleatoria en la base de datos, lo que afecta su integridad y lleva al desperdicio de recursos.

Pregunta: ¿Cómo puedo proteger mi aplicación contra tales ataques?

    
pregunta check123 06.05.2011 - 19:22
fuente

2 respuestas

3

Debes validar la entrada en el servidor.

Presumiblemente, si no todas las cadenas están bien, entonces el cliente está haciendo algo para validar que la cadena que genera está bien, o está usando algún proceso para generar la cadena. Ahora haga esas mismas comprobaciones en el lado del servidor, o haga que el servidor vuelva a construir ese proceso para verificar que se siguió. Si el cliente puede hacerlo, el servidor también puede hacerlo.

El núcleo aquí es: no confíes en el cliente. Todas las verificaciones en las que confía deben realizarse en el servidor (está bien si se realizan tanto en el cliente como en el servidor, pero no está bien hacer verificaciones solo en el cliente y omitirlas en el servidor).

Si desea obtener consejos más específicos, deberá informarnos más sobre cómo el cliente genera la cadena y qué cadenas son o no son válidas.

    
respondido por el D.W. 09.05.2011 - 10:04
fuente
3

Parece que en realidad no estás preguntando sobre ataques de terceros como CSRF o XSS, sino que realmente te preocupa que el usuario autorizado reescriba el JavaScript o envíe una consulta a mano.

No hay protección contra eso, a menos que esté dispuesto a tomar medidas extraordinarias para bloquear al usuario de su propia computadora y navegador . Ver por ejemplo ¿Es AJAX fundamentalmente inseguro?

    
respondido por el nealmcb 07.05.2011 - 15:20
fuente

Lea otras preguntas en las etiquetas