Problemas de seguridad al permitir caracteres especiales en el campo de entrada

2

Estoy creando una aplicación web, en la que debo permitir que el usuario ingrese cualquier carácter (incluso caracteres especiales - ~!@#$%^&*()_-+=|\{}[];:'"<,.> ) en un campo de entrada. Para mitigar los problemas causados por ellos, me ocupo de dos cosas:

  1. inyección SQL - mediante consultas parametrizadas
  2. Secuencias de comandos de sitios cruzados: HTML que escapa la entrada del usuario antes de agregarla a DOM.

¿Es suficiente o me falta algo?

EDIT Para dar un mejor contexto, estoy explicando el flujo.

En mi aplicación web, la entrada del usuario va directamente a una base de datos. Se obtiene de la base de datos para crear HTML (también para la configuración de atributos y estilos de elementos html) y JSON. Estoy escapando de los valores obtenidos de la base de datos al crear HTML.

Al crear JSON, no estoy escapando de esos valores recuperados. Este JSON es utilizado por nuestra otra aplicación para crear HTML. Y me estoy asegurando de que los valores se escapen antes de insertarlos en HTML.

    
pregunta Moazzam Khan 18.05.2015 - 12:29
fuente

2 respuestas

3

No hay tal cosa como caracteres especiales.

Todo depende del contexto en que se use la entrada dentro de su aplicación. Protegerse contra SQLi y XSS es excelente, sin embargo, si la entrada se va a utilizar en una llamada de shell del sistema operativo, no le conviene.

Siempre codifique o desinfecte cuando se utilicen los datos; deje esto lo más tarde posible. Por ejemplo, cuando se imprime en HTML, la codificación HTML en este punto.

Entonces, sin conocer todos los puntos de salida o los sumideros en su aplicación, es imposible decir si le falta algo. Si todo lo que está haciendo es insertar datos en una base de datos y enviarlos a HTML ( no JSON, JavaScript, CSS, etc.), si realiza la parametrización correcta y la codificación de salida HTML en los lugares correctos Son buenos en cuanto a vulnerabilidades XSS y SQLi. Hacer cualquier otra cosa con los datos requeriría la codificación, el saneamiento o el uso correcto de la API según el formato.

    
respondido por el SilverlightFox 18.05.2015 - 12:46
fuente
-2
¿

pones la entrada del usuario directamente en una base de datos? ... Mala idea (en general).

Debes desinfectar todas las entradas. (por lo tanto, la entrada proviene del cliente y la entrada proviene de la base de datos).

Confía en el Cliente para que los valores estén seguros en su ejemplo. algo en lo que nunca debes confiar plenamente, ya que está fuera de tu control.

para el resto, me refiero a @SilverlightFox ya que sus puntos son válidos y aplicables con 1 adición. La entrada del usuario debe ser saneada no solo en la pantalla sino también antes del almacenamiento.

    
respondido por el LvB 18.05.2015 - 14:08
fuente

Lea otras preguntas en las etiquetas