Seguridad web, ¿hay problemas con los campos ocultos (sin datos confidenciales)?

Question

Estaba teniendo una conversación con mis compañeros de trabajo. Tenemos que implementar algunos estándares de seguridad. Sabemos que no se debe almacenar información "confidencial, de direcciones, fecha de nacimiento" en campos ocultos, pero ¿está bien utilizar campos ocultos para su aplicación, en general?

Por ejemplo:

action=goback 

parece que sería más seguro utilizar campos ocultos para ese tipo de información en lugar de añadirlo en la cadena de consulta. Es una información menos que un hacker podría usar en contra de su aplicación.

Answer 1

Un hacker puede acceder a los campos ocultos con la misma facilidad que los valores de la cadena de consulta mediante el uso de un proxy de interceptación (o cualquier cantidad de herramientas).

No creo que haya nada de malo en usar campos ocultos, siempre que no se utilicen para nada sensible y los valide como lo haría con cualquier otro valor del cliente.

Answer 2

Hacer un campo "oculto" no tiene nada que ver con la seguridad, y debe considerarse una decisión de UI. Cualquier "hacker" leerá su fuente HTML de todos modos.

Mejor no mostrar información confidencial o, si es necesario, utilizar SSL (para evitar la intercepción de datos por intermediarios de red) y una combinación de desafíos de inicio de sesión (para evitar el acceso no autorizado).

Answer 3

Yo diría que esto no es más o menos seguro que colocar el artículo en la cadena de consulta. Después de todo, siempre se puede ver el código fuente en el sitio (y no hay ninguna forma de evitarlo, ya que siempre se puede descargar programáticamente la fuente).

Una mejor solución aquí sería cifrar los nombres de los campos y los valores con una clave que se genera en el servidor, y solo en el servidor. A menos que el servidor haya sido pirateado, el cliente no tendría ni idea del nombre del valor ni de su valor.

Por supuesto, ya que esto proviene del cliente, aún debe verificar la validez de los datos que regresan, no solo dé por hecho que no se ha alterado de una manera que no lo hizo dictar.

Para ese fin, querrá usar el hash para asegurarse de que el valor no haya sido alterado.

Answer 4

Es solo un agujero de seguridad si expone información que de otra forma no estaría disponible para el usuario final y/o no la valida a su regreso.

me vería en lugar de almacenar dicha información en una variable de sesión de servidor en lugar ...

Answer 5

En general no utilizan campos de formulario ocultos para los datos sensibles. Solo para datos POST estáticos no sensibles que usted comprende que no es seguro manejar "como se recibió". La única vez que los uso es almacenar tokens de sesión a medida que se muestran y verifican al recibir el POST. Evitar los ataques de CSRF o al menos hacerlos mucho más difíciles.

Answer 6

Almacenar sus datos en un campo oculto es, desde un punto de vista de seguridad, exactamente lo mismo que almacenarlo en la cadena de consulta. De hecho, si su formulario usa la acción GET, termina de todos modos en la cadena de consulta.

Los campos ocultos no tienen ninguna relación con la seguridad; simplemente son un método por el cual los datos pueden almacenarse en un formulario sin forzando a a que el usuario lo vea. No proporcionan una forma de evitando que el usuario lo vea.

Answer 7

Como otras personas han mencionado tanto la cadena de consulta como los campos ocultos son esencialmente datos públicos, visibles para el usuario.

Una cosa a tener en cuenta si coloca datos en la cadena de consulta es que la gente pasa las direcciones URL, y debido a esto nunca debe contener ninguna información específica para el usuario actual.

También es probable que sea una buena idea no incluir información de estado en la url, si ese estado no se puede ingresar directamente. O al menos necesitaría manejar información de estado no válida en la cadena de consulta.

Answer 8

campos ocultos no son siempre un problema, pero siempre deben sonar las alarmas, ya que tienen dos problemas potenciales:

1) Si los datos son sensibles, se expone al cliente (por ejemplo, usando un proxy, o simplemente ver fuente - y no tiene sentido intentar y prevenir esto programáticamente)

2) Si los datos son interpretados por el servidor, un usuario conocedor puede cambiarlo. Para tomar un ejemplo tonto, si el campo oculto contiene el saldo bancario del usuario, podrían usar un proxy o un cliente no estándar para hacer que el servidor piense que su saldo bancario es lo que elija.

El segundo es una gran fuente de vulnerabilidades en webapps. Los datos asociados con la sesión deben mantenerse en el lado del servidor, a menos que tenga un medio de validarlo en el servidor (por ejemplo, si el servidor ha firmado o cifrado el campo).

Si está seguro de que no está cayendo en ninguna de estas trampas, puede utilizarlas. Como regla general, no utilizaría campos ocultos, excepto los datos que te gustaría ver en la cadena de consulta, o si javascript los necesita para procesarlos. Sin embargo, en este último caso, debe asegurarse de que el servidor está validando, pero no suponga que el cliente ejecutará su javascript.

Answer 9

Además de todos los otros consejos útiles de otros carteles, también agregaría que los campos ocultos hacen que su aplicación no sea menos vulnerable a los ataques de inyección de SQL como lo hacen los valores de cadena de consulta url. Como siempre, desinfecte su entrada.

Answer 10

Considere encriptar el nombre y el valor de su campo oculto con el fin de falsificar la cuenta, ya que los hackers aún pueden hacerse con sus campos ocultos y manipularlos de la forma que quisieran.