¿Está bien tener una capa de validación antes de la capa de control de acceso?

24

Estoy creando una aplicación web con API reducida y en esta aplicación tenemos diferentes capas que están haciendo su propio trabajo.

La primera capa es la capa de Validación que valida la entrada del usuario y si pasa la validación, la movemos a la segunda capa (que es la capa de Control de acceso ), de lo contrario, devuelve el mensaje de error

La segunda capa es Control de acceso que verifica si el usuario tiene permiso para realizar la tarea que desea realizar. Si el usuario tiene permiso, mueve la solicitud a la siguiente capa, de lo contrario, devolverá un mensaje de error

Third Layer es Controller Layer donde tenemos la lógica de aplicación

Mi pregunta es que ¿está bien tener una capa de validación antes del control de acceso? ¿Qué sucede si el usuario está intentando realizar una tarea para la cual no tiene permiso y estamos enviando un mensaje de error de validación? El usuario estaría enviando solicitudes a un punto final y hablando con la capa de validación y una vez que pasa la validación solo entonces vería el mensajeYou can't access this!

Me parece extraño, ¿está bien así o cuáles podrían ser mis otras opciones en infraestructura?

validation web-api access-control

— Mahoma
fuente

10

También vale la pena mencionar que las validaciones a menudo deben llegar a la base de datos para hacer su trabajo, o un almacén de archivos. Si hace esto antes de verificar las violaciones del control de acceso, esencialmente permite que los atacantes hagan DDoS en su base de datos o sistema de archivos lanzando grandes cantidades de tráfico a esa URL en particular.

— Greg Burghardt

En mi caso, lo mismo ocurre con el Middleware de control de acceso, comprueba un recurso y ve si el tipo de recurso es accesible por el usuario, si es accesible, permito el acceso, de lo contrario no lo haga

— Muhammad

Es verdad. Durante un DDoS, esa capa aún afectará su almacén de datos. Al ejecutar esa capa primero, no accederá a su almacén de datos para validaciones Y control de acceso, solo lo hará para control de acceso. Reduce el tamaño del tsunami, pero no evita que golpee la playa. Le da a usted o a su equipo de servidores una oportunidad de luchar para responder a un ataque antes de que todo el sistema se empantane.

— Greg Burghardt

55

Desde un punto de vista práctico, el control de acceso debe venir antes de la validación de todos modos: ¿cómo va a validar la exactitud de la solicitud de un usuario si no puede acceder a la solicitud en primer lugar?

— Zibbobz

Validación @Zibbobz es simple como la comprobación de si el usuario está enviando esquema correcto, al igual que el parámetro que debe ser entero es entero o alguna otra cosa

— Muhammad

57

Depende de si conocer la validez de alguna entrada para una tarea que no se le permite hacer es una fuga de seguridad. Si es así, realmente debería hacerlo al revés.

La única respuesta segura a un usuario no autorizado es "acceso denegado". Si a veces la respuesta es "solicitud incorrecta" y otras veces "acceso denegado", está enviando información a un usuario no autorizado.

Como ejemplo, puede verificar en la validación de la tarea "eliminar documento" que el documento nombrado existe. Alguien sin permisos sería capaz de discernir si algo existe al intentar eliminarlo y comparar qué error recibe. Un atacante particularmente determinado podría enumerar todos los nombres de documentos (con una longitud determinada) para ver cuál existe.

— Caleth
fuente

77

+1, absolutamente. Si sus datos son de alguna manera personalmente identificables o sensibles de cualquier otra manera, entonces las implicaciones de seguridad son mucho, mucho más serias que las implicaciones de usabilidad.

— Kilian Foth

44

@caleth en realidad no le permitiría saber si cierto documento está en el sistema o no, este tipo de información solo se dará cuando llegue a la capa de controlador. La validación solo verifica el esquema, no accede a la base de datos: solo el control de acceso y las capas más profundas acceden a la base de datos. Además, la capa de control de acceso solo muestra lo mismo mientras exista o no un recurso. Lo único comprometedor es el esquema en el que estoy pensando si está bien o no

— Muhammad

@Caleth ¿Podrías dar más detalles sobre tu último comentario? No veo cómo ese es el caso dado el comentario de los OP. En cualquier caso, parece que la única información que se devuelve es información no privilegiada si el esquema se documenta públicamente.

— Rotem

11

@Rotem Es esencialmente imposible determinar de antemano qué información podría aprovechar un atacante. El hecho de que no haya encontrado una manera de aprender algo que no debería, no significa que no haya tal manera. Como un ejemplo extremo, puede que no haya ninguna vulnerabilidad ahora , pero en el futuro alguien podría añadir un cheque a la capa de validación que hace la información de fugas, ya que no sabían que no estaba protegido.

— Kamil Drakari

44

@KamilDrakari no es un ejemplo extremo, es un ejemplo perfectamente razonable. Dicho de otra manera: si realiza la validación antes del control de acceso, cada vez que un desarrollador desee agregar un paso de validación, debe tomar una decisión sobre si esa validación expone algo sensible. La posibilidad de que cada desarrollador reciba esa llamada correcta parece pequeña.

— mfrankli

24

Bueno, hay múltiples tipos de validación:

Comprobación de cordura básica barata, que verifica que la solicitud obviamente no está malformada.

Esto suele ser al menos parcialmente duplicado del lado del cliente, para evitar viajes de ida y vuelta inútiles.

De todos modos, debe hacerse antes del control de acceso para hacer las cosas más fáciles y menos propensas a errores, ya que no corre el riesgo de que se filtre información.
Validación más costosa que todavía no depende de ningún dato de aplicación protegido.

Si existe tal validación adicional, podría ser después del control de acceso no para evitar la fuga de datos, sino para obstaculizar los ataques de DOS.
A veces, la simple ejecución de la solicitud hace parte de esa validación implícitamente a un costo reducido o sin costo, por lo que se puede dejar aquí.

Si se duplica toda la validación del primer paso, también podría tener sentido duplicar partes de este lado del cliente.
Validación adicional dependiendo de los datos protegidos de la aplicación.

Hacerlo antes del control de acceso obviamente conlleva el riesgo de fugas de información. Por lo tanto, primero haga el control de acceso.

— Deduplicador
fuente

3

Sería ideal realizar el control de acceso en un punto de aplicación de políticas en su infraestructura incluso antes de llegar a su API. Primero sería un conjunto estático básico de validación (Ej .: OpenAPI), seguido de una validación comercial más profunda. Incluso alguna validación estática podría tener un impacto en la disponibilidad de sus ataques ReDOS de aplicaciones .

— felickz

@felickz: Sí, los ataques de DOS son una razón válida para diferir la validación hasta después de la autorización. Es un acto de equilibrio. De todos modos, dividí mi primer punto para tenerlo en cuenta.

— Deduplicador

Hacer una validación costosa antes del control de acceso también corre el riesgo de perder información debido a ataques de tiempo. Si su sistema tarda más o menos según el recurso, el atacante puede inferir aspectos del recurso que se solicita.

— Mentira Ryan

@LieRyan: esta es la razón por la cual toda la validación que se realiza potencialmente antes del control de acceso no depende en absoluto de los datos de la aplicación protegida.

— Deduplicador

13

Debe haber alguna validación antes del control de acceso. Digamos que la API de SO tiene un punto final "editar respuesta", entonces si el usuario puede editar una respuesta particular puede depender de la respuesta (debajo de cierta reputación, un usuario solo puede editar sus propias respuestas). Por lo tanto, el parámetro "ID de respuesta" que está bien formado debe verificarse antes de que la capa de control de acceso entre en juego; posiblemente también que existe la respuesta.

OTOH, como mencionan Caleth y Greg, poner una validación más extensa antes del control de acceso es un riesgo potencial de seguridad.

Entonces las reglas duras son

No debe divulgar ninguna información a través de la validación que se supone que el usuario no puede averiguar de otra manera.
Debe validar los datos antes de que el control de acceso pueda usarlos en la medida en que el control de acceso lo necesite.

Seguir estas dos reglas puede significar que debe tener alguna validación antes y otra después del control de acceso.

— Sebastian Redl
fuente

3

Esta es la respuesta realista. Si se trata de una validación de estructura de datos de entrada simple y directa, no debe haber reparos en ponerla en primer lugar. Incluso protege la capa de control de acceso de entradas / paquetes especialmente diseñados. La validación que en realidad implica una fuga o adivinación segura de la información, debe realizarse después de las verificaciones de acceso.

— SD

Eso supone que las respuestas son públicas. Me atrevo a decir que muchas API ni siquiera le mostrarán los datos sin autenticación.

— TomTom

6

Además de la posible frustración de recibir un "acceso denegado" después de validar la entrada; También tenga en cuenta que la capa de Validación , a menos que sea muy simple, siempre puede necesitar información del Controlador . Teniendo esto en cuenta, creo que posicionar la Validación detrás del Control de acceso , más cerca del Controlador tiene más sentido.

— simurg
fuente

2

Eso depende de lo que quiera decir con la capa de validación; si con eso solo quiere decir verificar la sintaxis de la solicitud, eso es seguro y algo que debe hacer de todos modos. Si su 'validación' utiliza cualquier información que un usuario sin privilegios no tiene acceso a, ya no es seguro.

Definitivamente, debe tener un verificador de cordura antes de intentar el control de acceso, pero debe asegurarse de comunicar muy claramente a todos los encargados del mantenimiento (actuales y futuros) que esta parte no debe usar información privilegiada; Cualquier verificación de este tipo debe realizarse en un paso de validación por separado después de la autenticación.

Como una verificación de cordura para el verificador de cordura, en realidad no debería tener ninguna dependencia del código en ninguna parte de su código en la parte inferior de la tubería y debe ser separable en su propio paquete que debería publicarse sin ningún problema (aparte de posibles problemas legales) . Si no puede hacer eso, su 'capa de validación' está haciendo demasiado (o su base de código es un desastre).

— Cúbico
fuente

1

No. No esta bien.

Si tiene un error en su capa de validación, puede pasar por alto la capa de seguridad.

Es un error común considerar la seguridad como parte de los requisitos comerciales. "solo los usuarios con el rol de ventas deberían poder ver las cifras trimestrales" parece una regla de negocios.

Pero si desea estar seguro, debe leer una regla como "solo los usuarios en el rol de ventas deben poder ejecutar el código en este punto final" Debe asegurarse de que su servidor siempre devuelva "acceso denegado" antes de que llegue a cualquier tipo de código que haya escrito o archivos en el servidor.

— Ewan
fuente